服務粒度

當團隊實施微服務架構時，可以根據團隊規模來劃分微服務數量。一個團隊約有 6 個人時，可以劃分為 2 個微服務。隨著業務的擴展和團隊規模的增加（例如，擴展到 12 個人），可以將已有的 2 個微服務進一步細分為 4 個微服務。這種基于團隊規模的微服務拆分方法，有助于管理復雜度，保持開發效率。

為什么是 3 個人，不是 4 個或者其他數量呢？

首先，3 個人負責一個系統，每個人都能夠全面理解整個系統，同時又能夠進行分工。如果是 2 個人，系統的復雜度不夠，開發人員可能會感到技術上的挑戰不夠；如果是 4 個人或者更多，系統復雜度可能會導致開發人員無法全面了解系統的細節。

其次，3 個人形成一個穩定的備份，即使其中一個人休假或者調動到其他系統，剩余的 2 個人也可以支撐工作。如果是 2 個人，剩余的 1 個人可能承擔過大壓力；如果是 1 個人，團隊就存在單點故障。

最后，3 個人的技術小組可以形成有效的討論，快速達成一致意見。如果是 2 個人，可能會出現意見不一致的情況；如果是 1 個人，可能會陷入思維盲區；如果是 4 個人或者更多，可能會出現參與度不足的情況。

“三個火槍手”的原則主要適用于微服務設計和開發階段。當微服務經過一段時間發展后，進入維護期，無需太多開發工作時，平均每個微服務維護 1 個人或者幾個微服務都是可以接受的。然而，為了確保人員備份，最好安排每個微服務由 2 個人維護，每個人可以維護多個微服務。

拆分方法

基于業務邏輯拆分：這種方式是將系統中的業務模塊按照職責范圍識別出來，每個單獨的業務模塊拆分為一個獨立的服務。但在實踐過程中最常見的一個問題就是團隊成員對于“職責范圍”的理解差異很大，經常會出現爭論，難以達成一致意見。

基于可擴展拆分：將系統中的業務模塊按照穩定性排序，將已經成熟和改動不大的服務拆分為穩定服務，將經常變化和迭代的服務拆分為變動服務。穩定的服務粒度可以粗一些，即使邏輯上沒有強關聯的服務，也可以放在同一個子系統中。

基于可靠性拆分：將系統中的業務模塊按照優先級排序，將可靠性要求高的核心服務和可靠性要求低的非核心服務拆分開來，然后重點保證核心服務的高可用。具體拆分的時候，核心服務可以是一個也可以是多個，只要最終的服務數量滿足“三個火槍手”的原則就可以。

基于性能拆分：基于性能瓶頸將系統中的業務模塊進行拆分，將性能要求高或者性能壓力大的模塊拆分為獨立的服務。例如，電商系統中，搶購功能可能會導致性能瓶頸，可以將該功能獨立為一個服務。

基礎設施

大多數人關注微服務的“small”和“lightweight”特性，但實際上微服務的成敗更多取決于被忽視的“automated”（自動化）方面。為什么這樣說呢？因為即使服務粒度劃分不合理，當團隊遇到問題時，很自然地會考慮重新拆分或合并服務；但如果與“automated”相關的基礎設施不健全，微服務就會成為一個坑，使得研發、測試和運維陷入各種微服務陷阱中。

微服務基礎設施如下圖所示：

圖片

看到上面這張圖，相信很多人都會倒吸一口涼氣，說好的微服務的“輕量級”呢？都這么多基礎設施還好意思說自己是“輕量級”，感覺比 ESB 還要復雜??？

確實如此，微服務并不是很多人認為的那樣簡單和輕量級。要成功實施微服務，這些基礎設施是必不可少的，否則微服務可能會成為一個難以擺脫的泥潭，使業務和團隊陷入困境。因此，可以說微服務并沒有減少復雜性，而是將復雜性從ESB（企業服務總線）轉移到了基礎設施上。你可以看到，“服務發現”、“服務路由”等實際上都是ESB的功能，只是在微服務中被剝離出來，成為了獨立的基礎系統。

雖然建設完善的微服務基礎設施是一項龐大的工程，但不必因為團隊規模較小或公司規模不大而放棄微服務的實施。首先，開源社區已經提供了一些成熟的微服務基礎設施解決方案，比如知名的 Spring Cloud 項目，包含了服務發現、服務路由、網關、配置中心等功能。其次，如果微服務的數量不是很多，也并非每個基礎設施都是必需的。因此，我建議按照以下優先級來搭建基礎設施：

1. 服務發現、服務路由、服務容錯：這是最基本的微服務基礎設施。

2. 接口框架、API 網關：主要是為了提升開發效率，接口框架是提升內部服務的開發效率，API 網關是為了提升與外部服務對接的效率。

3. 自動化部署、自動化測試、配置中心：主要是為了提升測試和運維效率。

4. 服務監控、服務跟蹤、服務安全：主要是為了進一步提升運維效率。

以上 3 和 4 兩類基礎設施，其重要性會隨著微服務節點數量增加而越來越重要，但在微服務節點數量較少的時候，可以通過人工的方式支撐，雖然效率不高，但也基本能夠頂住。