一般系統的服務劃分有以下兩種維度： 按模塊劃分 這個比較適用於偏業務的場景：複雜的系統，最好先按業務領域橫向拆分成可獨立部署的子系統，每個子系統內部再按技術縱向拆分成不同的子模塊。 按角色劃分 這個比較適用於基礎服務類的場景：一個大系統，每個服務看起來關聯都很緊密，存在相互的調用關係。這時候可以考慮 ...
一般系統的服務劃分有以下兩種維度：
按模塊劃分
這個比較適用於偏業務的場景：複雜的系統，最好先按業務領域橫向拆分成可獨立部署的子系統，每個子系統內部再按技術縱向拆分成不同的子模塊。
按角色劃分
這個比較適用於基礎服務類的場景：一個大系統，每個服務看起來關聯都很緊密，存在相互的調用關係。這時候可以考慮它們各自承擔的角色和使命。
核心原則
單一職責：能不能用一句話說清楚這個服務的職責？非要分成兩句話，那就分成兩個服務。
在核心原則的基礎上，符合下麵的原則是一個比較好的實踐：
鬆散耦合原則
可復用性原則
服務自治原則
可發現性原則
可組合性原則
服務自治、可發現性相對難理解一些，展開一下。
服務自治
當一個服務的邏輯單元由自身的領域邊界內所控制，不受其他外界條件的影響（外界條件帶有不可預測性），且運行環境是自身可控，完全自給自足，我們認為這個服務是自治的。
自治的服務自身可以很好的對穩定性做把控。
可發現性
因為服務是被用來複用的，如果在服務設計過程中，並不能發現一個已經存在的服務，而需要重新建立多個同樣邏輯元旦的服務，會極大增加管理和維護成本。
服務發現主要有兩種：
1.設計時發現（人）
服務設計人員和研發人員在研發一個新的服務時，可以通過搜索服務倉庫的元數據信息，查看服務倉庫是否已存在此服務，沒有才重新開發。
2.運行時發現(程式)
服務的消費者可以通過服務註冊中心查到特定服務的介面調用地址調用。
要根據系統的規模和人員配置情況。
比如如果系統一個系統的日活躍用戶在萬級和千萬級，粒度肯定是不一樣的。同樣，基於系統規模帶來的產出，那麼開發人員數量也會相應不同。比較好的一個實踐是一個人獨立負責一個到兩個服務。多人維護一個服務，交互成本非常高。
關註靜兒公眾號，不定期漫畫技術推送~
