快捷導(dǎo)航

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

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

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

ServiceMesh

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

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

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

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

為何使用ServiceMesh

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

在傳統(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 這樣的 “胖客戶端” 庫，這些就是早期的 ServiceMesh，但是它們都近適用于特定的環(huán)境和特定的開發(fā)語言，并不能作為平臺級的 ServiceMesh 支持。

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

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

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

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

最大層度透明

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

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

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

架構(gòu)靈活

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

ServiceMesh架構(gòu)性能

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

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

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

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

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

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

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

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

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

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

Rainbond與ServiceMesh

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

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

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

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

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