分散式政企應用如何快速實現雲原生的微服務架構改造

隨著數字化時代的快速發展，企業和組織正面臨著如何在保持敏捷和靈活的同時，提高業務運營效率和降低成本的巨大挑戰。為了應對這些挑戰，許多企業開始採用面向服務的架構（ 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雲服務中使用相關功能。