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

SOA/ESB架構簡介和問題概覽

SOA（Service-Oriented Architecture，面向服務的架構）是一種軟件架構設計方法，它將應用程序的功能模塊化為一組可重用的服務，這些服務可以通過網絡進行調用和組合，以支持業務流程的執行。ESB（Enterprise Service Bus，企業服務總線）是SOA架構中的關鍵組件，它提供了一種用于連接和集成各種服務的中間件平臺。

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

SOA/ESB架構雖然在隔離性、安全性上存在一定優點，但是短板也非常明顯。主要包括性能和資源開銷以及運維成本。相對微服務架構，SOA/ESB架構上網絡增加了額外一跳，而且ELB的引入也會導致資源的額外消耗增多。此外，額外引入了一個ELB的組件，因此在微服務之間調用時，瓶頸在哪里，ELB是否需要擴縮容，都是問題。

微服務和云原生架構改造方法和問題

對于如何改造SOA/ESB架構，朝微服務架構或云原生架構演進，業界也有很多方法。主要是以下兩類：

1. 通過修改代碼，將應用改造為微服務架構。例如直接在代碼中引入比如SpringCloud的服務注冊發現和負載均衡等組件。當然，這種改造往往也并不簡單，主要取決于現有應用已采用的開發框架等。比如應用本身沒有采用spring來進行開發，那么直接采用SpringCloud可能會為應用帶來海量的改造成本。

2. 采用istio方案，通過有限改造應用，將架構升級為ServiceMesh架構。之所以該方案說是有限改造，而不是無改造，也是因為在服務調用方式上，istio方案對應用并不是完全無限制。其至少需要在客戶端將調用的http調用地址改造成為k8s原生的服務地址，調用的服務治理才能被envoy有效接管。當然，改造完畢后，用戶在接下來在面向邊車的性能衰減，更復雜的調用運維問題上，恐怕一個也不會少。

綜上所述，兩種方案都存在比較明顯的短板。接下來分析下采用Sermant方式進行架構改造，如何彌補上述兩種方案的短板。

Sermant對SOA/ESB架構升級的思路

采用Sermant對SOA/ESB架構升級，本質上的最后的架構終態是Service-Mesh。但是因為采用的方法稍有不同，從而導致方案在性能和運維問題上都不存在短板。主要是以下兩點：

1. 首先，Sermant采用Java Agent來動態注入增強的服務邏輯治理，因此應用側理論可以做到完全不用改代碼。

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

在核心技術點上，Sermant改造方案的功能主要有以下幾個方面：

1. 內置的服務注冊發現機制。插件本身會帶服務注冊功能，在Provider應用啟動的時候自動到注冊中心進行服務注冊。在Consumer應用進行URL服務調用的時候，通過微服務服務發現+負載均衡機制替代原先的服務直調。

2. 域名到服務名(有時也稱應用名)的轉換。服務發現時，由于原先的調用采用URL直調，并不包含應用信息。這就需要一個調用關系到應用名的映射。對于這塊內容，未來我們計劃做成了一個動態配置，存儲到配置中心里。這樣當有應用需要發起調用時，Sermant直接將URL轉換成應用名，就可以在注冊中心獲取響應的應用IP列表。

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

4. 對于一些必要的東西向流量的治理能力，如服務間的3A認證等，也需要進一步在Sermant端補齊。

采用Sermant對SOA/ESB架構升級的方案實操

應用改造在具體局點上不可能一蹴而就，因此在具體上實施上肯定是一個慢慢灰度的過程。以Kubernetes容器場景為例，介紹下在上百個微服務應用上千實例的情況下，如何采用Sermant對SOA/ESB基于灰度進行安全可控的云原生架構升級。

以下為準備工作：

1. 準備步驟一：自身應用是否支持。當前Sermant支持的微服務升級的Java框架可以在該文檔中查詢。如未支持，可以考慮給社區提Issue解決。

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

接下來，詳細介紹實施過程：

1. 在Kubernetes中對新版本的App進行發布。新版本的App需要攜帶Sermant Java Agent，可以通過在Kubernetes的Deployment或者StatefulSet中添加annotations來實現。例如：

```

annotations:

sermant.injector.io/inject: "true"

```

2. 在配置中心，將App加入到白名單中。這樣，當Consumer應用發起調用時，只有在白名單中的Provider應用才會被調用。這樣可以確保在灰度發布過程中，不會出現因為部分應用未升級導致的問題。

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

Sermant作為專注于服務治理領域的字節碼增強框架，致力于提供高性能、可擴展、易接入、功能豐富的服務治理體驗。通過采用Sermant對SOA/ESB架構進行升級，企業和組織可以更快速地實現云原生的微服務架構改造，從而提高業務運營效率和降低成本。

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

當前Sermant已在華為云云服務CSE中被集成，用戶可以在華為云CSE云服務中使用相關功能。

審核編輯黃宇