分布式政企應用如何快速實現(xiàn)云原生的微服務架構改造

在以往的文章《云原生微服務治理技術朝無代理架構的演進之路》中，我們介紹了幾種微服務架構模式，如下圖所示。

今天主要是介紹，第一種SOA/ESB架構，在Java語言場景下，如何朝第三種 云原生ServiceMesh架構 的演進的問題。

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

首先我們來看看 SOA/ESB 架構模式 在目前公有云上的典型參考架構。

如下圖所示，以華為云為例，以該模式部署應用時，其使用到的典型云服務為 彈性負載均衡 (ELB) + 彈性伸縮(AS，包含ECS)。在這種場景下：

·需要發(fā)起調(diào)用的客戶端程序，通過配置好的域名或地址，直接調(diào)用到ELB上，通過ELB去調(diào)用到后端的ECS服務器。

·ELB上需要配置后端服務器的多個IP地址。當然，一般這類操作可以簡化為添加某類彈性伸縮組。這樣，當ECS發(fā)生彈性伸縮時管理員無需處理ELB配置，ELB即可自動刷新ECS的IP列表的變化。

(配置操作可參見：

值得注意的是，以上的模式可能存在幾種變種。

·對于ELB，可能會采用API網(wǎng)關替代，或者用戶自建的KONG, APISIX,Envoy等，具體取決各個企業(yè)的自身業(yè)務場景。例如，某些互聯(lián)網(wǎng)公司傾向于采用企業(yè)自建的KONG，其主要原因是除了基本的服務發(fā)現(xiàn)和負載均衡能力以外，網(wǎng)關還需要處理面向內(nèi)部跨域調(diào)用的一些鑒權情況處理。

·對于彈性伸縮，可能也會直接采用Kubernetes的Deployment + HorizontalPodAutoscaler替代。這當然取決于企業(yè)內(nèi)部的基礎架構采用情況，看是更傾向于使用虛擬機架構還是容器架構。

以上架構雖然在隔離性、安全性上存在一定優(yōu)點，但是短板也非常明顯。

·性能和資源開銷。這個比較好理解，相對微服務架構，SOA/ESB架構上網(wǎng)絡增加了額外一跳，而且ELB的引入也會導致資源的額外消耗增多。

·運維成本。畢竟額外引入了一個ELB的組件，因此在微服務之間調(diào)用時，瓶頸在哪里，ELB是否需要擴縮容，都是問題。

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

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

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

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

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

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

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

·首先，Sermant采用Java Agent來動態(tài)注入增強的服務邏輯治理，因此應用側(cè)理論可以做到完全不用改代碼。

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

Sermant方案架構如下圖所示：

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

·內(nèi)置的服務注冊發(fā)現(xiàn)機制。(上圖中的第一點和第三點)

-插件本身會帶服務注冊功能，在Provider應用啟動的時候自動到注冊中心進行服務注冊。

- 在Consumer應用進行URL服務調(diào)用的時候，通過微服務服務發(fā)現(xiàn)+負載均衡機制替代原先的服務直調(diào)。

·域名到服務名(有時也稱應用名)的轉(zhuǎn)換。(上圖中的第二點)

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

- 通過URL獲取Provider應用名后，由于在改造過程中，不用Provider應用并不是同批次發(fā)布攜帶Sermant Java Agent，因此還需要有個白名單機制，來配合灰度發(fā)布。

·增強的客戶端側(cè)負載均衡、重試、隔離、降級機制。(上圖中的第四點)

- 通過URL獲取Provider應用名后，由于在改造過程中，不用Provider應用并不是同批次發(fā)布攜帶Sermant Java Agent，因此還需要有個白名單機制，來配合灰度發(fā)布。

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

以上便是Sermant改造方案的主要功能點。另外，在實操中如何針對現(xiàn)有環(huán)境進行升級還是需要一定方法，避免對現(xiàn)有環(huán)境進行太大沖擊。以下詳細敘述。

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

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

以下為準備工作：

準備步驟一：

自身應用是否支持。當前Sermant支持的微服務升級的Java框架可以在該文檔中查詢。如未支持，可以考慮給社區(qū)提Issue解決。

準備步驟二：

在Kubernetes中安裝Injector，方便以非侵入方式讓Java應用自動掛載Sermant Java Agent.

（本步驟可選。如跳過，則需要手動改變應用部署腳本加載Sermant Java Agent。）

以下介紹詳細實施過程。假設初始架構如下。一共三個App，其中App1通過ELB連接到App2和App3。為簡化表述，圖中為應用均為單實例，實際生產(chǎn)中的實例可能會有多個。

接下來，在Kubernetes中對新版本的App1, App2進行發(fā)布(圖中為V2版本)，并在發(fā)布時攜帶Sermant Java Agent，以及激活SpringBoot注冊插件。但是此時可以先不配置Provider白名單規(guī)則，因此發(fā)布后，應用流量應該還是走ELB，未發(fā)生任何變化。

接著在配置中心，將App2加入到白名單中。此時，對識別到App2的應用，掛有Sermant Java Agent的App1實例 (圖中的V2實例) 會對App2的實例以負載均衡方式直接發(fā)起調(diào)用。與此同時，App1訪問App3的流量沒有變化。

驗證成功后，刪除App1、 App2的V1版本，App1到App2的流量通過注冊中心的注冊發(fā)現(xiàn)，完全實現(xiàn)直連。同時，App1訪問App3的流量維持不變。

此，使用Sermant對App1、App2的云原生架構升級結(jié)束。后續(xù)其他App應用，可以按照類似方案，進行灰度升級，直至所有應用全部掛載上Sermant，完成微服務直連改造。

結(jié)束語

Sermant 作為專注于服務治理領域的字節(jié)碼增強框架，致力于提供高性能、可擴展、易接入、功能豐富的服務治理體驗，并會在每個版本中做好性能、功能、體驗的看護，廣泛歡迎大家的加入。

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

審核編輯：湯梓紅