1 傳統(tǒng)單體系統(tǒng)介紹

物理服務(wù)器的CPU、內(nèi)存、存儲(chǔ)器、連接數(shù)等資源有限，單體系統(tǒng)能夠承受的的QPS也是有限的，某個(gè)時(shí)段大量連接同時(shí)執(zhí)行操作，會(huì)導(dǎo)致web服務(wù)和數(shù)據(jù)庫(kù)服務(wù)在處理上遇到性能瓶頸。

為了解決這個(gè)問(wèn)題，偉大的前輩們發(fā)揚(yáng)了分而治之的思想，對(duì)大數(shù)據(jù)庫(kù)、大表進(jìn)行分割，可以參考我的《Mysql數(shù)據(jù)庫(kù)分庫(kù)分表全面瓦解》，以便實(shí)施更好的控制和管理。

同時(shí)創(chuàng)建多個(gè)服務(wù)實(shí)例，使用多臺(tái)服務(wù)機(jī)進(jìn)行CPU、內(nèi)存、存儲(chǔ)的分?jǐn)?，提供更好的性能?/p>

1.1 單體系統(tǒng)的問(wèn)題

1、復(fù)雜性高：由于是一個(gè)單體的系統(tǒng)，所以整個(gè)系統(tǒng)的模塊是耦合在一起的，模塊的邊界比較模糊、依賴關(guān)系錯(cuò)綜復(fù)雜。功能的調(diào)整，容易帶來(lái)不可知的影響和潛在的bug風(fēng)險(xiǎn)。

2、服務(wù)性能問(wèn)題：?jiǎn)误w系統(tǒng)遇到性能瓶頸問(wèn)題，只能橫向擴(kuò)展，增加服務(wù)實(shí)例，進(jìn)行負(fù)載均衡分擔(dān)壓力。無(wú)法縱向擴(kuò)展，做模塊拆分。

3、擴(kuò)縮容能力受限：?jiǎn)误w應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展，影響范圍大，無(wú)法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行單個(gè)模塊的伸縮。

4、無(wú)法做故障隔離：當(dāng)所有的業(yè)務(wù)功能模塊都聚集在一個(gè)程序集當(dāng)中，如果其中的某一個(gè)小的功能模塊出現(xiàn)問(wèn)題（如某個(gè)請(qǐng)求堵塞），那么都有可能會(huì)造成整個(gè)系統(tǒng)的崩潰。

5、發(fā)布的影響范圍較大：每次發(fā)布都是整個(gè)系統(tǒng)進(jìn)行發(fā)布，發(fā)布會(huì)導(dǎo)致整個(gè)系統(tǒng)的重啟，對(duì)于大型的綜合系統(tǒng)挑戰(zhàn)比較大，如果將各個(gè)模塊拆分，哪個(gè)部分做了修改，只發(fā)布哪個(gè)部分所在的模塊即可。

1.2 單體系統(tǒng)的優(yōu)點(diǎn)

1、系統(tǒng)的簡(jiǎn)易性：系統(tǒng)語(yǔ)言風(fēng)格、業(yè)務(wù)結(jié)構(gòu)，接口格式均具有一致性，服務(wù)都是耦合在一起的，不存在各個(gè)業(yè)務(wù)通信問(wèn)題。

2、易于測(cè)試：?jiǎn)误w應(yīng)用一旦部署，所有的服務(wù)或特性就都可以使用了，簡(jiǎn)化了測(cè)試過(guò)程，無(wú)需額外測(cè)試服務(wù)間的依賴，測(cè)試均可在部署完成后開(kāi)始。

3、易于部署與升級(jí)：相對(duì)于微服務(wù)架構(gòu)中的每個(gè)服務(wù)獨(dú)立部署，單體系統(tǒng)只需將單個(gè)目錄下的服務(wù)程序統(tǒng)一部署和升級(jí)。 

4、較低的維護(hù)成本：只需維護(hù)單個(gè)系統(tǒng)即可。運(yùn)維主要包括配置、部署、監(jiān)控與告警和日志收集四大方面。相對(duì)于單體系統(tǒng)，微服務(wù)架構(gòu)中的每個(gè)服務(wù)都需要獨(dú)立地配置、部署、監(jiān)控和日志收集，成本呈指數(shù)級(jí)增長(zhǎng)。

1.3 單體服務(wù)到微服務(wù)的發(fā)展過(guò)程

EUREKA的注冊(cè)中心逐漸被ZooKeeper和Nacos等替代了。

2 關(guān)于微服務(wù)

微服務(wù)是 一種架構(gòu)模式，是面向服務(wù)的體系結(jié)構(gòu)（SOA）軟件架構(gòu)模式的一種演變，

它提倡將單一應(yīng)用程序 劃分成一組松散耦合的細(xì)粒度小型服務(wù)，輔助輕量級(jí)的協(xié)議，互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。

