圖片

好的架構就像優(yōu)美的散文，行散神不散。

什么是服務

業(yè)務封裝

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

組件復用

進程外調(diào)用，接口無狀態(tài)；

職責聚焦，邊界明確；

獨立開發(fā)，獨立部署。

圖片

Case分析

下單服務

粗粒度 SOA

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

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

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

下單邏輯聚合

微服務

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

圖片

圖片

圖片

圖片

圖片

落地建議

粗粒度SOA

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

微服務

• 業(yè)務流程環(huán)節(jié)多，易變，為每個處理節(jié)點構造微服務，允許調(diào)整，如電商下單。
• 業(yè)務廣度和深度都非常復雜，互相關聯(lián)，通過主數(shù)據(jù)服務打造微內(nèi)核，簡化依賴并允許上層自由組合，如B2C電商業(yè)務。

微服務改造步驟：

圖片

1. 圈定訪問表

步驟：

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

目的：

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

2. 收集SQL

步驟：

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

目的：

• 了解所有的SQL訪問需求，為后續(xù)的優(yōu)化和設計提供依據(jù)。

3. 提煉SQL整體設計

步驟：

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

目的：

• 通過提煉和優(yōu)化，減少重復的SQL訪問，提升數(shù)據(jù)庫訪問的效率。

4. 開發(fā)接口

步驟：

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

目的：

• 提供統(tǒng)一的服務接口，簡化應用的開發(fā)和維護。

5. 應用接入

步驟：

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

目的：

• 通過逐步接入，減少對現(xiàn)有系統(tǒng)的沖擊，確保平穩(wěn)過渡到新的微服務架構。

6. 獨立遷庫

步驟：

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

目的：

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

B2C電商系統(tǒng)架構：

圖片

業(yè)務應?層

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

組件化/服務層

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

應用服務

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

基礎服務

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

數(shù)據(jù)層

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

Product：產(chǎn)品數(shù)據(jù)。

User：用戶數(shù)據(jù)。

Stock：庫存數(shù)據(jù)。

Order：訂單數(shù)據(jù)。

Wireless：無線相關數(shù)據(jù)。

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

BI：商業(yè)智能相關的數(shù)據(jù)。

大數(shù)據(jù)：大數(shù)據(jù)平臺，用于存儲和分析大量業(yè)務數(shù)據(jù)。

緩存平臺

• 提供了系統(tǒng)的緩存功能，以提升數(shù)據(jù)訪問的速度和系統(tǒng)的響應時間。

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

關鍵點：

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