快捷導(dǎo)航

詳解Rainbond內(nèi)置ServiceMesh微服務(wù)架構(gòu)

更新時(shí)間：2022年04月20日 17:43:51 作者：Rainbond?作者

這篇文章主要為大家介紹了詳解Rainbond內(nèi)置ServiceMesh微服務(wù)架構(gòu)，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

ServiceMesh

一般的字面解釋是“服務(wù)網(wǎng)格”，作為時(shí)下最流行的分布式系統(tǒng)架構(gòu)微服務(wù)的動(dòng)態(tài)鏈接器，處于服務(wù)到服務(wù)的通信的專用基礎(chǔ)設(shè)施層，該層獨(dú)立于應(yīng)用程序?yàn)榉?wù)之間的通信提供輕量級(jí)的可靠傳遞。

如果簡(jiǎn)單的描述的話，可以將它比作是應(yīng)用程序或者說微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控，同樣使用 ServiceMesh 也就無(wú)須關(guān)系服務(wù)之間的那些原來(lái)是通過應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情，比如 Spring Cloud架構(gòu)，現(xiàn)在只要交給 ServiceMesh 就可以了。

ServiceMesh的出現(xiàn)主要是由于應(yīng)用虛擬化技術(shù)的發(fā)展，例如Kubernetes, Rainbond等項(xiàng)目，大大降低了應(yīng)用的部署和運(yùn)維復(fù)雜度。

微服務(wù)架構(gòu)對(duì)比

為何使用ServiceMesh

ServiceMesh 并沒有給我們帶來(lái)新功能，它是用于解決其他工具已經(jīng)解決過的問題，只不過這是在 Cloud Native 的云原生環(huán)境下將過去復(fù)雜的人工運(yùn)維工作有機(jī)的自動(dòng)化管理。

在傳統(tǒng)的 MVC 三層 Web 應(yīng)用程序架構(gòu)下，服務(wù)之間的通訊并不復(fù)雜，在應(yīng)用程序內(nèi)部自己管理即可，但是在現(xiàn)今的復(fù)雜的大型網(wǎng)站情況下，單體應(yīng)用被分解為眾多的微服務(wù)，服務(wù)之間的依賴和通訊十分復(fù)雜，出現(xiàn)了 twitter 開發(fā)的 Finagle、Netflix 開發(fā)的 Hystrix 和 Google 的 Stubby 這樣的 “胖客戶端” 庫(kù)，這些就是早期的 ServiceMesh，但是它們都近適用于特定的環(huán)境和特定的開發(fā)語(yǔ)言，并不能作為平臺(tái)級(jí)的 ServiceMesh 支持。

在 Cloud Native 架構(gòu)下，容器的使用給予了異構(gòu)應(yīng)用程序的更多可行性，kubernetes 增強(qiáng)的應(yīng)用的橫向擴(kuò)容能力，用戶可以快速的編排出復(fù)雜環(huán)境、復(fù)雜依賴關(guān)系的應(yīng)用程序，同時(shí)開發(fā)者又無(wú)須過分關(guān)心應(yīng)用程序的監(jiān)控、擴(kuò)展性、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和分布式追蹤這些繁瑣的事情而專注于程序開發(fā)，賦予開發(fā)者更多的創(chuàng)造性。如果你是符合以下場(chǎng)景，推薦選擇ServiceMesh架構(gòu)：

1.遺留龐大系統(tǒng)逐步過渡到微服務(wù)架構(gòu)

2.業(yè)務(wù)系統(tǒng)由多種開發(fā)語(yǔ)言開發(fā)

ServiceMesh相對(duì)其他微服務(wù)架構(gòu)優(yōu)勢(shì)

最大層度透明

ServiceMesh通過全局控制層控制服務(wù)與服務(wù)之間的調(diào)用關(guān)系，服務(wù)的治理策略。對(duì)于服務(wù)本身來(lái)說，只需要站在單機(jī)的維度考慮上游服務(wù)的依賴通信，采用簡(jiǎn)單的通信協(xié)議例如HTTP，gRPC等。Mesh層透明的發(fā)現(xiàn)上游目標(biāo)，進(jìn)行重試/超時(shí)、監(jiān)控、追蹤。為單機(jī)服務(wù)賦予分布式系統(tǒng)能力。

學(xué)習(xí)成本低

過去我們要設(shè)計(jì)搭建一個(gè)完整的微服務(wù)架構(gòu)，比如SpringCloud,Dubbo等，免不了需要改變我們傳統(tǒng)的編程思想，學(xué)習(xí)復(fù)雜的架構(gòu)框架，例如SpringCloud,其包含各類組件10余個(gè)，基本與服務(wù)業(yè)務(wù)本身沒有直接關(guān)系。對(duì)于大多數(shù)業(yè)務(wù)開發(fā)者來(lái)說是一個(gè)高高的門檻。但是使用ServiceMesh架構(gòu)，由于其最大化的透明，開發(fā)者幾乎不需要額外學(xué)習(xí)與業(yè)務(wù)無(wú)關(guān)的框架技術(shù)。大大降低了學(xué)習(xí)成本。

