分散式微服務架構體系該怎麼建？

微服務架構的演變

微服務架構的技術體系、社群目前已經越來越成熟。在最初系統架構的搭建，或者當現有架構已到達瓶頸需要進行架構演進時，很多架構師、運維工程師會考慮是否需要搭建微服務架構體系。雖然很多文章都說微服務架構是複雜的、會帶來很多分散式的問題，但只要我們瞭解這些問題，並找到解法，就會有種撥開雲霧的感覺。

微服務架構也不是完美的，世上沒有完美的架構，微服務架構也是隨著業務、團隊成長而不斷演進的。最開始可能就幾個、十幾個微服務，每個服務是分庫的，通過 API Gateway 並行進行服務資料合併、轉發。隨著業務擴大、不斷地加入搜尋引擎、快取技術、分散式訊息佇列、資料儲存層的資料複製、分割槽、分表等。

微服務是一種服務間鬆耦合的、每個服務之間高度自治並且使用輕量級協議進行通訊的可持續整合部署的分散式架構體系。這一句包含了微服務的特點，微服務架構和其他架構有什麼區別？以下對比一些常見的架構。

單體架構

單體架構是最簡單的軟體架構，常用於傳統的應用軟體開發以及傳統 Web 應用。傳統 Web 應用，一般是將所有功能模組都打包（jar、war）在一個 Web 容器（JBoss、Tomcate）中部署、執行。隨著業務複雜度增加、技術團隊規模擴大，在一個單體應用中維護程式碼，會降低開發效率，即使是處理一個小需求，也需要將所有機器上的應用全部部署一遍，增加了運維的複雜度。

SOA 架構

當某一天使用單體架構發現很難推進需求的開發、以及日積月累的技術債時，很多企業會開始做單體服務的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一個應用拆成鬆耦合的多個獨立的應用，讓應用可以獨立部署，有獨立的團隊進行維護；水平拆分是把一些通用的，會被很多上層服務呼叫的模組獨立拆分出去，形成一個共享的基礎服務，這樣拆分可以對一些效能瓶頸的應用進行單獨的優化和運維管理，也在一定程度上防止了垂直拆分的重複造輪子。

SOA 也叫面向服務的架構，從單體服務到 SOA 的演進，需要結合水平拆分及垂直拆分。SOA 強呼叫統一的協議進行服務間的通訊，服務間執行在彼此獨立的硬體平臺但是需通過統一的協議介面相互協作，也即將應用系統服務化。舉個易懂的例子，單體服務如果相當於一個快餐店，所有的服務員職責都是一樣的，又要負責收銀結算，又要負責做漢堡，又要負責端盤子，又要負責打掃，服務員之間不需要有交流，使用者來了後，服務員從前到後負責到底。SOA 相當於讓服務員有職責分工，收銀員負責收銀，廚師負責做漢堡，保潔阿姨負責打掃等，所有服務員需要用同一種語言交流，方便工作協調。

微服務和 SOA

微服務也是一種服務化，不過其和 SOA 架構的服務化概念也是有區別的，可以從以下幾個關鍵字來理解：

鬆耦合：每個微服務內部都可以使用 DDD（領域驅動設計）的思想進行設計領域模型，服務間儘量減少同步的呼叫，多使用訊息的方式讓服務間的領域事件來進行解耦。 
輕量級協議：Dubbo 是 SOA 的開源的標準實現之一，類似的還有像 gRPC、Thrift 等。微服務更傾向於使用 Restful 風格的 API，輕量級的協議可以很好得支援跨語言開發的服務，可能有的微服務用 Java 語言實現，有的用 Go 語言，有的用 C++，但所有的語言都可以支援 Http 協議通訊，所有的開發人員都能理解 Restful 風格 API 的含義。 
高度自治和持續整合：從底層的角度來說，SOA 更加傾向於基於虛擬機器或者伺服器的部署，每個應用都部署在不同的機器上，一般持續整合工具更多是由運維團隊寫一些 Shell 指令碼以及提供基於共同協議（比如 Dubbo 管理頁面）的開發部署頁面。微服務可以很好得和容器技術結合，容器技術比微服務出現得晚，但是容器技術的出現讓微服務的實施更加簡便，目前 Docker 已經成為很多微服務實踐的基礎容器。因為容器的特色，所以一臺機器上可以部署幾十個、幾百個不同的微服務。如果某個微服務流量壓力比其他微服務大，可以在不增加機器的情況下，在一臺機器上多分配一些該微服務的容器例項。同時，因為 Docker 的容器編排社群日漸成熟，類似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續整合部署的技術選擇。

