微服務架構(gòu)的演變

微服務架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來越成熟。在最初系統(tǒng)架構(gòu)的搭建，或者當現(xiàn)有架構(gòu)已到達瓶頸需要進行架構(gòu)演進時，很多架構(gòu)師、運維工程師會考慮是否需要搭建微服務架構(gòu)體系。雖然很多文章都說微服務架構(gòu)是復雜的、會帶來很多分布式的問題，但只要我們了解這些問題，并找到解法，就會有種撥開云霧的感覺。 微服務架構(gòu)也不是完美的，世上沒有完美的架構(gòu)，微服務架構(gòu)也是隨著業(yè)務、團隊成長而不斷演進的。最開始可能就幾個、十幾個微服務，每個服務是分庫的，通過 API Gateway 并行進行服務數(shù)據(jù)合并、轉(zhuǎn)發(fā)。隨著業(yè)務擴大、不斷地加入搜索引擎、緩存技術(shù)、分布式消息隊列、數(shù)據(jù)存儲層的數(shù)據(jù)復制、分區(qū)、分表等。 微服務是一種服務間松耦合的、每個服務之間高度自治并且使用輕量級協(xié)議進行通信的可持續(xù)集成部署的分布式架構(gòu)體系。這一句包含了微服務的特點，微服務架構(gòu)和其他架構(gòu)有什么區(qū)別？以下對比一些常見的架構(gòu)。

單體架構(gòu) 單體架構(gòu)是最簡單的軟件架構(gòu)，常用于傳統(tǒng)的應用軟件開發(fā)以及傳統(tǒng) Web 應用。傳統(tǒng) Web 應用，一般是將所有功能模塊都打包（jar、war）在一個 Web 容器（JBoss、Tomcate）中部署、運行。隨著業(yè)務復雜度增加、技術(shù)團隊規(guī)模擴大，在一個單體應用中維護代碼，會降低開發(fā)效率，即使是處理一個小需求，也需要將所有機器上的應用全部部署一遍，增加了運維的復雜度。

SOA 架構(gòu) 當某一天使用單體架構(gòu)發(fā)現(xiàn)很難推進需求的開發(fā)、以及日積月累的技術(shù)債時，很多企業(yè)會開始做單體服務的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一個應用拆成松耦合的多個獨立的應用，讓應用可以獨立部署，有獨立的團隊進行維護；水平拆分是把一些通用的，會被很多上層服務調(diào)用的模塊獨立拆分出去，形成一個共享的基礎(chǔ)服務，這樣拆分可以對一些性能瓶頸的應用進行單獨的優(yōu)化和運維管理，也在一定程度上防止了垂直拆分的重復造輪子。 SOA 也叫面向服務的架構(gòu)，從單體服務到 SOA 的演進，需要結(jié)合水平拆分及垂直拆分。Java初高級一起學習分享，共同學習才是最明智的選擇，喜歡的話可以我的學習群64弍46衣3凌9，或加資料群69似64陸0吧3.

SOA 強調(diào)用統(tǒng)一的協(xié)議進行服務間的通信，服務間運行在彼此獨立的硬件平臺但是需通過統(tǒng)一的協(xié)議接口相互協(xié)作，也即將應用系統(tǒng)服務化。舉個易懂的例子，單體服務如果相當于一個快餐店，所有的服務員職責都是一樣的，又要負責收銀結(jié)算，又要負責做漢堡，又要負責端盤子，又要負責打掃，服務員之間不需要有交流，用戶來了后，服務員從前到后負責到底。SOA 相當于讓服務員有職責分工，收銀員負責收銀，廚師負責做漢堡，保潔阿姨負責打掃等，所有服務員需要用同一種語言交流，方便工作協(xié)調(diào)。

微服務和 SOA 微服務也是一種服務化，不過其和 SOA 架構(gòu)的服務化概念也是有區(qū)別的，可以從以下幾個關(guān)鍵字來理解： 松耦合：每個微服務內(nèi)部都可以使用 DDD（領(lǐng)域驅(qū)動設(shè)計）的思想進行設(shè)計領(lǐng)域模型，服務間盡量減少同步的調(diào)用，多使用消息的方式讓服務間的領(lǐng)域事件來進行解耦。 輕量級協(xié)議：Dubbo 是 SOA 的開源的標準實現(xiàn)之一，類似的還有像 gRPC、Thrift 等。微服務更傾向于使用 Restful 風格的 API，輕量級的協(xié)議可以很好得支持跨語言開發(fā)的服務，可能有的微服務用 Java 語言實現(xiàn)，有的用 Go 語言，有的用 C++，但所有的語言都可以支持 Http 協(xié)議通信，所有的開發(fā)人員都能理解 Restful 風格 API 的含義。

