作者：Jiahuan He，阿里雲MSE研發工程師。
在現代微服務架構中，我們將系統分解為一系列服務，並通過遠端過程呼叫將它們連線在一起，從而帶來了一些優勢和挑戰。
如上圖所示，詞云展示了當前微服務架構在生產中遇到的挑戰。 例如，在流量激增最常見的場景中，AIGC在過去一年中突然爆發，相關服務因流量激增而無法使用，這可能會導致我們錯過最佳增長視窗。
再比如缺乏容錯機制，某***的某項服務異常會隨著呼叫鏈的傳播而蔓延，導致全站入口不可用，影響數千萬使用者，產生重大經濟損失。 這些生產故障的頻繁發生，也提醒著我們穩定性是善用微服務的主要挑戰之一。
為了保證微服務的穩定性，我們需要做一些架構演進。
我們來看一下左邊的3大微服務，我們已經很熟悉了，通過這三者的配合，我們的應用可以正常使用，但是在生產可用之前還有很長的路要走，各個企業和社群為了消除距離，有一些探索和實踐， 比如 Dubbo 社群在 Dubbo3 中引入了流量管理和高可用等一系列能力來保證微服務的穩定性，這些措施可以統稱為微服務治理。
所以其實大家都已經意識到，微服務治理是從微服務執行到實際生產微服務不可或缺的一環。 然而，微服務治理應該做什麼以及如何去做，還比較模糊。
從軟體生命週期的角度來看，我們可以將微服務治理分為三個領域開發狀態、測試狀態、更改狀態和操作狀態。
例如，我們可以通過上線和下線來解決有損釋放問題，通過灰度控制變化的影響面，對不確定的流量使用流量控制和熱點保護，對不穩定的呼叫使用熔斷和隔離。
您可以看到，有一些成熟的方案和實踐在每個領域都執行良好。 但是，無論是阿里巴巴還是其他公司，在系統地實施微服務治理時，都會存在很多問題。
首先，我們涉及到的元件很多，在微服務架構中，我們需要有像 Dubbo 這樣的呼叫框架，像 Nacos 這樣的註冊中心，像 Sentinel、Hystrix 這樣的穩定性中介軟體，這些元件無法統一治理，控制成本會變得非常高。
二是概念不統一，比如 Envoy 中的隔離和 Sentinel 中的隔離不一樣，Envoy 的隔離是為了去除不健康的例項，而 Sentinel 的隔離是併發控制，這會讓開發者理解起來非常昂貴。
同時，每個商業社群都有自己的最佳實踐，這導致了能力的錯位和沒有統一的標準。
例如，Sentinel、Hystrix、Istio 都有融合的能力，但配置不同，開發者需要單獨學習習，也要注意不要混淆，不利於理解和統一把控。
可以發現，由於這些問題，我們在實現系統化的微服務治理時會遇到很大的阻力我們需要的是乙個統一的治理介面，以便我們更好地管理微服務，因此我們提出了 opensergo 專案。
OpenSergo 期望提出一套開放通用的、面向雲原生架構的微服務治理解決方案和標準，以幫助保障微服務的高可用性，上圖的四個部分是 OpenSergo 社群的願景。
OpenSergo 社群會基於業界的微服務治理場景和實踐，抽象成規範，以解決上述概念、配置、能力不一致的問題，並使用統一的控制面進行承載，降低使用和維護成本。
同時，縱向上，我們抽象出鏈路上的每乙個環節，覆蓋整個場景，橫向上，無論是J**a生態、GO生態還是其他語言，無論是傳統的微服務還是網格架構，都會被納入到這個統一的體系中。
但是，作為乙個開放標準，OpenSergo還不足以單靠阿里，所以我們聯合嗶哩嗶哩、中國移動等多家公司和社群，共同構建了這套開放標準，希望能真正解決微服務穩定性的風險。
接下來，我們簡單介紹一下 OpenSergo 的架構如前所述，OpenSergo 社群會基於場景對 OpenSergo 規範進行抽象，但這只是第一步，為了承載這些標準規範，我們需要乙個控制平面，社群選擇從 0 開始開發乙個控制平面來做初始演進中治理規則的控制、監控和交付。
但是，隨著社群的演進，我們發現基於 Istio 的擴容成本更低，可以復用更多的能力，因此在後續的演進中，我們會選擇將 Istio 擴充套件控制面和決策中心相結合，實現對治理規則的統一控制和治理策略的預計算。
有了控制面之後，我們還需要資料面來實現特定的治理能力，可以是 Sentinel 等中介軟體，也可以是框架本身。 在最初的架構中，控制面和資料面之間的通訊是基於 grpc 構建的鏈結，但在確定未來的演進方向將基於 Istio 擴充套件後，社群選擇擁抱 XDS 並盡可能地為其鏈結提供服務，然後使用我們自己的 grpc 鏈結來承載一些無法承載的鏈結。
如前所述，社群控制面的後續演進是基於 Istio 的擴充套件，Istio 本身也具備一定的流量治理能力，具有一定的普及度。 但是，Istio 主要關注的是流量管理，將流量獲取到需要去的地方，而不是微服務治理，因此在微服務穩定性的場景下，Istio 提供的這些能力並不足以滿足我們的需求。
因此，在 Istio 的基礎上，基於微服務穩定性的一些場景，比如上面提到的變更狀態穩定性和執行時穩定性，我們制定了滿足要求的規範和標準，希望更適合微服務場景。 因此，作為乙個整體，我們將在微服務治理領域成為 Istio 的超集，而不是互斥鎖。
讓我們看一下 OpenSergo 標準規範如何解決上述場景。
首先，我們來談談流量路由，它的主要作用是將滿足某些特徵的流量路由到指定的工作負載，一般大家都會利用這種能力來實現灰度、同區路由等方案。
基於 Istio VirtualService DestinationRule 的格式社群定義了流量路由規範，但在研究和實踐的過程中，我們發現它並不能很好地滿足微服務場景的需求。 因此，為了更貼近微服務場景，我們做了擴充套件。 例如，我們新增了處理路由失敗的邏輯，這是微服務架構中的常見要求。
由於 Istio 的主要關注點是 HTTP 請求，因此它的 CRD 不能像 Dubbo 那樣很好地處理 RPC 呼叫，因此我們為此新增了更多的 RPC 模型支援。 未來，我們還將探索與社群標準整合的解決方案，使我們的規範更加通用和標準。
在阿里巴巴集團內部多年的安全生產實踐中，灰度被定義為安全變革的三板軸，與監控和回滾並列，其中灰度是控制變革影響、保證變革穩定性不可或缺的能力。
為了實現灰度，我們通常有幾種解決方案，第一種是物理隔離，我們部署兩套相同的環境來實現灰度，但是這種解決方案的部署和維護成本很高。
為了提高資源利用率，應運而生第二種解決方案是流量灰度。 我們沒有單獨部署環境，而是在每一跳流量時匹配流量特徵，並決定是去灰度例項還是基礎例項，這比前者更靈活、更高效，可以通過上面提到的流量路由能力來實現。 但是，我們需要在每跳配置路由規則，比較繁瑣。
而且由於後續環節中無法獲取到某些資訊，比如uid，所以這個方案的實現有一定的難度。 事情就是這樣第三種方案是全鏈路灰度通過在流量入口處匹配流量並標記標籤，標籤將沿著呼叫鏈路自動透明傳輸，後續鏈路將根據標籤進行路由。 通過這種方式，我們能夠更簡潔地定義灰度。 OpenSergo 為此場景抽象了相應的 CRD。
我們把這個叫做crd車道，也就是泳道，我覺得比較生動，你看上面的**，橙色是正常的交通方向，灰色是灰色的交通方向，就像把乙個游泳池分成多個泳道一樣。
泳道的CRD由三部分組成，也很容易理解，首先我們需要匹配灰度流量，所以我們需要定義匹配條件，然後定義這些流量用什麼標籤來標記，最後定義這個標籤是如何透明傳輸的。
有了這個 crd，我們定義了乙個灰度泳道。 但是，如果單靠清晰度還不足以實現全通道灰度，我們還需要利用OpenSergo系統的全鏈路全方位框架的支援，使標籤在這些框架中自動透明傳輸，這些框架也可以通過標籤進行路由。 其中，流量染色和標籤透傳將借助OpenTelemetry等標準TRCAE系統實現。
上圖右側是 CRD 的示例，您可以簡要了解一下。
接下來，我們來看一下執行時穩定性的場景。
我們主要提到兩種情況第一種是流量激增的場景例如，在雙11限時搶購活動中，系統在開始時流量穩定時也處於穩定狀態。 但是，當流量激增時，系統會開始向不穩定的方向發展，異常呼叫也會激增，最終變得不可用。 對於此類場景，我們可以利用流量控制能力拒絕超出容量的請求，或者利用流量平滑能力來剔除波峰波谷，使流量保持在相對穩定的狀態，避免業務不可用。
第二種情況是不穩定的呼叫導致服務不可用例如，我們在呼叫一些第三方服務時，經常會出現不穩定的情況，這裡的不穩定主要是指異常或呼叫緩慢。 以 dubbo 為例，當服務提供者進行慢速呼叫時，會導致執行緒在服務消費者身上堆積，從而影響其他正常呼叫乃至整個服務的穩定性，而這種風險會沿著呼叫鏈傳遞和擴散，最終影響整個系統的穩定性。 在這種情況下，我們可以使用併發控制或熔斷保護來限制慢呼叫對資源的占用，保證系統的整體穩定性。
針對前面提到的這些場景，OpenSergo 也制定了相關的 CRD。 在行業實踐中，聖天諾是乙個成熟的流量防護解決方案，在阿里巴巴內部積累了大量與流量防護相關的場景和實踐，並在2024年開源後進一步豐富了這些行業積累，我們從這些積累中抽象出一套流量防護規範和標準。
因此，您可以簡要考慮一量保護規則應包含哪些內容。
我們首先需要確定的是要定位什麼樣的流量，我們可以按介面劃分，也可以根據請求中的特徵進行劃分。 一旦我們制定了目標，我們就需要定義我們想要採用什麼樣的治理策略。 這裡的策略包括上面提到的策略，以及高階策略，如自過載保護。
最後，因為限速本身是有損的，但是我們不希望這種有損的傳遞給使用者端，我們需要針對不同的規則配置不同的行為，這樣對使用者端的效能更加友好，比如最基本的限速對於搶購場景，我們可以返回乙個佇列， 請稍後提示。
上圖右側是 CRD 示例，其中流量目標為介面名稱為 foo 的請求，策略為閾值為 10 的全域性限制，回退為特定的返回正文。
通過這個 CRD 配置，無論是 Dubbo 框架還是其他框架，我們都可以輕鬆使用流量保護能力。
對於框架開發者來說，其實有兩種方法可以整合到 OpenSergo 系統中：
一種是通過對接OpenSergo系統的資料面進行接入，框架開發者只需要實現對接模組與Sentinel對接即可完成對接工作。 對於有特殊要求或更接近特定場景的框架，也可以對接 OpenSergo 標準接入 OpenSergo 系統。
對於使用者來說，不管是哪種方式，只需要簡單地引入一些依賴，就可以在不知不覺中獲取OpenSergo定義的微服務治理能力，就可以在統一的控制面上控制這些框架的微服務治理能力，大大提公升了使用微服務治理的體驗和效率。 說完訪問方法，我們再來看看實現的效果。
第一種做法是全鏈路灰度控制，以消除狀態穩定性變化的風險。 這是乙個簡單的 demo，我們只需要部署這樣乙個 crd，定義乙個 dubbo 請求，當它的引數出現 name=xiaoming 時，我們會將其定向到灰度環境，對於不符合要求的流量，我們還是會去基線環境，我們可以看到當前的請求方向符合我們的預期。
但是，我們的生產環境將比演示複雜得多，並且會涉及各種框架，例如 Rokcetmq 和 Spring Cloud Alibabab。 但是，只要這些框架連線到OpenSergo系統，就可以利用這個CRD來實現全鏈路和全框架灰度。
第二種做法是流量保護和容錯，保證執行時的穩定性——不穩定的呼叫場景。 這裡使用乙個簡單的 demo，其中應用程式 A 通過 dubbo 呼叫應用程式 B。 右側是正常和慢速呼叫介面的流量圖，紫色流量為總流量，黃色為拒絕流量，橙色為異常流量。 剛開始時，沒有發生慢呼叫，系統處於穩定狀態，沒有出現異常流量。
在第乙個時間點，我手動調整了慢呼叫介面的 RT，出現慢呼叫，出現了異常流量，同時，由於慢呼叫占用了 dubbo 的大量執行緒資源，正常呼叫的資源被擠占，也出現了大量的異常流量， 並且 Dubbo 端的執行緒池已經耗盡。
你可以想一想，在這個場景下我們應該配置什麼規則來解決這個問題，其實這個時候，很多人都會想做流量控制來限制流量，希望能解決這個問題，我們來看看它的其中乙個效果。
第二次配置了限速規則，可以看到雖然情況有所緩解，但還是有大量的錯誤，因為在慢呼叫場景下，請求已經堆積起來了，只有通過QPS限流還是會造成請求的進一步積累。
所以我們真正需要的是併發控制，在第三個時間點我配置併發控制規則來限制慢呼叫介面的併發數，也就是正在處理的請求數。 可以看出，通過這個限制，即使慢呼叫仍然存在，但其能占用的執行緒資源是有限的，正常介面可以正常呼叫，從而避免了穩定性風險的擴大，保證了應用的穩定性。
第三種做法是流量保護和容錯，以保證執行的穩定性——自適應過載保護。 可以看出，在我們 Demo 的持續高負載下，異常流量開始逐漸上公升，系統的穩態被破壞，因此我們可以通過配置自適應過載保護規則來調整限流行為，以排除異常請求，幫助系統恢復到穩態。
我們已經在開源中支援 BBR，並在內部實踐中使用 PID。 這裡我就不贅述這些策略了，但如果你有興趣，可以到我們的開源社群參與討論。
從這三個例子可以看出，Dubbo 通過與 Sentinel 對接 OpenSergo 系統後，具備了 OpenSergo 定義的通用治理能力，可以通過統一的控制面進行控制。
其他框架也是如此，試想一下，如果我們生產中涉及的所有框架都接入了 OpenSergo 系統，那麼我們可以在乙個控制平面上控制所有服務，所有框架的微服務治理能力可以更好的保證系統的穩定性。
這是多語言服務治理生態系統的大圖景。 在生態方面，我們希望 OpenSergo 是乙個全鏈路的多語言異構，我們將主要關注 J**A Go + Gateway + Mesh 生態，並持續覆蓋生態中的更多框架。
在能力上，我們將繼續抽象和實現更通用的微服務治理能力。 這包括流量保護、自我修復、容錯和業務認證。
目前，我們已經與許多社群建立了聯絡與合作，如Dubbo、Shenyu、APISIX、Higress、RocketMQ、Mosn等，其中許多社群已經取得了一些實質性的進展。
讓我們分享一下我們在不久的將來的計畫。
在控制面方面，我們將逐步將 control plane 推向生產，並在明年 3 月發布 GA 版本，讓大家在生產中驗證微服務治理系統。 規格方面，我們將支援微服務安全治理、異常值例項刪除以及與社群標準的持續整合。 治理能力的演變我們將重點介紹哨兵 20 公升級流量治理，向安全適配方向探索。 在社群合作方面，我們將持續推進與社群的交流與合作，推動各微服務治理領域的生態落地，統一控制面，共同構建SPEC。
雖然阿里巴巴在集團和雲上積累了大量的經驗和場景，但穩定性問題複雜，場景多樣，僅靠一方不足以覆蓋所有穩定場景，也不足以成為標準，因此微服務治理技術、生態化、標準化的演進也需要各企業和社群的共同參與。
您可以通過三種方式參與社群活動。
在微服務治理的規範中，每個社群和企業都是各自領域的領跑者，大家可以根據自己的場景和最佳實踐，共同制定和完善標準和規範。 作為乙個控制平面，它實際上處於決策者的位置，在一定程度上具有整個系統的視角，在當前AI技術的熱潮中有著廣闊的前景。 你可以參與到服務治理能力的演進中來，也可以為各個社群和 OpenSergo 系統之間的連線貢獻力量。 最後，我想說的是，微服務治理其實是乙個非常廣闊的平台，通過參與其中，你可以接觸到各個領域的技術和場景，而不是侷限於單一技術點的範圍。 歡迎企業和社群同學加入開源貢獻小組，引領下一代微服務技術體系演進