微服務架構作爲目前使用的主流架構，已經被廣泛使用，但是對於服務的劃分卻沒有固定的原則，在工作中也經常會出現服務劃分過度或者不充分的情況。所以在這裏想探討一下服務邊界和服務劃分的方法。
微服務設計四個原則：
- AKF拆分原則
-
AKF擴展立方體(參考《The Art of Scalability》)，是一個叫AKF的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，可以將一個單體系統，進行無限擴展。
X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，做個集羣加負載均衡的模式。
Z 軸 ：是基於類似的數據分區，比如一個互聯網打車應用突然或了，用戶量激增，集羣模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集羣。
Y 軸 ：就是我們所說的微服務的拆分模式，就是基於不同的業務拆分。
場景說明：比如打車應用，一個集羣撐不住時，分了多個集羣，後來用戶激增還是不夠用，經過分析發現是乘客和車主訪問量很大，就將打車應用拆成了三個乘客服務、車主服務、支付服務。三個服務的業務特點各不相同，獨立維護，各自都可以再次按需擴展。
- 前後端分離
前後端分離原則，簡單來講就是前端和後端的代碼分離也就是技術上做分離，我們推薦的模式是最好直接採用物理分離的方式部署，進一步促使進行更徹底的分離
- 無狀態服務
對於無狀態服務，首先說一下什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個“狀態”數據的服務被稱爲有狀態服務，反之稱爲無狀態服務。
那麼這個無狀態服務原則並不是說在微服務架構裏就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變爲無狀態的計算類服務，那麼狀態數據也就相應的遷移到對應的“有狀態數據服務”中。
場景說明：例如我們以前在本地內存中建立的數據緩存、Session緩存，到現在的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。
- Restful通信風格
作爲一個原則來講本來應該是個“無狀態通信原則”，在這裏我們直接推薦一個實踐優選的Restful 通信風格
微服務設計目標
- 架構必須穩定；
- 服務必須高內聚 - 服務應該實現一小組強相關的功能；
- 服務必須符合開閉原則 - 將一同變更的內容打包在一起，以確保每個更改僅影響一個服務；
- 服務必須鬆耦合 - 每個服務都可以在不影響客戶端的情況下更改實現；
- 服務應該是可測試的；
- 每項服務都小到足以由“兩個披薩”團隊開發，即一個6-10人的團隊；
- 負責一個或多個服務的每個團隊必須是自治的 - 團隊能夠在與其他團隊儘量少的協作下，來開發和部署他們的服務。
服務劃分方法
通過領域驅動設計（DDD），設計與 子域 相對應的服務。DDD通過分析問題空間和業務邏輯，將應用程序定義爲域。域由多個子域組成。每個子域對應於業務的不同部分。
子域可分爲以下幾類：
- 核心類 - 業務的關鍵差異化因素和應用程序中最有價值的部分；
- 支持類 - 與業務有關，但與差異化無關；這些可以在內部實施或外包；
- 通用類 - 與業務無關，理想情況下可以使用現成的軟件實現。
例如一個會員賬號管理系統包含以下幾個子域：
賬號管理域：包含賬號的模型和提供的基本接口能力
登錄模塊域： 涉及登錄和免登流程
註冊賬號域： 賬號註冊和賬號創建能力
個人中心域： 涉及個人中心管理