其實從架構的演進的角度來看，整體的演進都是朝著越來越輕量級、越來越靈活的應用方向發展，甚至到近兩年日漸成熟起來的 Serverless（無服務）架構。從單體服務到分層的服務，再到面向服務、再到微服務甚至無服務，對於架構的挑戰是越來越大。

微服務中的分散式

微服務架構屬於分散式系統嗎？答案是肯定的。微服務和 SOA 都是典型的分散式架構，只不過微服務的部署粒度更細，服務擴充套件更靈活。

怎樣理解微服務中的分散式？舉一個招聘時一個同學來面試的例子。A 同學說，目前所在公司在做從單應用到微服務架構遷移的工作，已經差不多完成了。提到微服務感覺就有話題聊了，於是便問：“是否可以簡單描述下服務拆分後的部署結構、底層儲存的拆分、遷移方案？”於是 A 同學說，只是做了程式碼工程結構的拆分，還是原來的部署方式，資料庫還是那個庫，所有的微服務都用一個庫，分散式事務處理方式是“避免”，儘量都同步呼叫……於是我就跟這位同學友好地微笑說再見了。

微服務的分散式不僅僅是容器應用層面的分散式，其為了高度自治，底層的儲存體系也應該互相獨立，並且也不是所有的微服務都需要持久化的儲存服務。一個“手機驗證碼”微服務可能底層儲存只用一個 Redis；一個“營銷活動搭建頁面”微服務可能底層儲存只需要一個 MongoDB。

微服務中的分散式場景除了服務本身需要有服務發現、負載均衡，微服務依賴的底層儲存也會有分散式的場景：為了高可用性和效能需要處理資料庫的複製、分割槽，並且在儲存的分庫情況下，微服務需要能保證分散式事務的一致性。

如何學習分散式微服務架構體系

微服務架構的技術體系、社群目前已經越來越成熟，所以在初期選擇使用或者企業技術體系轉型微服務的時候，需要了解微服務架構中的分散式的問題：

• 在所有服務都是更小單元的部署結構時，一個請求需要調動更多的服務資源，怎樣獲得更好的效能？
• 當業務規模增大，需要有地理分佈不同的微服務叢集時，其底層的資料儲存叢集是多資料中心還是單資料叢集？ 資料儲存如何進行資料複製？
• 業務資料達到大資料量時怎樣進行資料的分割槽？ 分散式事務怎樣保證一致性？ 不同程度的一致性有什麼差別？ 基於容器技術的服務發現怎麼處理？
• 應該用哪些 RPC 技術，用哪些分散式訊息佇列來完成服務通訊和解耦？ 那麼多的分散式技術框架、演算法、服務應該選哪個才適合企業的業務場景？

《分散式微服務架構體系詳解》從微服務不得不面對和解決的分散式問題出發，包含分散式技術的一系列理論以及架構模型、演算法的介紹，同時結合技術選型和實踐應用，提供一系列解決方案的梳理。相信閱讀完整個課程，你會對微服務的分散式問題有個系統地理解。本課程會對微服務的分散式場景問題一一擊破，為你提供解決思路。並且，本課程通過對分散式問題的體系化梳理，結合一些方案的對比選型，可以讓工程師們一覽微服務的知識圖譜。

如果你是一位開發工程師，相信閱讀完本系列課程，將會了解很多分散式系統的理論知識，同時也會理解一些分散式儲存、中介軟體技術的原理，對工作中的分散式架構會有體系化的清晰認知。 
如果你是一位架構師，本系列課程提供了對於分散式系統問題的全面梳理，以及一些技術背後的理論，結合實踐和目前業界先進的方案，對於技術選型和架構搭建提供了參考。