微服務(wù)架構(gòu)的演變
微服務(wù)架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來越成熟。在最初系統(tǒng)架構(gòu)的搭建，或者當(dāng)現(xiàn)有架構(gòu)已到達(dá)瓶頸需要進(jìn)行架構(gòu)演進(jìn)時，很多架構(gòu)師、運(yùn)維工程師會考慮是否需要搭建微服務(wù)架構(gòu)體系。雖然很多文章都說微服務(wù)架構(gòu)是復(fù)雜的、會帶來很多分布式的問題，但只要我們了解這些問題，并找到解法，就會有種撥開云霧的感覺。 分享之前我還是要推薦下我自己創(chuàng)建的大數(shù)據(jù)學(xué)習(xí)交流Qun: 710219868 進(jìn)Qun聊邀請碼填寫 南風(fēng)（必填）我就知道是你了

公司主營業(yè)務(wù)：成都網(wǎng)站制作、做網(wǎng)站、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)公司推出梅里斯免費(fèi)做網(wǎng)站回饋大家。

微服務(wù)架構(gòu)也不是完美的，世上沒有完美的架構(gòu)，微服務(wù)架構(gòu)也是隨著業(yè)務(wù)、團(tuán)隊成長而不斷演進(jìn)的。最開始可能就幾個、十幾個微服務(wù)，每個服務(wù)是分庫的，通過 API Gateway 并行進(jìn)行服務(wù)數(shù)據(jù)合并、轉(zhuǎn)發(fā)。隨著業(yè)務(wù)擴(kuò)大、不斷地加入搜索引擎、緩存技術(shù)、分布式消息隊列、數(shù)據(jù)存儲層的數(shù)據(jù)復(fù)制、分區(qū)、分表等。

微服務(wù)是一種服務(wù)間松耦合的、每個服務(wù)之間高度自治并且使用輕量級協(xié)議進(jìn)行通信的可持續(xù)集成部署的分布式架構(gòu)體系。這一句包含了微服務(wù)的特點(diǎn)，微服務(wù)架構(gòu)和其他架構(gòu)有什么區(qū)別？以下對比一些常見的架構(gòu)。

單體架構(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ùn)行。隨著業(yè)務(wù)復(fù)雜度增加、技術(shù)團(tuán)隊規(guī)模擴(kuò)大，在一個單體應(yīng)用中維護(hù)代碼，會降低開發(fā)效率，即使是處理一個小需求，也需要將所有機(jī)器上的應(yīng)用全部部署一遍，增加了運(yùn)維的復(fù)雜度。

SOA 架構(gòu)
當(dāng)某一天使用單體架構(gòu)發(fā)現(xiàn)很難推進(jìn)需求的開發(fā)、以及日積月累的技術(shù)債時，很多企業(yè)會開始做單體服務(wù)的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一個應(yīng)用拆成松耦合的多個獨(dú)立的應(yīng)用，讓應(yīng)用可以獨(dú)立部署，有獨(dú)立的團(tuán)隊進(jìn)行維護(hù)；水平拆分是把一些通用的，會被很多上層服務(wù)調(diào)用的模塊獨(dú)立拆分出去，形成一個共享的基礎(chǔ)服務(wù)，這樣拆分可以對一些性能瓶頸的應(yīng)用進(jìn)行單獨(dú)的優(yōu)化和運(yùn)維管理，也在一定程度上防止了垂直拆分的重復(fù)造輪子。

SOA 也叫面向服務(wù)的架構(gòu)，從單體服務(wù)到 SOA 的演進(jìn)，需要結(jié)合水平拆分及垂直拆分。SOA 強(qiáng)調(diào)用統(tǒng)一的協(xié)議進(jìn)行服務(wù)間的通信，服務(wù)間運(yùn)行在彼此獨(dú)立的硬件平臺但是需通過統(tǒng)一的協(xié)議接口相互協(xié)作，也即將應(yīng)用系統(tǒng)服務(wù)化。舉個易懂的例子，單體服務(wù)如果相當(dāng)于一個快餐店，所有的服務(wù)員職責(zé)都是一樣的，又要負(fù)責(zé)收銀結(jié)算，又要負(fù)責(zé)做漢堡，又要負(fù)責(zé)端盤子，又要負(fù)責(zé)打掃，服務(wù)員之間不需要有交流，用戶來了后，服務(wù)員從前到后負(fù)責(zé)到底。SOA 相當(dāng)于讓服務(wù)員有職責(zé)分工，收銀員負(fù)責(zé)收銀，廚師負(fù)責(zé)做漢堡，×××阿姨負(fù)責(zé)打掃等，所有服務(wù)員需要用同一種語言交流，方便工作協(xié)調(diào)。

微服務(wù)和 SOA
微服務(wù)也是一種服務(wù)化，不過其和 SOA 架構(gòu)的服務(wù)化概念也是有區(qū)別的，可以從以下幾個關(guān)鍵字來理解：