架構(gòu)靈活

對(duì)于不同的團(tuán)隊(duì)組成，可能擁有具有掌握不同開發(fā)語(yǔ)言的成員，或者具有成熟的已實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)。如果轉(zhuǎn)變到微服務(wù)架構(gòu)支持更大量級(jí)用戶，如果使用SpringCloud架構(gòu)，免不了對(duì)系統(tǒng)進(jìn)行重構(gòu)甚至重寫。面對(duì)現(xiàn)實(shí)與未來(lái)，我們需要逐步落地微服務(wù)架構(gòu)，使用合適的開發(fā)語(yǔ)言開發(fā)合適的服務(wù)，甚至融合多種輕量級(jí)架構(gòu)模式，比如Dubbo,SpringBoot和LNMP架構(gòu)。

ServiceMesh架構(gòu)性能

有人提出，在服務(wù)與服務(wù)之間增加兩層代理對(duì)性能會(huì)產(chǎn)生較大影響，對(duì)于性能問題，我們應(yīng)該放眼全局，從以下幾個(gè)方面分析：

對(duì)于增加代理響應(yīng)性能問題在所有的微服務(wù)架構(gòu)中都存在。

ServiceMesh的網(wǎng)絡(luò)代理層一般采用輕量級(jí)的高效率的代理實(shí)現(xiàn)，其本身性能通常較為優(yōu)越。

ServiceMesh為了提供更好的治理功能支持，通信模型一般處在應(yīng)用層，比如處理（http,grpc,mongo,mysql）等協(xié)議。如果對(duì)性能要求比較高，也可以直接使用4層網(wǎng)絡(luò)模型。

ServiceMesh一般面向中大型分布式系統(tǒng)，分布式系統(tǒng)直接本身就會(huì)有通信消耗，Mesh層相反可以使用更高效的通信協(xié)議比如http/2 來(lái)優(yōu)化通過http/1.1協(xié)議通信的服務(wù)通信過程。

ServiceMesh只對(duì)網(wǎng)絡(luò)進(jìn)行治理么？

ServiceMesh架構(gòu)框架是工作在網(wǎng)絡(luò)通信層面提供一系列服務(wù)治理功能，包括：

服務(wù)發(fā)現(xiàn)和負(fù)載均衡
高級(jí)路由
通信監(jiān)控和分析
通信安全

對(duì)于Rainbond的架構(gòu)設(shè)計(jì)來(lái)說還通過插件擴(kuò)展的方式增加以下方面功能：

日志處理
數(shù)據(jù)備份和恢復(fù)
服務(wù)運(yùn)維和監(jiān)控
服務(wù)運(yùn)行環(huán)境保障

Rainbond與ServiceMesh

Rainbond原生提供全量的ServiceMesh治理功能方案，同時(shí)提供了插件化得擴(kuò)展策略，用戶除了使用默認(rèn)方案以外也可以自定義插件實(shí)現(xiàn)。Rainbond與Istio的實(shí)現(xiàn)有共同點(diǎn)，也有天然的不同。

相同點(diǎn)是都實(shí)現(xiàn)了基于XDS規(guī)范實(shí)現(xiàn)全局控制層，支持envoy和istio-proxy。

不同點(diǎn)是Istio需要依賴Kubernetes等平臺(tái)工作，微服務(wù)架構(gòu)的支持需要從底層存儲(chǔ)與通信到上層的應(yīng)用層配置全盤考慮，大型的微服務(wù)架構(gòu)是離開不了自動(dòng)化管理應(yīng)用的PaaS平臺(tái)的。Rainbond從硬件層，通信層，平臺(tái)層實(shí)現(xiàn)不同的控制邏輯，既兼容已有的微服務(wù)架構(gòu)，同時(shí)提供了完整的ServiceMesh微服務(wù)架構(gòu)實(shí)踐。包容的架構(gòu)形式讓已有的應(yīng)用服務(wù)化變得可落地。

Rainbond提供給用戶的體驗(yàn)是最大化的透明，即用戶將服務(wù)運(yùn)行于Rainbond即已經(jīng)構(gòu)成了微服務(wù)架構(gòu)，而無(wú)需先學(xué)習(xí)微服務(wù)架構(gòu)知識(shí)，再考慮自己的服務(wù)如何改造，最后再落地。

如下圖可知，Rainbond的網(wǎng)絡(luò)治理插件通過Sidecar的方式在應(yīng)用的同一個(gè)網(wǎng)絡(luò)命名空間，同一個(gè)存儲(chǔ)空間，同一個(gè)環(huán)境變量空間內(nèi)動(dòng)態(tài)啟動(dòng)第三方插件服務(wù)，例如envoy服務(wù)，通過與Rainbond應(yīng)用運(yùn)行時(shí)通信完成從應(yīng)用空間到平臺(tái)空間的數(shù)據(jù)交換，實(shí)現(xiàn)平臺(tái)對(duì)應(yīng)用通信的控制。