所以，微服務(wù)（或微服務(wù)架構(gòu)）是一種云原生架構(gòu)方法，其中單個(gè)應(yīng)用程序由許多松散耦合且可獨(dú)立部署的較小組件或服務(wù)組成。這些服務(wù)通常包含如下特點(diǎn)：  

2.1 單一職責(zé)

微服務(wù)架構(gòu)中的每個(gè)節(jié)點(diǎn)高度服務(wù)化，都是 具有業(yè)務(wù)邏輯的，符合高內(nèi)聚、低耦合原則以及單一職責(zé)原則的單元，包括數(shù)據(jù)庫(kù)和數(shù)據(jù)模型；

不同的服務(wù)通過(guò)“管道”的方式靈活組合，從而構(gòu)建出龐大的系統(tǒng)。

2.2 輕量級(jí)通信

通過(guò)REST API模式或者RPC框架，實(shí)現(xiàn)服務(wù)間互相協(xié)作的輕量級(jí)通信機(jī)制。

2.3 獨(dú)立性

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都是獨(dú)立的業(yè)務(wù)單元，與其他服務(wù)高度解耦，只需要改變當(dāng)前服務(wù)本身，就可以完成獨(dú)立的開(kāi)發(fā)、測(cè)試、部署、運(yùn)維。

2.4 進(jìn)程隔離

在微服務(wù)架構(gòu)中，應(yīng)用程序由多個(gè)服務(wù)組成，每個(gè)服務(wù)都是高度自治的獨(dú)立業(yè)務(wù)實(shí)體，可以運(yùn)行在獨(dú)立的進(jìn)程中， 不同的服務(wù)能非常容易地部署到不同的主機(jī)上，實(shí)現(xiàn)高度自治和高度隔離。

進(jìn)程的隔離，還能保證服務(wù)達(dá)到動(dòng)態(tài)擴(kuò)縮容的能力，業(yè)務(wù)高峰期自動(dòng)增加服務(wù)資源以提升并發(fā)能力，業(yè)務(wù)低谷期則可自動(dòng)釋放服務(wù)資源以節(jié)省開(kāi)銷。 

2.5 混合技術(shù)棧和混合部署方式

團(tuán)隊(duì)可以為不同的服務(wù)組件使用不同的技術(shù)棧和不同的部署方式（公有云、私有云、混合云）。

2.6 簡(jiǎn)化治理

組件可以彼此獨(dú)立地進(jìn)行擴(kuò)縮容和治理，從而減少了因必須縮放整個(gè)應(yīng)用程序而產(chǎn)生的浪費(fèi)和成本，因?yàn)閱蝹€(gè)功能可能面臨過(guò)多的負(fù)載。 

2.7 安全可靠，可維護(hù)。

從架構(gòu)上對(duì)運(yùn)維提供友好的支撐，在安全、可維護(hù)的基礎(chǔ)上規(guī)范化發(fā)布流程，支持?jǐn)?shù)據(jù)存儲(chǔ)容災(zāi)、業(yè)務(wù)模塊隔離、訪問(wèn)權(quán)限控制、編碼安全檢測(cè)等。 

3 微服務(wù)演進(jìn)史 

我們前面已經(jīng)了解了微服務(wù)的概念，通過(guò)百度指數(shù)可以看出，從2012年之后，微服務(wù)的發(fā)展有顯著的發(fā)展趨勢(shì)。

目前業(yè)內(nèi)的微服務(wù)相關(guān)開(kāi)發(fā)平臺(tái)和框架還是比較多的，比如較早的Spring Cloud（使用Eureke做服務(wù)注冊(cè)與發(fā)現(xiàn)，Ribbon做服務(wù)間負(fù)載均衡，Hystrix做服務(wù)容錯(cuò)保護(hù)），

