隨著網際網路技術的快速發展，一些傳統的IT系統支撐遇到了越來越多的問題：

• 系統的複雜性越來越高
• 線上訪問壓力大，交付速度無法滿足業務需求
• 裝置採購和維護成本高，測試、部署成本高
• IT運維管理複雜，構建一隻全功能團隊困難

針對上述問題，傳統的單體結構已經不再適用於複雜度日益漸增的產品，因此一種新的軟體架構提供瞭解決方案——微服務。

什麼是微服務

微服務架構是一種架構風格，就如MVC、分層架構一般，它有六個特點：

• 一組小的服務：原來單塊架構將所有的業務能力打包在一個單塊應用當中的，而微服務主張將這些單塊應用拆成一個個小的獨立的服務。
• 獨立的程式：正如Java應用程式可以部署在Tomcat容器中，容器本身也是一個獨立的程式，微服務可以部署在容器中，容器可以部署在物理機上 ，以程式的方式去橫向擴充套件微服務
• 輕量級通訊：主張輕量級協議，如http
• 基於業務能力構建微服務
• 獨立部署：微服務拆分後由每個團隊各自維護，可以獨立進行開發、演化、部署，各部門之間不需要太多的協調，大大提高的團隊的迭代效率。
• 無集中式管理：原來的架構是有獨立的架構團隊制定標準，統一技術棧、統一儲存方式。而微服務架構則主張每個團隊選擇其最能解決當前問題的技術棧及儲存機制。

用一句話來概括微服務就是基於有界上下文的（區域性狀態，每個團隊可以維護自己的資料來源，服務演化速度比較快，對服務支援更敏捷），鬆散耦合（服務之間不能強依賴）的面向服務的架構。

微服務優缺點

架構最重要的職責就是權衡，瞭解微服務的優缺點才能更好地使用微服務。

優勢

• 強模組化邊界：元件、類庫以服務的方式進行呼叫，可以直接呼叫服務，而不需要引入包（程式實體）

• 可獨立部署：各團隊可單獨對服務進行維護部署，不需要涉及其他團隊進行協同

• 技術多樣性：分散式治理，各團隊可根據業務實際情況選擇最優技術棧

弊端

• 分散式複雜性：服務之間相互溝通協作實現業務功能，清晰理解整個完整架構的難度上升

• 最終一致性：需要維護不同資料來源的狀態同步問題

• 運維複雜性：運維團隊需要引入監控、進行容量規劃以保證服務的可靠性、穩定性，運維難度上升

• 測試複雜性：各服務分散在各個團隊，一個完整的業務功能測試可能需要很多團隊聯合測試

微服務不是銀彈，如果一個單塊應用尚且搞不定，更別指望微服務能拯救你。

康威法則與微服務的關係

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

上述這句話的意思是設計系統的組織，其產生的架構設計等價於組織間的溝通結構。因此技術架構和組織架構的關係是強相關的，這也解釋了為什麼單塊應用隨著系統複雜性越來越高變得不再適用。

在業務初期，開發的系統是簡單的單塊應用，但隨著業務量變大，團隊規模變大，單塊應用架構和多團隊之間產生了不匹配的情況，也就是違反了康威法則。

什麼時間段引入微服務

在瞭解康威法則後，什麼時候是引入微服務架構是最優時間點呢，是越早引入越好嗎？

答案當然不是。通常情況下，業務初期開發的系統只是為了驗證商業模式，並不是很複雜，因此並不推薦一開始使用微服務。

微服務適用性

下面這張圖表的橫座標表示生產力，縱座標表示系統複雜性，很準確地描述了微服務的適用性。

微服務有基礎設施要求需要一定的前期投資，而單塊應用不需要很大投入就能交付基礎功能。

隨著業務量變大，團隊規模和單塊應用的矛盾凸顯違反了康威法則，生產力會隨著業務複雜性下降，這時候要考慮微服務解決問題的交叉點（這個交叉點意味著單塊應用已不再合適，這個時間點的確定需要架構師綜合權衡）

單塊優先

上述這張圖表很清楚的展示了架構是通過設計出來和還是演化出來的兩個過程。

在業務初期，架構師還對業務問題的領域模型不清晰，一開始直接採用微服務架構進行服務拆分是冒險的。

而如果一開始就採用單塊應用的模式，隨著業務的發展，架構師對業務問題領域模型越來越清晰，這個時候就能準確地找到系統的瓶頸對功能模組進行合理拆分。

微服務組織架構

康威法則是微服務的組織原理，因此可以說微服務架構本質上是組織架構的重組，那麼什麼樣的組織架構更適合微服務架構？

首先來看看傳統企業中是如何組織團隊的，下面這個圖表為傳統職能型的團隊架構，橫座標標識業務價值流的交付過程，一般來說一個業務需求先由產品開始到研發到DBA最後上線運維，縱座標表示業務能力，在傳統的企業當中團隊劃分方式是嚴格按照職能的。當有專案的時候，會從各個職能團隊進行抽調組成交付團隊，等到專案完成後再回歸各自的職能團隊。這種傳統的職能劃分團隊的方式有兩個缺點：

• 溝通協調成本高，價值流從一個團隊到另一個團隊傳遞的過程中需要進行很多溝通協調工作

• 問題反饋不及時，反饋週期長，研發效率低下，對業務支援慢

在微服務模式下，需要一種新型的組織架構方式——基於微服務的跨職能的組織架構。

每個業務線的團隊組織方式不再是嚴格的按職能劃分，而是跨職能模式，一個團隊包括各職能的專家，團隊內部形成閉環，圍繞微服務進行開發測試和交付。

而DBA、運維團隊則把計算、網路儲存等持續交付能力封裝成一個平臺產品，以API呼叫的形式提供給不同業務線快速交付迭代。

who builds it, who run it——也就是說微服務團隊是圍繞著微服務產品進行組織的，團隊內部人員要負責架構設計、開發、評審、測試、部署、執行和支援，整個形成端到端的閉環，快速響應業務需求。

未完待續。。。