圖片

好的架構就像優美的散文，行散神不散。

什么是服務

業務封裝

服務是動詞，對業務流程進行封裝和抽象。封裝針對業務深度，如下單服務封裝下單一系列處理過程。抽象針對業務廣度，支持類似的業務流程，如普通商品/虛擬商品/團購商品下單。

組件復用

進程外調用，接口無狀態；

職責聚焦，邊界明確；

獨立開發，獨立部署。

圖片

Case分析

下單服務

粗粒度 SOA

提供端到端的功能，對應用友好；

服務內部實現復雜，訪問一系列庫表，對象之間有大量計算，耦合緊密；

如果需求有變化，整個大服務跟修改和重新部署。

下單邏輯聚合

微服務

• 每個子服務高度聚焦，邊界清晰，獨立數據模型；
• 需要上層應用做服務聚合，一般簡單組裝即可；
• 需求有變化，修改對應子服務。因子服務提供功能完備，一般應用方調整聚合邏輯即可（比如虛擬商品下單，可以跳過發票/發貨環節）。

圖片

圖片

圖片

圖片

圖片

落地建議

粗粒度SOA

• 系統業務之間比較獨立，耦合度不高，面向具體業務需求，提供流程端到端處理，如OTA業務。
• 業務流程比較固定，直接封裝，如銀行轉賬。

微服務

• 業務流程環節多，易變，為每個處理節點構造微服務，允許調整，如電商下單。
• 業務廣度和深度都非常復雜，互相關聯，通過主數據服務打造微內核，簡化依賴并允許上層自由組合，如B2C電商業務。

微服務改造步驟：

圖片

1. 圈定訪問表

步驟：

• 確定哪些表是某個服務所專用的，并且不允許其他服務訪問這些表。例如，訂單服務可能會訪問訂單主表和訂單明細表，但不允許其他服務訪問這些表，訂單服務也不會訪問其他服務的表。

目的：

• 通過明確表的訪問邊界，減少服務之間的耦合，確保數據訪問的安全性和一致性。

2. 收集SQL

步驟：

• 收集各個應用對指定表的所有SQL訪問需求。
• 如果某些SQL涉及到關聯其它表，則需要先將這些SQL進行拆分，確保每個SQL只涉及到單個服務的表。

目的：

• 了解所有的SQL訪問需求，為后續的優化和設計提供依據。

3. 提煉SQL整體設計

步驟：

• 對收集到的SQL訪問需求進行分類和提煉。
• 進行總體設計，如統一緩存、優化查詢等，以提升系統性能。

目的：

• 通過提煉和優化，減少重復的SQL訪問，提升數據庫訪問的效率。

4. 開發接口

步驟：

• 根據提煉后的SQL需求，開發相應的服務接口。
• 確保這些接口能夠滿足各個應用的SQL訪問需求。

目的：

• 提供統一的服務接口，簡化應用的開發和維護。

5. 應用接入

步驟：

• 各個應用逐步接入新的服務接口。
• 可以邊開發邊上線和接入，確保平穩過渡。

目的：

• 通過逐步接入，減少對現有系統的沖擊，確保平穩過渡到新的微服務架構。

6. 獨立遷庫

步驟：

• 在條件允許的情況下，可以考慮將表的schema進行修改，并將數據遷移到獨立的數據庫。
• 徹底與現有的庫表分開，確保新的微服務架構的獨立性。

目的：

• 通過獨立遷庫，進一步減少服務之間的耦合，提高系統的可維護性和擴展性。

B2C電商系統架構：

圖片

業務應?層

• 包括不同業務線的應用，如自營、商城、無線、商家、供應商和第三方。這些業務應用通過業務接口調用底層的組件和服務，實現具體的業務功能。
• 具體的業務模塊如Mobile（移動端）、CMS（內容管理系統）、分類、詳情頁、廣告、搜索、購物車、結算、訂單管理、物料信息、賬戶管理、CRM（客戶關系管理）等。

組件化/服務層

• 這一層主要負責具體的業務邏輯和功能實現，通過組件和服務提供給上層業務應用調用。
• 主要包含應用服務和基礎服務：

應用服務

• 下單（OMS、Shopping）：負責處理訂單管理和購物相關的業務邏輯。
• 促銷、個人中心、精準化、評論、PMS（商品管理系統）：處理促銷活動、用戶個人中心、精準營銷、用戶評論和商品管理相關的業務。
• 客?服務（Invoice、GRS（退貨管理系統））：處理客戶服務和發票、退貨相關的業務。
• YCM（優惠券管理）、PIS（庫存管理系統）、團購、Coupon（優惠券）：處理優惠券、庫存管理、團購和其他促銷活動。
• Search、AD（廣告）、Store、特賣、Finance（財務）、Payment（支付）、更多服務：處理搜索、廣告、商店、特賣、財務、支付等其他服務。

基礎服務

• 產品服務：處理產品信息的管理。
• 庫存服務：管理庫存相關的數據和操作。
• 價格服務：管理商品價格和定價策略。
• 用戶服務：管理用戶信息和用戶操作。
• 訂單服務：管理訂單相關的數據和操作。
• 支付服務：處理支付相關的操作和數據。

數據層

• 這一層負責數據的存儲和管理，包含了不同類型的數據倉庫：

Product：產品數據。

User：用戶數據。

Stock：庫存數據。

Order：訂單數據。

Wireless：無線相關數據。

SBY：可能是某個特定業務線的數據（需要具體上下文來確認）。

BI：商業智能相關的數據。

大數據：大數據平臺，用于存儲和分析大量業務數據。

緩存平臺

• 提供了系統的緩存功能，以提升數據訪問的速度和系統的響應時間。

這個架構展示了一個分層清晰、職責明確的電商平臺架構，通過不同層次的分工和協作，實現了復雜業務需求的處理。每一層都有特定的職責，從數據存儲、基礎服務，到業務邏輯和具體應用，實現了高效的業務處理和良好的擴展性。

關鍵點：

• 分層設計：每一層都有明確的職責，確保了系統的模塊化和可維護性。
• 組件化服務：通過組件化和服務化的設計，提高了系統的靈活性和可擴展性。
• 數據管理：數據層管理著不同類型的業務數據，通過統一的數據平臺支持上層業務應用。
• 緩存機制：通過緩存平臺提升了系統的性能和響應速度。