雲原生微服務治理技術朝無代理架構的演進之路

本文分享自華為雲社群《雲原生微服務治理技術朝無代理架構的演進之路-雲社群-華為雲》，作者： 楊奕 華為雲技術規劃專家。

微服務治理技術發展趨勢

對于雲原生的歸納，業界從來沒有停止過演進。但是總體來講，微服務和容器化基本上是兩個永恒不變的話題。今天這篇文章重點來談談微服務架構的演進。

微服務這個詞，比較公認的官方正式介紹來自 Martin Fowler 在2014年釋出的 Microservices 一書。但是實際上，其解決的服務解耦的問題，最早可以追述到SOA (Service-Oriented Architecture，面向服務的架構)。下面這種圖 (參考連結：https://twitter.com/bibryam/status/1026429379587567616 ) 比較好的诠釋了服務的演進曆程。從最早的SOA，到本世紀10年代的微服務，到最後的雲原生微服務架構的Servicemesh，核心都是為了解決在企業的複雜業務場景下，讓各服務以解耦方式各自獨立快速疊代。

圖例1：服務架構的演進曆程：SOA -> 微服務架構 -> 雲原生

總體來講，微服務的疊代發展到目前為止，分為三個階段。

• SOA：該階段針對政企場景的煙囪式架構，通過集中式中心網關方式，解決異構應用之間的快速內建問題。該階段，服務治理功能集中在中心網關上，性能和可靠性上也都有較大問題。

• 微服務架構：主要針對大規模高并發場景，通過去中心網關、做厚用戶端的方式，使得企業内部應用可快速解耦和橫向擴容，以滿足業務快速發展需求。該階段，服務治理功能一般通過SDK，部署在業務程式上，輔以注冊中心和配置中心進行服務管理。雖然性能和可靠性得到解決，但是服務治理邏輯和業務邏輯存在一定程度耦合，在應用生命周期疊代上存在一定問題。

• 雲原生 Service Mesh：将更多的服務治理能力沉澱到雲平台上，應用隻關注業務邏輯，服務治理和應用徹底解耦，應用快速疊代得到解放。該階段，服務治理功能以代理邊車方式沉澱到容器内，應用時在運作時挂載邊車即可，具體的服務治理控制邏輯由雲平台(如圖中 Kubernetes/Service Mesh)承接。

在以上架構圖中，SOA不是本文重點。關于SOA到微服務的演進，感興趣可以參考文章 《 面試官靈魂三問：什麼是SOA？什麼是微服務？SOA和微服務有什麼差別？-雲社群-華為雲》 一文。本文以下章節重點介紹其他的 微服務架構 和 雲原生 Service Mesh 這兩個階段的微服務治理架構特點。

微服務架構 架構

如前文所述，微服務的的名詞比較正式被普及可歸公于 Martin Fowler 在2014年撰寫的 Microservices 一書。但是實際上，國内的微服務起源反而更早。比較出名的是是阿裡早期的HSF和Dubbo。正如“ Dubbo 和 HSF 在阿裡巴巴的實踐：攜手走向下一代雲原生微服務 ”一文中所述，阿裡最早在2008年就開始了微服務方面的實際嘗試，雖然可能在當時，其團隊并未真正意識到自己開發的其實是下一代微服務架構。

文摘1：Dubbo阿裡内部的演進曆史：

Dubbo 項目誕生于 2008 年，起初隻在一個阿裡内部的系統使用；2011 年，阿裡 B2B 決定将整個項目開源 ，僅用了一年時間就收獲了來自不同行業的大批使用者；2014 年，由于内部團隊調整，Dubbo 暫停更新；2017 年 9 月，Dubbo 3 重新開機開源，在 2019 年 5 月由 Apache 孵化畢業，成為第二個由阿裡巴巴捐獻至 Apache 畢業的項目。

在海外，雖然RPC架構類元件塵出不窮，但是真正将服務治理納入一體，而且幾乎成為事實标準的，當屬 Spring Cloud（https://spring.io/projects/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 容器（阿裡巴巴微服務技術實踐_QCon_朱勇_InfoQ精選文章 ）這項技術。這個不起眼的技術，其實起了一個至關重要的作用：服務治理功能和業務功能在代碼上徹底解耦，治理功能的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在百度的實踐與思考 - DockOne.io無标題文檔一文中有詳細闡述。

圖例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 （https://istio.io/v1.12/blog/2021/proxyless-grpc/）. 原文本意是基于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同時使用的類增強沖突問題及分析-雲社群-華為雲 。這裡就摘出要文章核心摘要：

文摘2："記一次多個JavaAgent同時使用的類增強沖突問題及分析" 文中對避免Javaagent沖突的建議。

嚴格遵守位元組碼增強的使用要求和限制。

無論是Byte Buddy、Javassist還是ASM，底層實作都離不開JDK1.5之後引入的Instrumentation接口。既然官方接口的設計理念是reTransformClasses()增強類時不能新增、删除或者重命名字段和方法，不能更改方法的簽名，也不能更改類的繼承關系，那作為JavaAgent的架構開發者，應該不要做出超越上述限制的設計，否則極易導緻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。

點選下方，第一時間了解華為雲新鮮技術~

華為雲部落格_大資料部落格_AI部落格_雲計算部落格_開發者中心-華為雲