詳解Rainbond內(nèi)置ServiceMesh微服務架構

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

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

ServiceMesh

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

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

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

微服務架構對比

為何使用ServiceMesh

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

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

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

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

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

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

最大層度透明

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

學習成本低

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

架構靈活

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

ServiceMesh架構性能

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

對于增加代理響應性能問題在所有的微服務架構中都存在。

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

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

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

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

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

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

對于Rainbond的架構設計來說還通過插件擴展的方式增加以下方面功能：

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

Rainbond與ServiceMesh

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

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

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

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

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