在以往的文章《云原生微服務(wù)治理技術(shù)朝無(wú)代理架構(gòu)的演進(jìn)之路》中,我們介紹了幾種微服務(wù)架構(gòu)模式,如下圖所示。
今天主要是介紹,第一種SOA/ESB架構(gòu),在Java語(yǔ)言場(chǎng)景下,如何朝第三種 云原生ServiceMesh架構(gòu) 的演進(jìn)的問(wèn)題。
SOA/ESB架構(gòu)簡(jiǎn)介和問(wèn)題概覽
首先我們來(lái)看看 SOA/ESB 架構(gòu)模式 在目前公有云上的典型參考架構(gòu)。
如下圖所示,以華為云為例,以該模式部署應(yīng)用時(shí),其使用到的典型云服務(wù)為 彈性負(fù)載均衡 (ELB) + 彈性伸縮(AS,包含ECS)。在這種場(chǎng)景下:
·需要發(fā)起調(diào)用的客戶(hù)端程序,通過(guò)配置好的域名或地址,直接調(diào)用到ELB上,通過(guò)ELB去調(diào)用到后端的ECS服務(wù)器。
·ELB上需要配置后端服務(wù)器的多個(gè)IP地址。當(dāng)然,一般這類(lèi)操作可以簡(jiǎn)化為添加某類(lèi)彈性伸縮組。這樣,當(dāng)ECS發(fā)生彈性伸縮時(shí)管理員無(wú)需處理ELB配置,ELB即可自動(dòng)刷新ECS的IP列表的變化。
(配置操作可參見(jiàn):
值得注意的是,以上的模式可能存在幾種變種。
·對(duì)于ELB,可能會(huì)采用API網(wǎng)關(guān)替代,或者用戶(hù)自建的KONG, APISIX,Envoy等,具體取決各個(gè)企業(yè)的自身業(yè)務(wù)場(chǎng)景。例如,某些互聯(lián)網(wǎng)公司傾向于采用企業(yè)自建的KONG,其主要原因是除了基本的服務(wù)發(fā)現(xiàn)和負(fù)載均衡能力以外,網(wǎng)關(guān)還需要處理面向內(nèi)部跨域調(diào)用的一些鑒權(quán)情況處理。
·對(duì)于彈性伸縮,可能也會(huì)直接采用Kubernetes的Deployment + HorizontalPodAutoscaler替代。這當(dāng)然取決于企業(yè)內(nèi)部的基礎(chǔ)架構(gòu)采用情況,看是更傾向于使用虛擬機(jī)架構(gòu)還是容器架構(gòu)。
以上架構(gòu)雖然在隔離性、安全性上存在一定優(yōu)點(diǎn),但是短板也非常明顯。
·性能和資源開(kāi)銷(xiāo)。這個(gè)比較好理解,相對(duì)微服務(wù)架構(gòu),SOA/ESB架構(gòu)上網(wǎng)絡(luò)增加了額外一跳,而且ELB的引入也會(huì)導(dǎo)致資源的額外消耗增多。
·運(yùn)維成本。畢竟額外引入了一個(gè)ELB的組件,因此在微服務(wù)之間調(diào)用時(shí),瓶頸在哪里,ELB是否需要擴(kuò)縮容,都是問(wèn)題。
微服務(wù)和云原生架構(gòu)改造方法和問(wèn)題
對(duì)于如何改造 SOA/ESB 架構(gòu),朝微服務(wù)架構(gòu)或云原生架構(gòu)演進(jìn),業(yè)界也有很多方法。主要是以下兩類(lèi)。
通過(guò)修改代碼,將應(yīng)用改造為微服務(wù)架構(gòu)。例如直接在代碼中引入比如SpringCloud的服務(wù)注冊(cè)發(fā)現(xiàn)和負(fù)載均衡等組件。當(dāng)然,這種改造往往也并不簡(jiǎn)單,主要取決于現(xiàn)有應(yīng)用已采用的開(kāi)發(fā)框架等。比如應(yīng)用本身沒(méi)有采用spring來(lái)進(jìn)行開(kāi)發(fā),那么直接采用SpringCloud可能會(huì)為應(yīng)用帶來(lái)海量的改造成本。
·采用istio方案,通過(guò)有限改造應(yīng)用,將架構(gòu)升級(jí)為ServiceMesh架構(gòu)。之所以該方案說(shuō)是有限改造,而不是無(wú)改造,也是因?yàn)樵诜?wù)調(diào)用方式上,istio方案對(duì)應(yīng)用并不是完全無(wú)限制。其至少需要在客戶(hù)端將調(diào)用的http調(diào)用地址改造成為k8s原生的服務(wù)地址,調(diào)用的服務(wù)治理才能被envoy有效接管。當(dāng)然,改造完畢后,用戶(hù)在接下來(lái)在面向邊車(chē)的性能衰減,更復(fù)雜的調(diào)用運(yùn)維問(wèn)題上,恐怕一個(gè)也不會(huì)少。
綜上所述,兩種方案都存在比較明顯的短板。接下來(lái)分析下采用Sermant方式進(jìn)行架構(gòu)改造,如何彌補(bǔ)上述兩種方案的短板。
Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的思路
采用Sermant (https://sermant.io/zh/) 對(duì)SOA/ESB架構(gòu)升級(jí),本質(zhì)上的最后的架構(gòu)終態(tài)是Service-Mesh。但是因?yàn)椴捎玫姆椒ㄉ杂胁煌瑥亩鴮?dǎo)致方案在性能和運(yùn)維問(wèn)題上都不存在短板。主要是以下兩點(diǎn):
·首先,Sermant采用Java Agent來(lái)動(dòng)態(tài)注入增強(qiáng)的服務(wù)邏輯治理,因此應(yīng)用側(cè)理論可以做到完全不用改代碼。
·其次,由于Sermant的核心邏輯是以AOP (面向切面編程) 方式,Java Agent和業(yè)務(wù)屬于同一進(jìn)程,因此在性能方面不存在sidecar形態(tài)的特別大的損耗。
Sermant方案架構(gòu)如下圖所示:
在核心技術(shù)點(diǎn)上,Sermant改造方案的功能主要有以下幾個(gè)方面:
·內(nèi)置的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制。(上圖中的第一點(diǎn)和第三點(diǎn))
-插件本身會(huì)帶服務(wù)注冊(cè)功能,在Provider應(yīng)用啟動(dòng)的時(shí)候自動(dòng)到注冊(cè)中心進(jìn)行服務(wù)注冊(cè)。
- 在Consumer應(yīng)用進(jìn)行URL服務(wù)調(diào)用的時(shí)候,通過(guò)微服務(wù)服務(wù)發(fā)現(xiàn)+負(fù)載均衡機(jī)制替代原先的服務(wù)直調(diào)。
·域名到服務(wù)名(有時(shí)也稱(chēng)應(yīng)用名)的轉(zhuǎn)換。(上圖中的第二點(diǎn))
- 服務(wù)發(fā)現(xiàn)時(shí),由于原先的調(diào)用采用URL直調(diào),并不包含應(yīng)用信息。這就需要一個(gè)調(diào)用關(guān)系到應(yīng)用名的映射。對(duì)于這塊內(nèi)容,未來(lái)我們計(jì)劃做成了一個(gè)動(dòng)態(tài)配置,存儲(chǔ)到配置中心里。這樣當(dāng)有應(yīng)用需要發(fā)起調(diào)用時(shí),Sermant直接將URL轉(zhuǎn)換成應(yīng)用名,就可以在注冊(cè)中心獲取響應(yīng)的應(yīng)用IP列表。
- 通過(guò)URL獲取Provider應(yīng)用名后,由于在改造過(guò)程中,不用Provider應(yīng)用并不是同批次發(fā)布攜帶Sermant Java Agent,因此還需要有個(gè)白名單機(jī)制,來(lái)配合灰度發(fā)布。
·增強(qiáng)的客戶(hù)端側(cè)負(fù)載均衡、重試、隔離、降級(jí)機(jī)制。(上圖中的第四點(diǎn))
- 通過(guò)URL獲取Provider應(yīng)用名后,由于在改造過(guò)程中,不用Provider應(yīng)用并不是同批次發(fā)布攜帶Sermant Java Agent,因此還需要有個(gè)白名單機(jī)制,來(lái)配合灰度發(fā)布。
- 此外,對(duì)于一些必要的東西向流量的治理能力,如服務(wù)間的3A認(rèn)證等,也需要進(jìn)一步在Sermant端補(bǔ)齊。
以上便是Sermant改造方案的主要功能點(diǎn)。另外,在實(shí)操中如何針對(duì)現(xiàn)有環(huán)境進(jìn)行升級(jí)還是需要一定方法,避免對(duì)現(xiàn)有環(huán)境進(jìn)行太大沖擊。以下詳細(xì)敘述。
采用Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的方案實(shí)操
應(yīng)用改造在具體局點(diǎn)上不可能一蹴而就,因此在具體上實(shí)施上肯定是一個(gè)慢慢灰度的過(guò)程。以Kubernetes容器場(chǎng)景為例,介紹下在上百個(gè)微服務(wù)應(yīng)用上千實(shí)例的情況下,如何采用Sermant對(duì)SOA/ESB基于灰度進(jìn)行安全可控的云原生架構(gòu)升級(jí)。
以下為準(zhǔn)備工作:
準(zhǔn)備步驟一:
自身應(yīng)用是否支持。當(dāng)前Sermant支持的微服務(wù)升級(jí)的Java框架可以在該文檔中查詢(xún)。如未支持,可以考慮給社區(qū)提Issue解決。
準(zhǔn)備步驟二:
在Kubernetes中安裝Injector,方便以非侵入方式讓Java應(yīng)用自動(dòng)掛載Sermant Java Agent.
(本步驟可選。如跳過(guò),則需要手動(dòng)改變應(yīng)用部署腳本加載Sermant Java Agent。)
以下介紹詳細(xì)實(shí)施過(guò)程。假設(shè)初始架構(gòu)如下。一共三個(gè)App,其中App1通過(guò)ELB連接到App2和App3。為簡(jiǎn)化表述,圖中為應(yīng)用均為單實(shí)例,實(shí)際生產(chǎn)中的實(shí)例可能會(huì)有多個(gè)。
接下來(lái),在Kubernetes中對(duì)新版本的App1, App2進(jìn)行發(fā)布(圖中為V2版本),并在發(fā)布時(shí)攜帶Sermant Java Agent,以及激活SpringBoot注冊(cè)插件。但是此時(shí)可以先不配置Provider白名單規(guī)則,因此發(fā)布后,應(yīng)用流量應(yīng)該還是走ELB,未發(fā)生任何變化。
接著在配置中心,將App2加入到白名單中。此時(shí),對(duì)識(shí)別到App2的應(yīng)用,掛有Sermant Java Agent的App1實(shí)例 (圖中的V2實(shí)例) 會(huì)對(duì)App2的實(shí)例以負(fù)載均衡方式直接發(fā)起調(diào)用。與此同時(shí),App1訪(fǎng)問(wèn)App3的流量沒(méi)有變化。
驗(yàn)證成功后,刪除App1、 App2的V1版本,App1到App2的流量通過(guò)注冊(cè)中心的注冊(cè)發(fā)現(xiàn),完全實(shí)現(xiàn)直連。同時(shí),App1訪(fǎng)問(wèn)App3的流量維持不變。
此,使用Sermant對(duì)App1、App2的云原生架構(gòu)升級(jí)結(jié)束。后續(xù)其他App應(yīng)用,可以按照類(lèi)似方案,進(jìn)行灰度升級(jí),直至所有應(yīng)用全部掛載上Sermant,完成微服務(wù)直連改造。
結(jié)束語(yǔ)
Sermant 作為專(zhuān)注于服務(wù)治理領(lǐng)域的字節(jié)碼增強(qiáng)框架,致力于提供高性能、可擴(kuò)展、易接入、功能豐富的服務(wù)治理體驗(yàn),并會(huì)在每個(gè)版本中做好性能、功能、體驗(yàn)的看護(hù),廣泛歡迎大家的加入。
當(dāng)前Sermant已在華為云云服務(wù)CSE中被集成,用戶(hù)可以在華為云CSE云服務(wù)中使用相關(guān)功能。
審核編輯:湯梓紅
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
8958瀏覽量
85082 -
SOA
+關(guān)注
關(guān)注
1文章
282瀏覽量
27404 -
微服務(wù)
+關(guān)注
關(guān)注
0文章
131瀏覽量
7322 -
華為云
+關(guān)注
關(guān)注
3文章
2391瀏覽量
17244 -
云原生
+關(guān)注
關(guān)注
0文章
240瀏覽量
7932
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論