隨著數(shù)字化時(shí)代的快速發(fā)展，企業(yè)和組織正面臨著如何在保持敏捷和靈活的同時(shí)，提高業(yè)務(wù)運(yùn)營(yíng)效率和降低成本的巨大挑戰(zhàn)。為了應(yīng)對(duì)這些挑戰(zhàn)，許多企業(yè)開始采用面向服務(wù)的架構(gòu)（SOA）和企業(yè)服務(wù)總線（ESB）來構(gòu)建和集成復(fù)雜的應(yīng)用系統(tǒng)。然而，隨著云計(jì)算和微服務(wù)等新技術(shù)的出現(xiàn)，SOA/ESB架構(gòu)也面臨著一些問題和挑戰(zhàn)。本文將對(duì)SOA/ESB架構(gòu)，在Java語言場(chǎng)景下，如何朝云原生ServiceMesh架構(gòu)演進(jìn)的問題進(jìn)行探討。

SOA/ESB架構(gòu)簡(jiǎn)介和問題概覽

SOA（Service-Oriented Architecture，面向服務(wù)的架構(gòu)）是一種軟件架構(gòu)設(shè)計(jì)方法，它將應(yīng)用程序的功能模塊化為一組可重用的服務(wù)，這些服務(wù)可以通過網(wǎng)絡(luò)進(jìn)行調(diào)用和組合，以支持業(yè)務(wù)流程的執(zhí)行。ESB（Enterprise Service Bus，企業(yè)服務(wù)總線）是SOA架構(gòu)中的關(guān)鍵組件，它提供了一種用于連接和集成各種服務(wù)的中間件平臺(tái)。

SOA/ESB架構(gòu)模式在目前公有云上的典型參考架構(gòu)，以華為云為例，其使用到的典型云服務(wù)為彈性負(fù)載均衡（ELB）和彈性伸縮（AS，包含ECS）。在這種場(chǎng)景下，需要發(fā)起調(diào)用的客戶端程序，通過配置好的域名或地址，直接調(diào)用到ELB上，通過ELB去調(diào)用到后端的ECS服務(wù)器。ELB上需要配置后端服務(wù)器的多個(gè)IP地址。當(dāng)然，一般這類操作可以簡(jiǎn)化為添加某類彈性伸縮組。這樣，當(dāng)ECS發(fā)生彈性伸縮時(shí)管理員無需處理ELB配置，ELB即可自動(dòng)刷新ECS的IP列表的變化。

SOA/ESB架構(gòu)雖然在隔離性、安全性上存在一定優(yōu)點(diǎn)，但是短板也非常明顯。主要包括性能和資源開銷以及運(yùn)維成本。相對(duì)微服務(wù)架構(gòu)，SOA/ESB架構(gòu)上網(wǎng)絡(luò)增加了額外一跳，而且ELB的引入也會(huì)導(dǎo)致資源的額外消耗增多。此外，額外引入了一個(gè)ELB的組件，因此在微服務(wù)之間調(diào)用時(shí)，瓶頸在哪里，ELB是否需要擴(kuò)縮容，都是問題。

微服務(wù)和云原生架構(gòu)改造方法和問題

對(duì)于如何改造SOA/ESB架構(gòu)，朝微服務(wù)架構(gòu)或云原生架構(gòu)演進(jìn)，業(yè)界也有很多方法。主要是以下兩類：

1. 通過修改代碼，將應(yīng)用改造為微服務(wù)架構(gòu)。例如直接在代碼中引入比如SpringCloud的服務(wù)注冊(cè)發(fā)現(xiàn)和負(fù)載均衡等組件。當(dāng)然，這種改造往往也并不簡(jiǎn)單，主要取決于現(xiàn)有應(yīng)用已采用的開發(fā)框架等。比如應(yīng)用本身沒有采用spring來進(jìn)行開發(fā)，那么直接采用SpringCloud可能會(huì)為應(yīng)用帶來海量的改造成本。

2. 采用istio方案，通過有限改造應(yīng)用，將架構(gòu)升級(jí)為ServiceMesh架構(gòu)。之所以該方案說是有限改造，而不是無改造，也是因?yàn)樵诜?wù)調(diào)用方式上，istio方案對(duì)應(yīng)用并不是完全無限制。其至少需要在客戶端將調(diào)用的http調(diào)用地址改造成為k8s原生的服務(wù)地址，調(diào)用的服務(wù)治理才能被envoy有效接管。當(dāng)然，改造完畢后，用戶在接下來在面向邊車的性能衰減，更復(fù)雜的調(diào)用運(yùn)維問題上，恐怕一個(gè)也不會(huì)少。

綜上所述，兩種方案都存在比較明顯的短板。接下來分析下采用Sermant方式進(jìn)行架構(gòu)改造，如何彌補(bǔ)上述兩種方案的短板。

Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的思路

采用Sermant對(duì)SOA/ESB架構(gòu)升級(jí)，本質(zhì)上的最后的架構(gòu)終態(tài)是Service-Mesh。但是因?yàn)椴捎玫姆椒ㄉ杂胁煌?，從而?dǎo)致方案在性能和運(yùn)維問題上都不存在短板。主要是以下兩點(diǎn)：

