摘要：微服務改造是政企客戶雲原生演進的重頭戲，但如何做到成本低、安全性高、效能不變、方便呼叫等，卻是一門學問。本文講述華為雲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解決。
• 準備步驟二：在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