近幾年，微服務架構迅速在整個技術社群竄紅，它被認為是IT軟體架構的未來方向，大神Martin Fowler也給微服務極高的評價。那為什麼我們需要微服務，微服務的真正優勢到底是什麼，一個完整的微服務系統，應該包含哪些功能，本文作者劉彥夫在軟體設計和開發領域有10多年工作經驗，他將會從他的角度給出答案。

對微服務的基本理解

顧名思義，微服務要從兩個方面來理解，一個是“微”，一個是“服務”。體型小到一定程度才能叫“微”，這個程度是什麼呢？一個身高1米6，體重90斤的MM，我們說她苗條。微服務也一樣，根據亞馬遜CEO Bezos給出的有趣定義，單個微服務的設計、開發、測試和運維的所有人加在一起吃飯，只需要兩個批薩就夠了，這是就是著名的two pizza team rule。

具備什麼樣的能力才能算是“服務”？這個話題很大，我這裡按照自己的片面理解總結一下，所謂服務就一定會區別於系統的功能，服務是一個或者一組相對的較小且獨立的功能單元，是使用者可以感知的功能最小集，比如：購物車，訂單，信用卡結算等都可以作為單個服務獨立提供。

這個理解顯然不夠深刻，為了進一步理解為什麼微服務在近兩年業界迅速竄紅，理解為什麼微服務會被認為是IT軟體架構的未來方向，就要理解為什麼我們需要微服務？它能給企業帶來什麼價值。傳統企業的IT軟體大多都是各種獨立系統的堆砌，這些系統的問題總結來說就是擴充套件性差，可靠性不高，維護成本高。後來有了一個叫SOA的軟體架構專門針對這些問題給出了一套解決方案，很多企業也因此將自身IT系統遷移到SOA架構上。

但是，由於SOA早期均使用了匯流排模式，這種匯流排模式是與某種技術棧強繫結的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間。最終SOA開起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。

依然SOA

微服務，從本質意義上看，還是SOA架構。但內涵有所不同，微服務並不繫結某種特殊的技術，在一個微服務的系統中，可以有Java編寫的服務，也可以有Python編寫的服務，他們是靠Restful架構風格統一成一個系統的。

最粗淺的理解就是將微服務之間的互動看作是各種字串的傳遞，各種語言都可以很好的處理字串，所以微服務本身與具體技術實現無關，擴充套件性強。另一個不同是微服務架構本身很輕，底層也有類似於SOA的匯流排，不過非常輕薄，現在看到的就兩種方式：MQ和HTTP，而HTTP都不能完全等同於匯流排，而僅僅是個資訊通道。

所以，基於這種簡單的的協議規範，無論是相容老舊系統，還是上線新業務，都可以隨著時代的步伐，滾動升級。比如：你去年還在使用.NET技術，今年就可以平滑的過度到Go了，而且系統已有服務不用改動。所以微服務架構，既保護使用者已有投資，又很容易向新技術演進。

微服務水下的冰山

人月不是銀彈，微服務更不是銀彈，好像軟體微服務化了，軟體系統就能夠應對各種問題了。其實微服務的水面下藏著巨大的冰山。下面是微服務提供的能力，以及背後需要付出的代價。

1. 單個微服務程式碼量小，易修改和維護。但是，系統複雜度的總量是不變的，每個服務程式碼少了，但服務的個數肯定就多了。就跟拼圖遊戲一樣，切的越碎，越難拼出整幅圖。一個系統被拆分成零碎的微服務，最後要整合為一個完整的系統，其複雜度肯定比大塊的功能整合要高很多。

2. 單個微服務資料獨立，可獨立部署和執行。雖然微服務本身是可以獨立部署和執行的，但仍然避免不了業務上的你來我往，這就涉及到要對外通訊，當微服務的數量達到一定量級的時候，如何提供一個高效的叢集通訊機制成為一個問題。

3. 單個微服務擁有自己的程序，程序本身就可以動態的啟停，為無縫升級的打好了基礎，但誰來啟動和停止程序，什麼時機，選擇在哪臺裝置上做這件事情才是無縫升級的關鍵。這個能力並不是微服務本身提供的，而是需要背後強大的版本管理和部署能力。

4. 多個相同的微服務可以做負載均衡，提高效能和可靠性。正是因為相同微服務可以有多個不同例項，讓服務按需動態伸縮成為可能，在高峰期可以啟動更多的相同的微服務例項為更多使用者服務，以此提高響應速度。同時這種機制也提供了高可靠性，在某個微服務故障後，其他相同的微服務可以接替其工作，對外表現為某個裝置故障後業務不中斷。同樣的道理，微服務本身是不會去關心繫統負載的，那麼什麼時候應該啟動更多的微服務，多個微服務的流量應該如何排程和分發，這背後也有一套複雜的負載監控和均衡的系統在起作用。

5. 微服務可以獨立部署和對外提供服務，微服務的業務上線和下線是動態的，當一個新的微服務上線時，使用者是如何訪問到這種新的服務？這就需要有一個統一的入口，新的服務可以動態的註冊到這個入口上，使用者每次訪問時可以從這個入口拿到系統所有服務的訪問地址，類似於到餐廳吃飯，新菜要寫到“選單”中，以供使用者選擇。這個統一的系統入口並不是微服務本身的一部分，所以這種能力需要系統單獨提供。

