微服務架構給我們帶來收益的同時，也會帶來副作用，我們應該在什麼階段採用微服務架構？如何拆分微服務架構？拆分粒度多大比較合適？本文內容從問題開始，帶你深入微服務架構的多個角落。

1 單體架構與微服務架構

就像很難用一個絕對的方式去判斷架構好壞一樣，在大多數場景下，我們也很難從一個外部的視角去判斷服務拆分粒度的合理性，需要對上下文非常瞭解才能做出一個好決策。例如，團隊規模多大，代碼規模多大，有沒有平臺化，有沒有工具鏈，是否需要持續交付，團隊文化如何等。因此，一個外部的架構師是很難在短時間內將架構規劃合理的，這需要一個過程，當真正瞭解這一切之後，不斷權衡才能最終確定。在規劃之前，有必要參考下面這張表，綜合各方面的情況，最終做出決策。

單體架構與微服務架構對比

2 什麼時候開始微服務架構

產品初期優先選擇單體架構。面對一個新的領域，對業務的理解很難在開始階段就比較清晰，往往是經過一段時間之後，才能逐步弄清楚。很多時候，從一個已有的單體架構中逐步劃分服務，要比一開始就構建微服務簡單得多。另外，在資源受限的情況下，採用微服務架構風險較大，很多優勢無法體現，性能上的劣勢反而會比較明顯。

單體、組件化、微服務架構成本趨勢，如下圖。當業務複雜度達到一定程度後，微服務架構消耗的成本才會體現優勢，並不是所有的場景都適合採用微服務架構，服務的劃分應逐步進行，持續演進。產品初期業務複雜度不高的時候，應該儘量採用單體架構。

單體、組件化、微服務架構成本趨勢

摘自Martin Fowler 博客的內容簡單翻譯如下。

當我聽到關於使用微服務架構的故事的時候，我注意到了一種通用的模式。

1．幾乎所有成功的微服務架構都是從一個巨大的單體架構開始的，並且都是由於單體架構太大而被拆分為微服務架構。

2．幾乎在所有我聽說過從一開始就構建為微服務架構的故事中，最終都有人遇到了巨大的麻煩。

在服務劃分之前，應該保證基礎設施及公共基礎服務已經準備完畢。可以通過監控快速定位故障，通過工具自動化部署、管理服務，通過服務化框架降低服務開發的複雜度，通過灰度發佈提升可用性，通過資源調度服務快速申請、釋放資源，通過彈性伸縮快速擴展應用。

3 如何決定微服務架構的拆分粒度

微服務架構中的微字，並不代表足夠小，應該解釋為合適。但是“合適”過於含糊，每個人理解的合適都不盡相同。實際上，有時候對於一個對業務理解不夠深入，對團隊情況又不是很瞭解的人，根本無權協助確定服務的粒度。況且，就算本團隊的架構師，也很難確定粒度。隨著業務發展，開發人員水平的提升，粒度可能會發生變化。這是一個磨合的過程，一個不斷演進的過程，沒有絕對的對與錯。

如果實在找不到合適的依據，可以參考下表。決策佔比是從通用的角度考慮，並不適用所有的情況，某些公司認為團隊規模是決定性的，也有些公司認為架構演進是決定性的，還有些公司認為交付速度是決定性的，找到那個你認為的決定性因素，去做合理的拆分即可。

微服務拆分粒度決策參考表

本文選自

作者從全局視角出發，全面闡釋Cloud Native 的關鍵技術，以及其衍生出來的工具、團隊文化等核心要素，對於正在部署微服務架構或開展雲原生業務的企業和組織而言，終於有了面向落地的務實參考和全面指導。

閱讀更多 博文視點Broadview 的文章

關鍵字: 粒度 服務 單體