微服務(wù)架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來越成熟。在最初系統(tǒng)架構(gòu)的搭建，或者當(dāng)現(xiàn)有架構(gòu)已到達瓶頸需要進行架構(gòu)演進時，很多架構(gòu)師、運維工程師會考慮是否需要搭建微服務(wù)架構(gòu)體系。雖然很多文章都說微服務(wù)架構(gòu)是復(fù)雜的、會帶來很多分布式的問題，但只要我們了解這些問題，并找到解法，就會有種撥開云霧的感覺。
微服務(wù)架構(gòu)也不是完美的，世上沒有完美的架構(gòu)，微服務(wù)架構(gòu)也是隨著業(yè)務(wù)、團隊成長而不斷演進的。最開始可能就幾個、十幾個微服務(wù)，每個服務(wù)是分庫的，通過 API Gateway 并行進行服務(wù)數(shù)據(jù)合并、轉(zhuǎn)發(fā)。隨著業(yè)務(wù)擴大、不斷地加入搜索引擎、緩存技術(shù)、分布式消息隊列、數(shù)據(jù)存儲層的數(shù)據(jù)復(fù)制、分區(qū)、分表等。
微服務(wù)是一種服務(wù)間松耦合的、每個服務(wù)之間高度自治并且使用輕量級協(xié)議進行通信的可持續(xù)集成部署的分布式架構(gòu)體系。這一句包含了微服務(wù)的特點，微服務(wù)架構(gòu)和其他架構(gòu)有什么區(qū)別？以下對比一些常見的架構(gòu)。
單體架構(gòu)是最簡單的軟件架構(gòu)，常用于傳統(tǒng)的應(yīng)用軟件開發(fā)以及傳統(tǒng) Web 應(yīng)用。傳統(tǒng) Web 應(yīng)用，一般是將所有功能模塊都打包（jar、war）在一個 Web 容器（JBoss、Tomcate）中部署、運行。隨著業(yè)務(wù)復(fù)雜度增加、技術(shù)團隊規(guī)模擴大，在一個單體應(yīng)用中維護代碼，會降低開發(fā)效率，即使是處理一個小需求，也需要將所有機器上的應(yīng)用全部部署一遍，增加了運維的復(fù)雜度。
當(dāng)某一天使用單體架構(gòu)發(fā)現(xiàn)很難推進需求的開發(fā)、以及日積月累的技術(shù)債時，很多企業(yè)會開始做單體服務(wù)的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一個應(yīng)用拆成松耦合的多個獨立的應(yīng)用，讓應(yīng)用可以獨立部署，有獨立的團隊進行維護；水平拆分是把一些通用的，會被很多上層服務(wù)調(diào)用的模塊獨立拆分出去，形成一個共享的基礎(chǔ)服務(wù)，這樣拆分可以對一些性能瓶頸的應(yīng)用進行單獨的優(yōu)化和運維管理，也在一定程度上防止了垂直拆分的重復(fù)造輪子。
SOA 也叫面向服務(wù)的架構(gòu)，從單體服務(wù)到 SOA 的演進，需要結(jié)合水平拆分及垂直拆分。SOA 強調(diào)用統(tǒng)一的協(xié)議進行服務(wù)間的通信，服務(wù)間運行在彼此獨立的硬件平臺但是需通過統(tǒng)一的協(xié)議接口相互協(xié)作，也即將應(yīng)用系統(tǒng)服務(wù)化。舉個易懂的例子，單體服務(wù)如果相當(dāng)于一個快餐店，所有的服務(wù)員職責(zé)都是一樣的，又要負責(zé)收銀結(jié)算，又要負責(zé)做漢堡，又要負責(zé)端盤子，又要負責(zé)打掃，服務(wù)員之間不需要有交流，用戶來了后，服務(wù)員從前到后負責(zé)到底。SOA 相當(dāng)于讓服務(wù)員有職責(zé)分工，收銀員負責(zé)收銀，廚師負責(zé)做漢堡，保潔阿姨負責(zé)打掃等，所有服務(wù)員需要用同一種語言交流，方便工作協(xié)調(diào)。
微服務(wù)也是一種服務(wù)化，不過其和 SOA 架構(gòu)的服務(wù)化概念也是有區(qū)別的，可以從以下幾個關(guān)鍵字來理解：
松耦合：每個微服務(wù)內(nèi)部都可以使用 DDD（領(lǐng)域驅(qū)動設(shè)計）的思想進行設(shè)計領(lǐng)域模型，服務(wù)間盡量減少同步的調(diào)用，多使用消息的方式讓服務(wù)間的領(lǐng)域事件來進行解耦。 輕量級協(xié)議：Dubbo 是 SOA 的開源的標準實現(xiàn)之一，類似的還有像 gRPC、Thrift 等。微服務(wù)更傾向于使用 Restful 風(fēng)格的 API，輕量級的協(xié)議可以很好得支持跨語言開發(fā)的服務(wù)，可能有的微服務(wù)用 Java 語言實現(xiàn)，有的用 Go 語言，有的用 C++，但所有的語言都可以支持 Http 協(xié)議通信，所有的開發(fā)人員都能理解 Restful 風(fēng)格 API 的含義。 高度自治和持續(xù)集成：從底層的角度來說，SOA 更加傾向于基于虛擬機或者服務(wù)器的部署，每個應(yīng)用都部署在不同的機器上，一般持續(xù)集成工具更多是由運維團隊寫一些 Shell 腳本以及提供基于共同協(xié)議（比如 Dubbo 管理頁面）的開發(fā)部署頁面。微服務(wù)可以很好得和容器技術(shù)結(jié)合，容器技術(shù)比微服務(wù)出現(xiàn)得晚，但是容器技術(shù)的出現(xiàn)讓微服務(wù)的實施更加簡便，目前 Docker 已經(jīng)成為很多微服務(wù)實踐的基礎(chǔ)容器。因為容器的特色，所以一臺機器上可以部署幾十個、幾百個不同的微服務(wù)。如果某個微服務(wù)流量壓力比其他微服務(wù)大，可以在不增加機器的情況下，在一臺機器上多分配一些該微服務(wù)的容器實例。同時，因為 Docker 的容器編排社區(qū)日漸成熟，類似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續(xù)集成部署的技術(shù)選擇。
其實從架構(gòu)的演進的角度來看，整體的演進都是朝著越來越輕量級、越來越靈活的應(yīng)用方向發(fā)展，甚至到近兩年日漸成熟起來的 Serverless（無服務(wù)）架構(gòu)。從單體服務(wù)到分層的服務(wù)，再到面向服務(wù)、再到微服務(wù)甚至無服務(wù)，對于架構(gòu)的挑戰(zhàn)是越來越大。
微服務(wù)架構(gòu)屬于分布式系統(tǒng)嗎？答案是肯定的。微服務(wù)和 SOA 都是典型的分布式架構(gòu)，只不過微服務(wù)的部署粒度更細，服務(wù)擴展更靈活。
怎樣理解微服務(wù)中的分布式？舉一個招聘時一個同學(xué)來面試的例子。A 同學(xué)說，目前所在公司在做從單應(yīng)用到微服務(wù)架構(gòu)遷移的工作，已經(jīng)差不多完成了。提到微服務(wù)感覺就有話題聊了，于是便問：“是否可以簡單描述下服務(wù)拆分后的部署結(jié)構(gòu)、底層存儲的拆分、遷移方案？”于是 A 同學(xué)說，只是做了代碼工程結(jié)構(gòu)的拆分，還是原來的部署方式，數(shù)據(jù)庫還是那個庫，所有的微服務(wù)都用一個庫，分布式事務(wù)處理方式是“避免”，盡量都同步調(diào)用……于是我就跟這位同學(xué)友好地微笑說再見了。
微服務(wù)的分布式不僅僅是容器應(yīng)用層面的分布式，其為了高度自治，底層的存儲體系也應(yīng)該互相獨立，并且也不是所有的微服務(wù)都需要持久化的存儲服務(wù)。一個“手機驗證碼”微服務(wù)可能底層存儲只用一個 Redis；一個“營銷活動搭建頁面”微服務(wù)可能底層存儲只需要一個 MongoDB。
微服務(wù)中的分布式場景除了服務(wù)本身需要有服務(wù)發(fā)現(xiàn)、負載均衡，微服務(wù)依賴的底層存儲也會有分布式的場景：為了高可用性和性能需要處理數(shù)據(jù)庫的復(fù)制、分區(qū)，并且在存儲的分庫情況下，微服務(wù)需要能保證分布式事務(wù)的一致性。
微服務(wù)架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來越成熟，所以在初期選擇使用或者企業(yè)技術(shù)體系轉(zhuǎn)型微服務(wù)的時候，需要了解微服務(wù)架構(gòu)中的分布式的問題：
《分布式微服務(wù)架構(gòu)體系詳解》從微服務(wù)不得不面對和解決的分布式問題出發(fā)，包含分布式技術(shù)的一系列理論以及架構(gòu)模型、算法的介紹，同時結(jié)合技術(shù)選型和實踐應(yīng)用，提供一系列解決方案的梳理。相信閱讀完整個課程，你會對微服務(wù)的分布式問題有個系統(tǒng)地理解。本課程會對微服務(wù)的分布式場景問題一一擊破，為你提供解決思路。并且，本課程通過對分布式問題的體系化梳理，結(jié)合一些方案的對比選型，可以讓工程師們一覽微服務(wù)的知識圖譜。