松耦合：每個微服務(wù)內(nèi)部都可以使用 DDD（領(lǐng)域驅(qū)動設(shè)計）的思想進(jìn)行設(shè)計領(lǐng)域模型，服務(wù)間盡量減少同步的調(diào)用，多使用消息的方式讓服務(wù)間的領(lǐng)域事件來進(jìn)行解耦。
輕量級協(xié)議：Dubbo 是 SOA 的開源的標(biāo)準(zhǔn)實(shí)現(xiàn)之一，類似的還有像 gRPC、Thrift 等。微服務(wù)更傾向于使用 Restful 風(fēng)格的 API，輕量級的協(xié)議可以很好得支持跨語言開發(fā)的服務(wù)，可能有的微服務(wù)用 Java 語言實(shí)現(xiàn)，有的用 Go 語言，有的用 C++，但所有的語言都可以支持 Http 協(xié)議通信，所有的開發(fā)人員都能理解 Restful 風(fēng)格 API 的含義。
高度自治和持續(xù)集成：從底層的角度來說，SOA 更加傾向于基于虛擬機(jī)或者服務(wù)器的部署，每個應(yīng)用都部署在不同的機(jī)器上，一般持續(xù)集成工具更多是由運(yùn)維團(tuán)隊寫一些 Shell 腳本以及提供基于共同協(xié)議（比如 Dubbo 管理頁面）的開發(fā)部署頁面。微服務(wù)可以很好得和容器技術(shù)結(jié)合，容器技術(shù)比微服務(wù)出現(xiàn)得晚，但是容器技術(shù)的出現(xiàn)讓微服務(wù)的實(shí)施更加簡便，目前 Docker 已經(jīng)成為很多微服務(wù)實(shí)踐的基礎(chǔ)容器。因?yàn)槿萜鞯奶厣砸慌_機(jī)器上可以部署幾十個、幾百個不同的微服務(wù)。如果某個微服務(wù)流量壓力比其他微服務(wù)大，可以在不增加機(jī)器的情況下，在一臺機(jī)器上多分配一些該微服務(wù)的容器實(shí)例。同時，因?yàn)?Docker 的容器編排社區(qū)日漸成熟，類似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續(xù)集成部署的技術(shù)選擇。

其實(shí)從架構(gòu)的演進(jìn)的角度來看，整體的演進(jìn)都是朝著越來越輕量級、越來越靈活的應(yīng)用方向發(fā)展，甚至到近兩年日漸成熟起來的 Serverless（無服務(wù)）架構(gòu)。從單體服務(wù)到分層的服務(wù)，再到面向服務(wù)、再到微服務(wù)甚至無服務(wù)，對于架構(gòu)的挑戰(zhàn)是越來越大。

微服務(wù)中的分布式
微服務(wù)架構(gòu)屬于分布式系統(tǒng)嗎？答案是肯定的。微服務(wù)和 SOA 都是典型的分布式架構(gòu)，只不過微服務(wù)的部署粒度更細(xì)，服務(wù)擴(kuò)展更靈活。

怎樣理解微服務(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)該互相獨(dú)立，并且也不是所有的微服務(wù)都需要持久化的存儲服務(wù)。一個“手機(jī)驗(yàn)證碼”微服務(wù)可能底層存儲只用一個 redis；一個“營銷活動搭建頁面”微服務(wù)可能底層存儲只需要一個 MongoDB。

微服務(wù)中的分布式場景除了服務(wù)本身需要有服務(wù)發(fā)現(xiàn)、負(fù)載均衡，微服務(wù)依賴的底層存儲也會有分布式的場景：為了高可用性和性能需要處理數(shù)據(jù)庫的復(fù)制、分區(qū)，并且在存儲的分庫情況下，微服務(wù)需要能保證分布式事務(wù)的一致性。

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

在所有服務(wù)都是更小單元的部署結(jié)構(gòu)時，一個請求需要調(diào)動更多的服務(wù)資源，怎樣獲得更好的性能？
當(dāng)業(yè)務(wù)規(guī)模增大，需要有地理分布不同的微服務(wù)集群時，其底層的數(shù)據(jù)存儲集群是多數(shù)據(jù)中心還是單數(shù)據(jù)集群？ 數(shù)據(jù)存儲如何進(jìn)行數(shù)據(jù)復(fù)制？
業(yè)務(wù)數(shù)據(jù)達(dá)到大數(shù)據(jù)量時怎樣進(jìn)行數(shù)據(jù)的分區(qū)？ 分布式事務(wù)怎樣保證一致性？ 不同程度的一致性有什么差別？ 基于容器技術(shù)的服務(wù)發(fā)現(xiàn)怎么處理？
應(yīng)該用哪些 RPC 技術(shù)，用哪些分布式消息隊列來完成服務(wù)通信和解耦？ 那么多的分布式技術(shù)框架、算法、服務(wù)應(yīng)該選哪個才適合企業(yè)的業(yè)務(wù)場景？
《分布式微服務(wù)架構(gòu)體系詳解》從微服務(wù)不得不面對和解決的分布式問題出發(fā)，包含分布式技術(shù)的一系列理論以及架構(gòu)模型、算法的介紹，同時結(jié)合技術(shù)選型和實(shí)踐應(yīng)用，提供一系列解決方案的梳理。相信閱讀完整個課程，你會對微服務(wù)的分布式問題有個系統(tǒng)地理解。本課程會對微服務(wù)的分布式場景問題一一擊破，為你提供解決思路。并且，本課程通過對分布式問題的體系化梳理，結(jié)合一些方案的對比選型，可以讓工程師們一覽微服務(wù)的知識圖譜。

如果你是一位開發(fā)工程師，相信閱讀完本系列課程，將會了解很多分布式系統(tǒng)的理論知識，同時也會理解一些分布式存儲、中間件技術(shù)的原理，對工作中的分布式架構(gòu)會有體系化的清晰認(rèn)知。
如果你是一位架構(gòu)師，本系列課程提供了對于分布式系統(tǒng)問題的全面梳理，以及一些技術(shù)背后的理論，結(jié)合實(shí)踐和目前業(yè)界先進(jìn)的方案，對于技術(shù)選型和架構(gòu)搭建提供了參考。

網(wǎng)頁名稱：分布式微服務(wù)架和SOAj架構(gòu)體系詳解
分享路徑：http://sd-ha.com/article26/iedhjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、全網(wǎng)營銷推廣、微信小程序、自適應(yīng)網(wǎng)站、靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)