1.4　微服務拆分

微服務架構的顯著特點就是微小、程序功能單一、顆粒度小。所以，宏大的單體架構向微服務架構演進過程中，關鍵的步驟就是進行微服務拆分，將顆粒度較大的單體程序拆分成多個顆粒度較小的微服務程序。

下面介紹微服務設計原則和拆分原則。

1.4.1　微服務設計原則

1．AKF拆分原則

AKF擴展立方體（可以參考The Art of Scalability），是AKF公司的技術專家抽象總結的應用擴展的三個維度。按照這個擴展模式，從理論上來說可以將一個單體系統進行無限擴展?；贏KF擴展立方體的拆分如圖1-4所示。

X 軸：指的是水平復制、水平擴容。例如，單體架構系統多運行幾個程序實例，做成集群加負載均衡的模式。

Z 軸：基于類似的數據分區。例如，一個互聯網打車應用突然變得火熱，用戶量激增。集群模式不再適用，可按照用戶請求的地區進行數據分區，在北京、上海、廣州等多建幾個集群。

Y 軸：就是微服務的拆分模式，基于不同的業務拆分。例如，按照不同業務類型、不同處理步驟、系統前后銜接關系、部署區域等進行拆分。

2．前后端完全分離原則

前后端在邏輯和物理上的分離，前端和后端均獨立部署，各自專注自身業務。另外，前后端完全分離后，將靜態資源推送到CDN上將更加容易，可以方便使用CDN的靜態資源加速能力。

3．無狀態服務原則

微服務盡量無狀態化，優點是應用可以任意橫向擴容、擴展。

4．RESTful通信風格

無狀態的RESTful通信風格的HTTP協議具備先天優勢，擴展能力很強。JSON 報文序列化，輕量簡單，具備語言無關性，主流語言都提供成熟的RESTful API框架，相對于一些RPC框架生態更完善。

1.4.2　微服務拆分原則

1．粒度適中原則

拆分不應該過分追求細粒度，要考慮適中性，不能過大或過小。拆分后的代碼應該是易讀、易維護的，業務職責也是明確且單一的。

2．先大后小原則

在拆分大粒度模塊時，一個模塊拆分為一個微服務。后續迭代優化時，可以根據需要將較大的服務進一步拆分為多個微服務。

3．公共服務抽取原則

公共服務一般分為數據庫服務、緩存服務、消息服務、日志服務、查詢服務等，這些服務封裝為公共服務，然后向其他微服務提供API接口。

4．實體類封裝原則

數據庫表對應的實體類、過程數據類、關聯查詢結果類，以及第三方訪問返回結果類等是所有微服務都會使用到的模塊。