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

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

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

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

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

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

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

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

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

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

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

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

2、易于測試：單體應(yīng)用一旦部署，所有的服務(wù)或特性就都可以使用了，簡化了測試過程，無需額外測試服務(wù)間的依賴，測試均可在部署完成后開始。

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

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

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

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

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

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

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

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

2.1 單一職責(zé)

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

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

2.2 輕量級通信

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

2.3 獨立性

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

2.4 進(jìn)程隔離

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

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

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

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

2.6 簡化治理

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

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

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

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

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

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

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

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

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

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

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

3.2 第二階：原始通信時代

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

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

3.3 第三階：TCP時代

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

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

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

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

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

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

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

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

3.6 第六階：第一代Service Mesh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.7 第七階：第二代Service Mesh

第一代Service Mesh由一系列獨立運行的單機代理服務(wù)構(gòu)成，為了提供統(tǒng)一的上層運維入口，演化出了集中式的控制面板，我們稱之為控制面（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)前流行的開源服務(wù)網(wǎng)格 Istio 和 Linkerd 都是這種構(gòu)造。

控制平面的特點：

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

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

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

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

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

最新評論