阿里的Dubbo，微軟的.Net體系微服務(wù)框架 Service Fabric，再到后來(lái)進(jìn)階的服務(wù)網(wǎng)格(Service Mesh,如 Istio、Linkerd）。

那從12年開(kāi)始到現(xiàn)在，微服務(wù)到底發(fā)展到哪個(gè)階段了，在各個(gè)階段的進(jìn)階過(guò)程中，又有哪些的變化。所以我們需要了解微服務(wù)技術(shù)的歷史發(fā)展脈絡(luò)。

下面的內(nèi)容參考了 Phil Calçado的文章《Pattern: Service Mesh》，從開(kāi)發(fā)者的視角，詳細(xì)分析了從微服務(wù)到Service Mesh技術(shù)的演進(jìn)過(guò)程，這邊做了進(jìn)一步的整理和總結(jié)。 

3.1 第一階：簡(jiǎn)單服務(wù)通信模塊

這是最初的模樣，開(kāi)發(fā)人員最開(kāi)始的時(shí)候想象的兩個(gè)服務(wù)間簡(jiǎn)單的通信模式，抽象表示如下，兩個(gè)服務(wù)之間直接進(jìn)行通信：

3.2 第二階：原始通信時(shí)代

上面的方式非常簡(jiǎn)單，但實(shí)際情況遠(yuǎn)比想象的復(fù)雜很多，通信需要底層字節(jié)碼傳輸和電子信號(hào)的物理層來(lái)完成，在TCP協(xié)議出現(xiàn)之前，

服務(wù)需要自己處理網(wǎng)絡(luò)通信所面臨的丟包、錯(cuò)誤、亂序、重試等一系列流控問(wèn)題，因此服務(wù)實(shí)現(xiàn)中，除了業(yè)務(wù)邏輯外，還包含對(duì)網(wǎng)絡(luò)傳輸問(wèn)題的處理邏輯。

3.3 第三階：TCP時(shí)代

TCP協(xié)議的出現(xiàn)，避免了每個(gè)服務(wù)自己實(shí)現(xiàn)一套相似的網(wǎng)絡(luò)傳輸處理邏輯，解決網(wǎng)絡(luò)傳輸中通用的流量控制問(wèn)題。

這時(shí)候我們把處理網(wǎng)絡(luò)傳輸?shù)哪芰ο鲁?，從服?wù)的實(shí)現(xiàn)中抽離出來(lái)，成為操作系統(tǒng)網(wǎng)絡(luò)層的一部分。

3.4 第四階：第一代微服務(wù)（Spring Cloud/RPC）

TCP出現(xiàn)之后，服務(wù)間的網(wǎng)絡(luò)通信已經(jīng)不是一個(gè)難題了，所以 GFS/BigTable/MapReduce 為代表的分布式系統(tǒng)得到了蓬勃的發(fā)展。

這時(shí)，分布式系統(tǒng)特有的通信語(yǔ)義又出現(xiàn)了，如服務(wù)注冊(cè)與發(fā)現(xiàn)、負(fù)載均衡、熔斷降級(jí)策略、認(rèn)證和授權(quán)、端到端trace、日志與監(jiān)控等，因此根據(jù)業(yè)務(wù)需求,完成一些通信語(yǔ)義的實(shí)現(xiàn)。

3.5 第五階：第二代微服務(wù)

為了避免每個(gè)服務(wù)都需要自己實(shí)現(xiàn)一套分布式系統(tǒng)通信的語(yǔ)義功能，隨著技術(shù)的發(fā)展，一些面向微服務(wù)架構(gòu)的通用開(kāi)發(fā)框架出現(xiàn)了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等，

這些框架實(shí)現(xiàn)了分布式系統(tǒng)通信需要的各種通用語(yǔ)義功能：如負(fù)載均衡和服務(wù)發(fā)現(xiàn)等，因此一定程度上屏蔽了這些通信細(xì)節(jié)，使得開(kāi)發(fā)人員使用較少的框架代碼就能開(kāi)發(fā)出健壯的分布式系統(tǒng)。

3.6 第六階：第一代Service Mesh

上面的第二代微服務(wù)框架目前看著挺完美了，但整套微服務(wù)框架其實(shí)是很復(fù)雜的，比如Spring Cloud，聚合了很多組件。所以在實(shí)踐過(guò)程中，會(huì)發(fā)現(xiàn)有如下諸多問(wèn)題：

• 侵入性強(qiáng)。想要集成SDK的能力，除了需要添加相關(guān)依賴，業(yè)務(wù)層中 入侵的代碼、注解、配置，與治理層界限不清晰。

• 升級(jí)成本高。每次升級(jí)都需要業(yè)務(wù)應(yīng)用修改SDK版本，重新進(jìn)行功能回歸測(cè)試，并對(duì)每一臺(tái)服務(wù)進(jìn)行部署上線， 與快速迭代開(kāi)發(fā)相悖。

• 版本碎片化嚴(yán)重。由于升級(jí)成本高，而中間件版本更新快，導(dǎo)致 線上不同服務(wù)引用的SDK版本不統(tǒng)一、能力參差不齊，造成很難統(tǒng)一治理。

• 中間件演變困難。由于版本碎片化嚴(yán)重，導(dǎo)致中間件向前演進(jìn)的過(guò)程中就需要在代碼中 兼容各種各樣的老版本邏輯，帶著"枷鎖”前行，無(wú)法實(shí)現(xiàn)快速迭代。

• 內(nèi)容多、門(mén)檻高。依賴組件多，學(xué)習(xí)成本高，即使通用分布式系統(tǒng)屏蔽了很多的實(shí)現(xiàn)細(xì)節(jié)，我們引入微服務(wù)框架并熟練使用也是要花費(fèi)巨大的精力的。

