場景
如果你正準備將你的單體架構（Monolithic architecture）應用改造爲微服務架構，並希望使用微服務架構將應用程序構造爲一組鬆耦合的服務。那麼第一個要面對的問題就是如何進行服務的拆分。
上圖展示了微服務的架構優勢，主要包括兩方面：
- 簡化測試並允許獨立部署
- 將工程組織結構化爲一組小型（6-10名成員）的自治團隊，每個團隊負責一個或多個服務
這些好處不會自動得到保證。相反，它們只能通過合理的服務分解爲實現。
服務必須足夠小，以由小型團隊開發並易於測試。單一職責（SRP）是一個非常有用的面向對象設計（OOD）原則。SRP將Class的責任定義爲只由一個原因而改更，並且Class僅應該爲一個原因而改變。將SRP應用於服務設計以使服務是具有少量緊密相關功能的凝聚體。
還可以以另一種方式分解應用，以保證大多數新需求和更改的需求僅影響單個服務。這是因爲影響多個服務的變更需要多個團隊之間的協調，這減慢了開發速度。OOD的另一個有用原理是閉包原則（CCP），它指出由於相同原因而更改的類應位於同一包中。例如，也許兩個類實現了同一業務規則的不同方面。目的是當該業務規則更改開發人員時，只需要更改少量（理想情況下僅更改）一個程序包中的代碼。在設計服務時，這種思路很有意義，因爲它將有助於確保每次更改僅影響一項服務。
基於業務分解的原則
- 架構必須穩定
- 服務必須高內聚，單個服務應該實現一小組強相關的功能
- 服務必須符合開閉原則， 即一起的變更應該打包在一起，以確保每次變更隻影響單個服務（譯者注：這只是理想情況，實際上很多情況我們會影響多個服務）
- 服務間必須鬆耦合，每個服務作爲API封裝自己的實現，其實現的變更不會影響到客戶端
- 服務必須是易測試的
- 每個服務是足夠小以至於可以由“two pizza” team開發完成，即6-10人
- 每個開發團隊必須是自治的。每個團隊必須可以以最小的協作成本進行開發和部署