高度自治和持續(xù)集成：從底層的角度來說，SOA 更加傾向于基于虛擬機或者服務器的部署，每個應用都部署在不同的機器上，一般持續(xù)集成工具更多是由運維團隊寫一些 Shell 腳本以及提供基于共同協(xié)議（比如 Dubbo 管理頁面）的開發(fā)部署頁面。微服務可以很好得和容器技術(shù)結(jié)合，容器技術(shù)比微服務出現(xiàn)得晚，但是容器技術(shù)的出現(xiàn)讓微服務的實施更加簡便，目前 Docker 已經(jīng)成為很多微服務實踐的基礎(chǔ)容器。因為容器的特色，所以一臺機器上可以部署幾十個、幾百個不同的微服務。如果某個微服務流量壓力比其他微服務大，可以在不增加機器的情況下，在一臺機器上多分配一些該微服務的容器實例。同時，因為 Docker 的容器編排社區(qū)日漸成熟，類似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續(xù)集成部署的技術(shù)選擇。 其實從架構(gòu)的演進的角度來看，整體的演進都是朝著越來越輕量級、越來越靈活的應用方向發(fā)展，甚至到近兩年日漸成熟起來的 Serverless（無服務）架構(gòu)。從單體服務到分層的服務，再到面向服務、再到微服務甚至無服務，對于架構(gòu)的挑戰(zhàn)是越來越大。

微服務中的分布式 微服務架構(gòu)屬于分布式系統(tǒng)嗎？答案是肯定的。微服務和 SOA 都是典型的分布式架構(gòu)，只不過微服務的部署粒度更細，服務擴展更靈活。 怎樣理解微服務中的分布式？舉一個招聘時一個同學來面試的例子。A 同學說，目前所在公司在做從單應用到微服務架構(gòu)遷移的工作，已經(jīng)差不多完成了。提到微服務感覺就有話題聊了，于是便問：“是否可以簡單描述下服務拆分后的部署結(jié)構(gòu)、底層存儲的拆分、遷移方案？”于是 A 同學說，只是做了代碼工程結(jié)構(gòu)的拆分，還是原來的部署方式，數(shù)據(jù)庫還是那個庫，所有的微服務都用一個庫，分布式事務處理方式是“避免”，盡量都同步調(diào)用……于是我就跟這位同學友好地微笑說再見了。 微服務的分布式不僅僅是容器應用層面的分布式，其為了高度自治，底層的存儲體系也應該互相獨立，并且也不是所有的微服務都需要持久化的存儲服務。一個“手機驗證碼”微服務可能底層存儲只用一個 Redis；一個“營銷活動搭建頁面”微服務可能底層存儲只需要一個 MongoDB。 微服務中的分布式場景除了服務本身需要有服務發(fā)現(xiàn)、負載均衡，微服務依賴的底層存儲也會有分布式的場景：為了高可用性和性能需要處理數(shù)據(jù)庫的復制、分區(qū)，并且在存儲的分庫情況下，微服務需要能保證分布式事務的一致性。

如何學習分布式微服務架構(gòu)體系 微服務架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來越成熟，所以在初期選擇使用或者企業(yè)技術(shù)體系轉(zhuǎn)型微服務的時候，需要了解微服務架構(gòu)中的分布式的問題：

?在所有服務都是更小單元的部署結(jié)構(gòu)時，一個請求需要調(diào)動更多的服務資源，怎樣獲得更好的性能？

?當業(yè)務規(guī)模增大，需要有地理分布不同的微服務集群時，其底層的數(shù)據(jù)存儲集群是多數(shù)據(jù)中心還是單數(shù)據(jù)集群？ 數(shù)據(jù)存儲如何進行數(shù)據(jù)復制？

??業(yè)務數(shù)據(jù)達到大數(shù)據(jù)量時怎樣進行數(shù)據(jù)的分區(qū)？ 分布式事務怎樣保證一致性？ 不同程度的一致性有什么差別？ 基于容器技術(shù)的服務發(fā)現(xiàn)怎么處理？

?應該用哪些 RPC 技術(shù)，用哪些分布式消息隊列來完成服務通信和解耦？ 那么多的分布式技術(shù)框架、算法、服務應該選哪個才適合企業(yè)的業(yè)務場景？