1. 首先，Sermant采用Java Agent來動(dòng)態(tài)注入增強(qiáng)的服務(wù)邏輯治理，因此應(yīng)用側(cè)理論可以做到完全不用改代碼。

2. 其次，由于Sermant的核心邏輯是以AOP (面向切面編程) 方式，Java Agent和業(yè)務(wù)屬于同一進(jìn)程，因此在性能方面不存在sidecar形態(tài)的特別大的損耗。

在核心技術(shù)點(diǎn)上，Sermant改造方案的功能主要有以下幾個(gè)方面：

1. 內(nèi)置的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制。插件本身會(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í)候，通過微服務(wù)服務(wù)發(fā)現(xiàn)+負(fù)載均衡機(jī)制替代原先的服務(wù)直調(diào)。

2. 域名到服務(wù)名(有時(shí)也稱應(yīng)用名)的轉(zhuǎn)換。服務(wù)發(fā)現(xiàn)時(shí)，由于原先的調(diào)用采用URL直調(diào)，并不包含應(yīng)用信息。這就需要一個(gè)調(diào)用關(guān)系到應(yīng)用名的映射。對(duì)于這塊內(nè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列表。

3. 增強(qiáng)的客戶端側(cè)負(fù)載均衡、重試、隔離、降級(jí)機(jī)制。通過URL獲取Provider應(yīng)用名后，由于在改造過程中，不用Provider應(yīng)用并不是同批次發(fā)布攜帶Sermant Java Agent，因此還需要有個(gè)白名單機(jī)制，來配合灰度發(fā)布。

4. 對(duì)于一些必要的東西向流量的治理能力，如服務(wù)間的3A認(rèn)證等，也需要進(jìn)一步在Sermant端補(bǔ)齊。

采用Sermant對(duì)SOA/ESB架構(gòu)升級(jí)的方案實(shí)操

應(yīng)用改造在具體局點(diǎn)上不可能一蹴而就，因此在具體上實(shí)施上肯定是一個(gè)慢慢灰度的過程。以Kubernetes容器場(chǎng)景為例，介紹下在上百個(gè)微服務(wù)應(yīng)用上千實(shí)例的情況下，如何采用Sermant對(duì)SOA/ESB基于灰度進(jìn)行安全可控的云原生架構(gòu)升級(jí)。

以下為準(zhǔn)備工作：

1. 準(zhǔn)備步驟一：自身應(yīng)用是否支持。當(dāng)前Sermant支持的微服務(wù)升級(jí)的Java框架可以在該文檔中查詢。如未支持，可以考慮給社區(qū)提Issue解決。

2. 準(zhǔn)備步驟二：在Kubernetes中安裝Injector，方便以非侵入方式讓Java應(yīng)用攜帶Sermant Java Agent。具體安裝方法可以參考Sermant官方文檔。

接下來，詳細(xì)介紹實(shí)施過程：

1. 在Kubernetes中對(duì)新版本的App進(jìn)行發(fā)布。新版本的App需要攜帶Sermant Java Agent，可以通過在Kubernetes的Deployment或者StatefulSet中添加annotations來實(shí)現(xiàn)。例如：

```

annotations:

sermant.injector.io/inject: "true"

```

2. 在配置中心，將App加入到白名單中。這樣，當(dāng)Consumer應(yīng)用發(fā)起調(diào)用時(shí)，只有在白名單中的Provider應(yīng)用才會(huì)被調(diào)用。這樣可以確保在灰度發(fā)布過程中，不會(huì)出現(xiàn)因?yàn)椴糠謶?yīng)用未升級(jí)導(dǎo)致的問題。

3. 驗(yàn)證成功后，可以逐步將其他App升級(jí)為攜帶Sermant Java Agent的版本，并將其加入到白名單中。最后，刪除App的舊版本。

Sermant作為專注于服務(wù)治理領(lǐng)域的字節(jié)碼增強(qiáng)框架，致力于提供高性能、可擴(kuò)展、易接入、功能豐富的服務(wù)治理體驗(yàn)。通過采用Sermant對(duì)SOA/ESB架構(gòu)進(jìn)行升級(jí)，企業(yè)和組織可以更快速地實(shí)現(xiàn)云原生的微服務(wù)架構(gòu)改造，從而提高業(yè)務(wù)運(yùn)營(yíng)效率和降低成本。

本文主要介紹了SOA/ESB架構(gòu)的簡(jiǎn)介和問題，以及如何使用Sermant對(duì)SOA/ESB架構(gòu)進(jìn)行升級(jí)。文章認(rèn)為Sermant采用Java Agent來動(dòng)態(tài)注入增強(qiáng)的服務(wù)邏輯治理，并且其核心邏輯是以AOP (面向切面編程) 方式，因此在性能方面不存在sidecar形態(tài)的特別大的損耗。同時(shí)，Sermant方案在實(shí)際操作中也可以實(shí)現(xiàn)灰度發(fā)布，確保應(yīng)用升級(jí)過程的安全可控。因此，對(duì)于分布式政企應(yīng)用如何快速實(shí)現(xiàn)云原生的微服務(wù)架構(gòu)改造，Sermant方案值得關(guān)注和嘗試。

當(dāng)前Sermant已在華為云云服務(wù)CSE中被集成，用戶可以在華為云CSE云服務(wù)中使用相關(guān)功能。

審核編輯黃宇