• 治理功能不全。不同于RPC框架，SpringCloud作為治理全家桶的典型，也不是萬(wàn)能的，諸如協(xié)議轉(zhuǎn)換支持、多重授權(quán)機(jī)制、動(dòng)態(tài)請(qǐng)求路由、故障注入、灰度發(fā)布等高級(jí)功能并沒(méi)有覆蓋到。

• 無(wú)法實(shí)現(xiàn)真正意義上的語(yǔ)言無(wú)關(guān)性。提供的框架一般只支持一種或幾種語(yǔ)言，要將框架不支持的語(yǔ)言研發(fā)的服務(wù)也納入微服務(wù)架構(gòu)中，是比較有難度的。

所以，第一代微服務(wù)架構(gòu) Service Mesh就產(chǎn)生了，它作為一個(gè)基礎(chǔ)設(shè)施層，能夠與業(yè)務(wù)解耦，主要解決復(fù)雜網(wǎng)絡(luò)拓?fù)湎挛⒎?wù)與微服務(wù)之間的通信，其實(shí)現(xiàn)形態(tài)一般為輕量級(jí)網(wǎng)絡(luò)代理，并與應(yīng)用以邊車代理（SideCar）模式部署，同時(shí)對(duì)業(yè)務(wù)應(yīng)用透明。

SideCar將分布式服務(wù)的通信抽象為單獨(dú)一層，需要和服務(wù)部署在一起，接管服務(wù)的流量，通過(guò)代理之間的通信間接完成服務(wù)之間的通信請(qǐng)求。

所以在這一層中它能夠?qū)崿F(xiàn)負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能。

如果我們從一個(gè)全局視角來(lái)看，綠色的為應(yīng)用服務(wù)，藍(lán)色的為SideCar，就會(huì)得到如下部署圖：

如果我們省略去服務(wù)，只看Service Mesh的代理邊車的網(wǎng)格應(yīng)該是這樣的：

流量經(jīng)過(guò)的時(shí)候，會(huì)先被代理邊車所劫持，然后再進(jìn)入服務(wù)，所以它就是一個(gè)由若干服務(wù)代理所組成的錯(cuò)綜復(fù)雜的網(wǎng)格。  

3.7 第七階：第二代Service Mesh

第一代Service Mesh由一系列獨(dú)立運(yùn)行的單機(jī)代理服務(wù)構(gòu)成，為了提供統(tǒng)一的上層運(yùn)維入口，演化出了集中式的控制面板，我們稱之為控制面（control plane）。

控制面和所有的數(shù)據(jù)面（data plane，即代理邊車）進(jìn)行交互，比如策略下發(fā)、數(shù)據(jù)采集等。這就是以Istio為代表的第二代Service Mesh。

只包含控制面和數(shù)據(jù)面的 Service Mesh 服務(wù)網(wǎng)格全局結(jié)構(gòu)圖 如下：

從上面的結(jié)構(gòu)圖可以看出，Service Mesh 的基礎(chǔ)設(shè)施層主要分為兩部分：控制平面與數(shù)據(jù)平面。當(dāng)前流行的開(kāi)源服務(wù)網(wǎng)格 Istio 和 Linkerd 都是這種構(gòu)造。

控制平面的特點(diǎn)：

• 不直接解析數(shù)據(jù)包。
• 與控制平面中的代理通信，下發(fā)策略和配置。
• 負(fù)責(zé)網(wǎng)絡(luò)行為的可視化。
• 通常提供 API 或者命令行工具可用于配置版本化管理，便于持續(xù)集成和部署。

數(shù)據(jù)平面的特點(diǎn)：

• 通常是按照無(wú)狀態(tài)目標(biāo)設(shè)計(jì)的，但實(shí)際上為了提高流量轉(zhuǎn)發(fā)性能，需要緩存一些數(shù)據(jù)，因此無(wú)狀態(tài)也是有爭(zhēng)議的。
• 直接處理入站和出站數(shù)據(jù)包，轉(zhuǎn)發(fā)、路由、健康檢查、負(fù)載均衡、認(rèn)證、鑒權(quán)、產(chǎn)生監(jiān)控?cái)?shù)據(jù)等。
• 對(duì)應(yīng)用來(lái)說(shuō)透明，即可以做到無(wú)感知部署。

到這一步我們大概了解了微服務(wù)架構(gòu)的演進(jìn)過(guò)程，也初步了解Service Mesh技術(shù)比較于傳統(tǒng)的微服務(wù)架構(gòu)有哪些優(yōu)勢(shì)。

以上就是詳解微服務(wù)架構(gòu)及其演進(jìn)史的詳細(xì)內(nèi)容，更多關(guān)于微服務(wù)演進(jìn)史的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論