初始微服務（一）

隨着互聯網技術的快速發展，一些傳統的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——也就是說微服務團隊是圍繞着微服務產品進行組織的，團隊內部人員要負責架構設計、開發、評審、測試、部署、運行和支持，整個造成端到端的閉環，快速響應業務需求。

未完待續。。。