6. 還有一些企業級關注的系統問題，比如，安全策略如何集中管理？系統故障如何快速審計和跟蹤到具體服務？整個系統狀態如何監控？服務之間的依賴關係如何管理？等等這些問題都不是單個微服務考慮的範疇，而需要有一個系統性的考慮和設計，讓每個微服務都能夠按照系統性的要求和約束提供對應的安全性，可靠性，可維護性的能力。

綜上所述，微服務關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、執行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“鬆耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的介面，統一的許可權管理，統一的安全策略，統一的上線過程，統一的日誌和審計方法，統一的排程方式，統一的訪問入口等等。

這些系統性的功能也需要有一些服務來提供，這些服務不會直接呈現給終端使用者，也就是微服務系統冰山下面的部分，我們可以簡稱它為微服務系統的“底座”。所有的微服務都像一個APP，插在這個底座的上面，享受這個底座提供的系統能力比如：元資料存放、灰度釋出、藍綠部署等等。

微服務系統底座

一個完整的微服務系統，它的底座最少要包含以下功能：

• 日誌和審計，主要是日誌的彙總，分類和查詢

• 監控和告警，主要是監控每個服務的狀態，必要時產生告警

• 訊息匯流排，輕量級的MQ或HTTP

• 註冊發現

• 負載均衡

• 部署和升級

• 事件排程機制

• 資源管理，如：底層的虛擬機器，物理機和網路管理

以下功能不是最小集的一部分，但也屬於底座功能：

• 認證和鑑權

• 微服務統一程式碼框架，支援多種程式語言

• 統一服務構建和打包

• 統一服務測試

• 微服務CI/CD流水線

• 服務依賴關係管理

• 統一問題跟蹤除錯框架，俗稱呼叫鏈

• 灰度釋出

• 藍綠部署

  令人困惑的幾個問題

微服務的底座是不是必須的？

是的，基本上是必須的。你可以不用程式碼實現一個資源管理服務，可以手工用Excel管理你的所有機器資源，但是不代表微服務系統沒有這個功能，只不過這個功能是人工實現的。再舉個例子，日誌系統如果只是簡單的列印檔案，那麼多個微服務的日誌就需要手工收集，人工分類和篩選。所以，微服務的底座最小集一定會存在，問題是看怎樣實現它。

這裡僅僅是總結了對微服務系統的基本理解，而實現這個架構有很多技術，這裡不進行詳細展開。實踐方面，推薦王磊的《微服務架構與實踐》，他描述了使用Ruby相關的技術實現了一整套微服務系統，特別是書中後面的實踐部分講解了如何將已有的系統演化為微服務架構，是很好的參考和指導材料。

是不是所有軟體都能做微服務？

這個命題有些微妙，也很難說清楚，回答這個命題本身就是一種挑戰，可能最終也沒有正確答案。不過，我還是把我自己的理解寫在這裡，讓大家去拍磚。在我這裡，答案是否定的。我只需舉出一個反例，比如：儲存系統，其架構是傳統的分層架構，每一層都使用下面一層的服務，併為上一層提供服務。雖然可以將這種架構調整為基於服務的架構，但沒辦法做成微服務。

區別在哪裡呢？核心的區別在於獨立性上，微服務大多是可以獨立的執行和使用的，而儲存這種非常底層和基礎的系統，每層部件都不能單獨被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS檔案系統，這些功能都無法離開另外一些功能而獨立執行，要對外提供可用的儲存功能，一大堆功能必須一起上。這種系統做到極致，最多也就能夠使其部件可以獨立的部署和升級，俗稱打熱補丁。

這也就是為什麼這種底層傳統系統架構通常是單塊架構的原因。由於單塊架構的各個部分呼叫關係緊密，做成微服務後系統整合成本會大大增加，不僅如此，這樣的架構做成微服務並不能提高交付效率，因為各個部分根本就無法獨立的執行和測試。

什麼樣的軟體做成微服務？

能不能做成微服務，取決於四個要素：

• 小：微服務體積小，2 pizza團隊。

• 獨：能夠獨立的部署和執行。

• 輕：使用輕量級的通訊機制和架構。

• 鬆：為服務之間是鬆耦合的。

針對於小、輕、鬆都是可以通過某些技術手段達到目的，而獨立的部署和執行，則是和業務本身有關係，如果你這個系統提供的業務是貼近終端使用者的，並且這些功能之間的耦合性很小，則微服務就可以按照業務功能本身的獨立性來劃分，則這類系統做成微服務是非常合適的。如果系統提供的業務是非常底層的，如：作業系統核心、儲存系統、網路系統、資料庫系統等等，這類系統都偏底層，功能和功能之間有著緊密的配合關係，如果強制拆分為較小的服務單元，會讓整合工作量急劇上升，並且這種人為的切割無法帶來業務上的真正的隔離，所以無法做到獨立部署和執行，也就更加無法做到真正的微服務了。