摘要：微服務改造是政企客戶云原生演進的重頭戲，但如何做到成本低、安全性高、性能不變、方便呼叫等，卻是一門學問，本文講述華為云Stack的解決之道，

本文分享自華為云社區《【華為云Stack】【大架光臨】第17期：更安全、更低耗的微服務架構改造之道》，作者：楊奕 華為云技術規劃專家，

在以往的文章《云原生時代，政企混合云場景IT監控和診斷的難點和應對之道》中，我們介紹了幾種微服務架構模式，如下圖所示：

注：圖片來源 https://twitter.com/bibryam/status/1026429379587567616

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

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

首先我們來看看 SOA/ESB 架構 在目前云上架構的典型架構模式，

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

? 需要發起呼叫客戶端的程式，通過配置好的域名或地址，直接呼叫到ELB上，通過ELB去呼叫到后端的ECS服務器，

? ELB上需要配置后端服務器的多個IP地址，當然，一般這類操作可以簡化為添加某類彈性伸縮組，這樣，當ECS發生彈性伸縮時管理員無需處理ELB配置，ELB即可自動重繪ECS的IP串列的變化， (配置操作可參見：https://support.huaweicloud.com/usermanual-as/as_01_0102.html )

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

? 對于ELB，可能會采用API網關替代，或者用戶自建的KONG、APISIX、Envoy等，具體取決各個企業的自身業務場景，例如，某些互聯網公司傾向于采用企業自建的KONG，其主要原因是除了基本的服務發現和負載均衡能力以外，網關還需要處理面向內部跨域呼叫的一些鑒權情況處理，

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

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

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

? 運維成本，畢竟額外引入了一個ELB的組件，因此在微服務之間呼叫時，瓶頸在哪里，ELB是否需要擴縮容，都是問題，

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

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

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

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

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

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

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

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

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

Sermant方案架構如下圖所示：

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

? 內置的服務注冊發現機制，(上圖中的第一點和第三點) 

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

? 域名到應用名的轉換，(上圖中的第二點)

• 服務發現時，由于原先的呼叫采用URL直調，并不包含應用資訊，這就需要一個呼叫關系到應用名的映射，對于這塊內容，未來我們計劃做成一個動態配置，存盤到配置中心里，這樣當有應用需要發起呼叫時，Sermant直接將URL轉換成應用名，就可以在注冊中心獲取回應的應用IP串列，
• 通過URL獲取Provider應用名后，由于在改造程序中，不用Provider應用并不是同批次發布攜帶Sermant JavaAgent，因此還需要有個白名單機制，來配合灰度發布，

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

• 結合上一步，完整的商用方案，Consumer呼叫Provider除了需要滿足基本的負載均衡功能以外，還需要更進一步進行重試、容錯隔離、以及對下游的限流降級處理，
• 此外，對于一些必要的東西向流量的治理能力，如服務間的3A認證等，也需要進一步在Sermant端補齊，

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

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

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

以下為準備作業：

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

• 參考鏈接：https://sermant.io/zh/document/plugin/springboot-registry.html#%E8%AF%A6%E7%BB%86%E6%B2%BB%E7%90%86%E8%A7%84%E5%88%99

? 準備步驟二：在Kubernetes中安裝Injector，方便以非侵入方式讓Java應用自動掛載Sermant JavaAgent.

• 本步驟可選，如跳過，則需要手動改變應用部署腳本加載sermant javaAgent，
• 參考鏈接：https://sermant.io/zh/document/user-guide/injector.html

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

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

接著在配置中心，將App2加入到白名單中，此時，對識別到App2的應用，掛有Sermant Javaagent的App1實體 (圖中的V2實體) 會對App2的實體以負載均衡方式直接發起呼叫，與此同時，App1訪問App3的流量沒有變化，

驗證成功后，洗掉App1、 App2的V1版本，App1到App2的流量通過注冊中心的注冊發現，完全實作直連，同時，App1訪問App3的流量維持不變，

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

結束語

Sermant  作為專注于服務治理領域的位元組碼增強框架，致力于提供高性能、可擴展、易接入、功能豐富的服務治理體驗，并會在每個版本中做好性能、功能、體驗的看護，

當前Sermant已在Huawei Cloud Stack (HCS)中的ROMA Factory被集成，用戶可以在華為云Stack ROMA Factory中使用相關功能，
https://www.huaweicloud.com/zhishi/solution-ROMA-Factory-jiagou.html

開發者也可以加入到Sermant社區，參與相關功能的討論和共建，

? Sermant 官網：https://sermant.io

? GitHub 倉庫地址：https://github.com/huaweicloud/Sermant

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：如何提升智能檔案處理識別精度？合合資訊“版面分析”實作新突破

下一篇：編程體驗2