雲原生微服務治理技術朝無代理架構的演進之路
摘要：本文基於對微服務治理技術從SOA, 微服務框架，到雲原生架構的歷史發展總結，提出了一種新的基於Javaagent技術的新一代無代理架構的服務治理技術，並介紹了其相關的代表性開源專案Sermant。
本文分享自華為雲社群《雲原生微服務治理技術朝無代理架構的演進之路》，作者： 楊奕｜華為雲技術規劃專家。
微服務治理技術發展趨勢
對於雲原生的歸納，業界從來沒有停止過演進。但是總體來講，微服務和容器化基本上是兩個永恆不變的話題。今天這篇文章重點來談談微服務架構的演進。
微服務這個詞，比較公認的官方正式介紹來自 Martin Fowler 在2014年釋出的 Microservices 一書。但是實際上，其解決的服務解耦的問題，最早可以追述到SOA (Service-Oriented Architecture，面向服務的架構)。下面這種圖 (參考連結
圖例1：服務架構的演進歷程：SOA -> 微服務框架 -> 雲原生
總體來講，微服務的迭代發展到目前為止，分為三個階段。
- SOA：該階段針對政企場景的煙囪式架構，通過集中式中心閘道器方式，解決異構應用之間的快速整合問題。該階段，服務治理功能集中在中心閘道器上，效能和可靠性上也都有較大問題。
- 微服務框架：主要針對大規模高併發場景，通過去中心閘道器、做厚客戶端的方式，使得企業內部應用可快速解耦和橫向擴容，以滿足業務快速發展需求。該階段，服務治理功能一般通過SDK，部署在業務程式上，輔以註冊中心和配置中心進行服務管理。雖然效能和可靠性得到解決，但是服務治理邏輯和業務邏輯存在一定程度耦合，在應用生命週期迭代上存在一定問題。
- 雲原生 Service Mesh：將更多的服務治理能力沉澱到雲平臺上，應用只關注業務邏輯，服務治理和應用徹底解耦，應用快速迭代得到解放。該階段，服務治理功能以代理邊車方式沉澱到容器內，應用時在執行時掛載邊車即可，具體的服務治理控制邏輯由雲平臺(如圖中 Kubernetes/Service Mesh)承接。
在以上架構圖中，SOA不是本文重點。關於SOA到微服務的演進，感興趣可以參考文章 《 SOA 和微服務的區別》 一文。本文以下章節重點介紹其他的 微服務框架 和 雲原生 Service Mesh 這兩個階段的微服務治理架構特點。
微服務框架 架構
如前文所述，微服務的的名詞比較正式被普及可歸公於 Martin Fowler 在2014年撰寫的 Microservices 一書。但是實際上，國內的微服務起源反而更早。比較出名的是是阿里早期的HSF和Dubbo。正如“ Dubbo
”Dubbo專案誕生於2008年，起初只在一個阿里內部的系統使用；2011年，阿里B2B決定將整個專案開源，僅用了一年時間就收穫了來自不同行業的大批使用者；2014年，由於內部團隊調整，Dubbo暫停更新；2017年9月，Dubbo 3重啟開源，在2019年5月由Apache孵化畢業，成為第二個由阿里巴巴捐獻至Apache畢業的專案。“
文摘1：Dubbo阿里內部的演進歷史
在海外，雖然RPC框架類元件塵出不窮，但是真正將服務治理納入一體，而且幾乎成為事實標準的，當屬 Spring Cloud 。雖然專案是2016年才開始正式釋出，但論流行程度，不光在世界範圍論堪稱一哥，在中國國內，風頭也幾乎蓋過Dubbo。
圖例2：Dubbo 和 SpringCloud 在國內的搜尋熱度。藍色是Dubbo，紅色是SpringCloud
Dubbo和SpringCloud的具體發展歷程，這裡不多做介紹，大家可以翻翻其他相關介紹。這裡重點突出一個兩套框架的一個共同特點，無論是Dubbo，以及後來的SpringCloud，都不光是一套RPC框架。其除了方便研發直接基於RPC模式開發微服務架構的業務以外，自身還有很多擴充套件點，方便服務治理開發人員以獨立Jar包方式進行服務治理功能的單獨開發。比如：Dubbo比較耳熟能詳的是自身的基於SPI擴充套件點機制來實現服務治理；而SpringCloud則是通過SpringBoot機制，通過開發者開發starter包來實現服務治理。兩者基本都能做到服務治理功能對業務程式碼解耦。例如SpringCloud，對於引入新的服務治理功能，很多時候對於開發者來說只需要引入一個starter的pom依賴。不過這也引入一個問題，任何服務治理的功能升級，雖然對於業務程式碼來說只是更新配置檔案，但是畢竟還是動了業務程式碼，這也給服務治理功能的升級帶來潛在阻力。隨著業務規模增長，該問題也會被指數級放大。
基於以上問題，需要指出一個極其重要的但是容易被忽略大家忽略的事實，就是微服務治理能否在一個大廠內能否大規模鋪開使用，很重要的因素是服務治理能否和業務在軟體開發和釋出上解耦。阿里之所以微服務內部推廣和演進比較順利，筆者認為很大原因是阿里內部採用的微服務框架HSF很早集成了Pandora 容器這項技術。這個不起眼的技術，其實起了一個至關重要的作用：服務治理功能和業務功能在程式碼上徹底解耦，治理功能的jar包可以在不改變業務程式碼情況下單獨釋出；且在此基礎上實現了治理功能和業務功能類隔離，防止類衝突。
圖例3：據阿里巴巴微服務實踐一文介紹，通過Pandora，業務和中介軟體邏輯釋出得到完全解耦。
阿里內部的Pandora容器技術，雖然在外曝光度不高。但是在阿里的服務治理領域起到了至關重要的作用。正是因為有了Pandora，阿里的業務開發人員才能做到 "治理功能萬千重，我自巋然不動"。阿里歷史上每年雙11前幾個月，在業務近乎無感情況下，微服務框架批量搞幾次大版本升級，也基本就能滿足每年大促的服務治理需求。
而其他如採用SpringCloud技術棧的大廠，在沒有類似Pandora容器的隔離技術情況下，隨著業務規模增長，服務治理能力的演進將越來越痛苦。每釋出一個重要版本或重要補丁，服務治理團隊就需要思考如何去說服上千個業務方進行SDK升級，就成了一件讓人非常頭疼的事。因此，服務治理功能如何和業務功能在架構上如何解耦，就成了後來微服務治理一個剛需。這也是後續Istio等邊車服務治理方案興起的一大原因。
雲原生 Proxy (邊車代理) 服務治理 架構
在CloudNative時代的服務治理架構中，Service-mesh因為其對應用的無侵入性，成為了雲原生服務治理的一個經典流派。而在Service-mesh流派中，Istio又是其中一個代表作。Istio的興起，其實核心是因為解決了兩個問題。
- 多語言架構下的服務治理功能統一。無論是java、go、c++等語言，只要通訊協議一致，理論上都可以通過邊車程序來進行服務治理。
- 通過代理程序方式，實現治理功能對業務程式碼的非侵入，架構上和業務充分解耦。
圖例4：Istio社群中火了5年的書店demo程式，集 python、ruby、node.js、java 等各類開發語言
關於Istio的功能和架構介紹，網上文章多如牛毛，本文就不贅訴了。但是這裡核心講下Istio在實踐中遇到的幾個問題。
- 非侵入的相容性。本來非侵入是istio的主打優勢，但是社群版的istio有個核心問題，就是是基於gRPC協議構建的。這就使得istio在國內落地時，面對國內dubbo治理框架是個事實標準之一的情況，顯得有點水土不服。這在大多數雲廠商的istio商業版中對Dubbo的各種“蹩腳”支援可見一斑。雖然dubbo社群也在主動朝3.0開始演進，相容gRPC協議，但是其成熟度仍尚存很長距離。
- 服務治理，功能也很豐富，但是有缺陷。在長長的xDS協議的功能列表中，從服務註冊發現，到限流降級，到餛飩工程，可謂玲瓏滿面。但是基於Proxy邊車的服務治理方案中，一大硬傷是Proxy邊車程序畢竟是個和業務無關的程序，本身無法侵入到業務程序，因此任何需要在業務程序透傳標識的場景全部都不支援。典型比如分散式鏈路Tracing ID的透傳，還比如一些全鏈路灰度釋出的路由標的透傳，等。以上兩個問題，都可參考 Proxyless Service Mesh 在百度的實踐與思考 一文中有詳細闡述。
圖例5：百度在 Proxy Service Mesh 實踐中因為邊車無法侵入程序，所遇到的問題
- 架構上，由於採用了單獨程序，無論是效能和運維上，和SDK流派相比還是有差距。一方面，在各種基準效能測試中，額外的響應時間穩定增加1.7ms以上，參見istio Performance and Scalability 。另外一方面，在落地時，sidecar conatiner的規格設定也是個令人頭疼的問題：vcpu和記憶體設得小了，效能不夠；設得大了，浪費資源；按應用各自效能特點設定，又造成額外管理成本。
圖例6：Istio社群中最新發布的效能測試。測試現實，增加邊車，效能損耗至少增加1.5ms
基於以上各種原因，原生的istio的落地實踐中，都多少處於叫好不叫座的尷尬境界。接下來就Proxy邊車治理方案的問題，說說為啥最近Proxyless邊車治理方案開始逐漸異軍突起。
雲原生 Proxyless (無代理) 服務治理 架構
Proxyless服務治理，原本出處是 gRPC Proxyless Service Mesh . 原文字意是基於gRPC，結合xDS協議，做了一個服務治理框架。gRPC Proxyless Service Mesh的提出，筆者認為，本質上是因為proxy治理架構的各種各樣的問題，導致istio團隊重新思考適基於現成的xDS協議，把服務治理的大部分功能重新做到了框架內部。從架構上看起來gRPC Proxyless Service Mesh更像是走了一次微服務框架流派的歷史倒車，把業務和治理框架耦合在了一起。
圖例7：左邊是 gRPC Proxyless Service Mesh 最新發表的架構圖，右側是 Dubbo 幾乎10年前的架構圖，是不是何其相似
那麼有沒有一種 Proxyless 邊車方案，既能具備邊車方案的各種解耦優點，又能一定程度上克服Proxy帶來的問題呢？答案是 Javaagent。
Javaagent的位元組碼增強技術很早就有。真正發揮商業價值的地方其實是在2015年前後的所謂APM元年，其被大量使用在APM領域。但是這個javaagent這個技術在服務治理領域火起來的，也是最近兩年的事。這裡面主要發生兩件值得一提的事：
- Apache Skywalking 這個開源APM工具，作為國內Apache的頂級專案，把javaagent技術在國內好好普及了一把。最終結果是各個網際網路中小廠商基本上java程序上都掛了一個skywalking javaagent的同時，該技術都普遍接受。 （筆者見過不少政企和網際網路廠商，甚至掛了一個skywalking javaagent的同時，又掛了一個基於skywalking修改的javaagent，其使用場景涵蓋各種服務治理場景。）
- 基於對javaagent技術的接受基礎上，以Java技術棧為主的各類網際網路大廠和雲廠商開始內外大量使用Javaagent技術做服務治理和相關商業化產品。總體上講，之前業界對javaagent做服務治理基本上都持觀望態度。現在基本上也不質疑了，大家現在思考的問題都變成了怎麼把javaagent在服務治理領域如何發揮到極致。
為啥javaagent技術這麼火？這是因為其相比傳統SDK和Servicemesh技術：
- 非侵入架構：這點和Sidecar架構類似，治理能力開箱即用，業務方程式碼務虛改造，上車成本極低。而且相比傳統邊車技術，沒有額外程序，執行態和開發態的差異進一步降低。
- 治理功能和業務程式碼升級解耦：相比SDK升級動輒需要去各業務方推廣，非侵入這塊這塊能力確實比SDK實際體驗好太多。試想一下，治理功能快速迭代的同時，業務方只需晚上滾動重啟一下即可獲得新的治理功能，這對服務治理團隊和業務團隊都是一種生產力的解放。
- 相比傳統邊車方案，效能更好，資源消耗更低 ：畢竟傳統邊車方案動輒2ms以上的延時增加，以及額外的程序資源開銷，對業務都是不小的負擔。而javaagent這塊由於採用和SDK雷同的AOP服務治理方式，效能幾乎和SDK持平。
- 治理場景多樣：實踐證明，在場景上，Javaagent > SDK > 邊車架構。Javaagent的場景比邊車方案多，這個好理解，畢竟Javaagent可以注入到使用者程序中，完成很多流量標透傳的場景，這塊是邊車架構無法做到的。但是Javaagent為何場景比SDK方案還要多？這是因為一般如Dubbo, SpringCloud等治理方案，其預設需要對應的RPC函式提供相應的函式埋點。但是很多服務治理場景，如流量錄製回放，對應的一些遠端呼叫，如Redis呼叫，本身並不提供函式埋點，因此通過SDK來攔截流量進行錄製和回訪就無從談起。而基於Javaagent的位元組碼增強技術則沒有這個限制。
圖例8：(原創首發)Javaagent對其他服務治理對比的優勢
當然，Javaagent的服務治理技術也並非銀彈。
- Javaagent最大的問題是服務治理場景只能用於Java。如果您所在公司，主流開發預言是非Java類，那麼還是放棄吧。但是如果您所在公司，主流開發語言是java, 但是有很多長尾應用語言是其他語種怎麼辦？這裡開發者可以考慮 傳統邊車 + javaagent 方案，javaagent負責主流的Java語言微服務的服務治理，而傳統邊車方案負責其他多語言的服務治理。至於兩者的服務治理打通，業界也有很多方案，如Javaagent同時對接基本的xDS協議，也可以完成兩者服務的打通。
- 這裡也稍微提個不大不小的問題，就是當多個javaagent對同一個類進行增強的時候，有時候會產生增強衝突的異常。其實這塊很多場景是因為各類javaagent開發不規範的原因，是完全可以避免的。相關詳細的問題就不展開了，大家如果敢興趣的話，可以去看下相關文章 記一次多個 JavaAgent 同時使用的 類增強 衝突問題及分析 。這裡就摘出要文章核心摘要：
"嚴格遵守位元組碼增強的使用要求和限制。無論是Byte Buddy、Javassist還是ASM，底層實現都離不開JDK1.5之後引入的Instrumentation介面。既然官方介面的設計理念是reTransformClasses()增強類時不能新增、刪除或者重新命名欄位和方法，不能更改方法的簽名，也不能更改類的繼承關係，那作為JavaAgent的框架開發者，應該不要做出超越上述限制的設計，否則極易導致JavaAgent之間的相容性問題出現。不僅僅是這個介面，JavaAgent框架的開發者也需要遵循所有的位元組碼增強的底層介面的設計理念，畢竟有規則才有秩序。"
文摘2："記一次多個JavaAgent同時使用的類增強衝突問題及分析" 文中對避免Javaagent衝突的建議。
華為雲的sermant開源專案
用javaagent做服務治理很想，但是實際上手怎麼搞？ 華為雲在早期接觸的很多客戶場景中，發現很多架構團隊都是拿已有的開源的 javaagent 相關的專案上手魔改做自己的服務治理能力。但是做著做著很快發現了幾個問題。
- 我們目標的服務治理功能很多，但是一般開源專案如pinpoint, skywalking等增強的點就那麼一個，比如如果在服務呼叫增強點上實施了鏈路追蹤邏輯以後，再加其他比如限流降級功能，就需要在Plugin中寫很多限流降級邏輯，這些程式碼邏輯會和已有的開源專案的原生治理邏輯糾纏不清。
- 很多服務治理功能本身邏輯可能比較重，有其自身的三方依賴依賴庫。但是世面上已有的Javaagent，並不支援針對元件級別的類隔離機制。
- 服務治理場景有很多通用邏輯，除了方便快速的對特定函式介面做增強以外，還包括可替換的實時配置中心，基於RPC的Tag透傳，通用的Metrics上報機制。能否把這些能力都沉澱出來，以SDK API方式暴露給開發者直接使用，這樣可以極大提高服務治理的開發效率。
以上幾個原因，促使我們思考是否應該做一個新的javaagent服務治理專案，來解決以上問題。這就是sermant專案由來。我們希望通過Sermant專案，
- 服務治理功能以外掛形式裝載到javaagent中，不同外掛間可以做到對同一個業務函式增強點進行不同增強，且互不衝突。最終所有服務治理統一到一個javaagent中，降低資源損耗。。
- 服務治理外掛之間同時需要做到類隔離，以降低不通版本的三方庫依賴造成的類載入衝突風險。
- javaagent本身能提供一層厚度適中的framework能力，幫助外掛快速開發服務治理能力。專案之初，我們提出至少三個目標需要嘗試實現：
- 實時配置中心抽象。無論用ZooKeeper, Nacos, 還是Servicecomb，都不影響外掛使用統一framework提供的實時配置的能力。以此做到實時配置連線收斂。
- payload資料透傳能力。我們希望framework提供SDK，無論是tracing id透傳，還是全鏈路灰度標透傳，都能基於資料透傳能力快速開發治理功能。
- 監控能力。按照規範開發的外掛最後都能在後端平臺上對所有的javaagent和其載入的plugin做統一監控。
圖例9：Sermant 的框架、外掛架構
路走對了，就不怕遠。到今天，在公司內外生態夥伴的貢獻下，Sermant名下已有各類服務治理外掛已多達數十種，場景覆蓋包括 服務註冊發現改造、服務契約查詢、服務血緣關係發現、服務雙註冊、配置治理、流量錄製回放、限流降級、優雅上下線、全流量標籤路由、同機房呼叫優先、故障注入、效能監控、等等。我們同時將規劃更多的框架層能力，以輔助增強Sermant服務治理總體能力，進一步降低外掛開發難度。這包括：外掛動態插拔能力，應用無需重啟應用，即可線上升級服務治理功能；外掛增強順序動態調配，對於同一個函式增強點，不同外掛可以按需調整順序，如效能監控外掛在限流降級外掛之前生效，以保證服務治理邏輯正確；等等。
如果您對以上細節感興趣，我們誠摯歡迎你來社群使用Sermant。
圖例10：Sermant的社群介紹
歡迎使用Sermant
Sermant社群當前快速成長中，當前開原始碼倉地址：https://github.com/huaweicloud/Sermant
Sermant目前部分服務治理功能已在華為雲產品中提供商業化服務，華為雲使用者可在 微服務引擎 CSE 中使用相關功能: https://www.huaweicloud.com/product/cse.html
政企客戶亦可在最新的HCS產品中使用相關Sermant功能。該功能在ROMA-Factory已支援部分場景的PoC。