OpenSergo 是什麼

在傳統微服務架構中，我們將服務調用中各角色分爲四大塊：服務提供者、服務消費者、註冊中心、監控。隨着分佈式服務架構的不斷演進帶來諸多複雜的穩定性與易用性問題，單一的監控已無法滿足架構的演進。在現代微服務架構中，我們需要一些手段來對複雜的微服務架構進行 “治理”。微服務治理就是通過全鏈路灰度、無損上下線、流控降級、異常流量調度、數據庫治理等技術手段來減少甚至避免發佈和管理大規模應用過程中遇到的穩定性問題，對微服務領域中的各個組件進行治理。服務提供者、消費者、註冊中心、服務治理，構成現代微服務架構中重要的幾環。

在企業內部，往往存在着不同語言、不同通信協議的微服務，這種異構化的架構會導致治理微服務的過程中，業務開發者、架構師無法用統一的方式來對所有服務進行治理管控，並且這類異構會衍生出更多的痛點：

基於上面這些痛點，阿里巴巴在 2022 年 1 月開始和 bilibili、字節等廠商討論服務治理如何規範化和更加普及，從而共同發起了 OpenSergo 項目。OpenSergo 是一套開放、通用的、面向分佈式服務架構、覆蓋全鏈路異構化生態的服務治理標準，基於業界服務治理場景與實踐形成服務治理通用標準。OpenSergo 的最大特點就是以統一的一套配置 /DSL/ 協議定義服務治理規則，面向多語言異構化架構，做到全鏈路生態覆蓋。無論微服務的語言是 Java, Go, Node.js 還是其它語言，無論是標準微服務還是 Mesh 接入，從網關到微服務，從數據庫到緩存，從服務註冊發現到配置，開發者都可以通過同一套 OpenSergo CRD 標準配置針對每一層進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路服務治理管控的複雜度。

OpenSergo 標準基於微服務治理中相關領域的實踐與場景抽象，覆蓋了服務元信息、流量治理、服務容錯、數據庫 / 緩存治理、服務註冊發現、配置治理等十幾個關鍵領域，覆蓋了完整的微服務生命週期（從開發態到測試態，到發佈態，再到運行態）。無論我們是希望針對 Spring Cloud + Dubbo 服務鏈路配置流量灰度隔離，還是希望針對一個 Go gRPC 服務進行流量控制，還是希望針對服務訪問數據庫的慢 SQL 調用進行自動熔斷，我們都可以利用 OpenSergo spec 中定義的 CRD 標準來進行統一配置，而無需關注各框架不同的聲明式 API 及互不兼容的配置格式。

OpenSergo 生態由以下幾部分組成：

我們期望與各個社區進行合作共建，將更多的框架與組件對接到 OpenSergo 生態中，每個框架都是 OpenSergo 的數據面，可以通過 OpenSergo CRD 進行統一治理管控。

那麼 OpenSergo 標準到底是什麼樣子的呢？我們可以利用 OpenSergo 標準來做哪些事情呢？下面我們來結合幾個例子來進行介紹。

OpenSergo 標準介紹

OpenSergo 項目涵蓋服務元信息、服務註冊發現、流量治理、服務容錯、數據庫治理、緩存治理等領域。在我們的首個版本 v1alpha1 版本中，我們提供了 服務契約（元數據）、流量路由、流控降級 這幾個領域的 CRD 標準。下面我們來介紹一下流量路由與流控降級這兩個領域的示例。

流量路由

流量路由，顧名思義就是將具有某些屬性特徵的流量，路由到指定的目標。流量路由是流量治理中重要的一環，我們可以基於流量路由標準來實現各種場景，如全鏈路灰度、金絲雀發佈、容災路由等。

流量路由規則 (v1alpha1) 主要分爲三部分：

我們以廣泛使用的全鏈路灰度場景爲例。全鏈路灰度通過一系列的流量路由規則，將鏈路上的多個服務的相同版本劃分到同一個泳道中，從而約束流量只在指定泳道中流轉，實現全鏈路的流量隔離的目的。

整個流程可以用下圖概括，我們通過通用的 Workload 標籤規則與流量標籤規則，來以統一的標準方式對完整的服務鏈路實現灰度的能力。

給 Workload 打標籤：

我們對新版本進行灰度時，通常會有單獨的環境，單獨的部署集。我們將單獨的部署集打上 gray 標籤（標籤值可自定義），標籤會參與到具體的流量路由中。

我們可以通過直接在 Kubernetes workload 上打 label 的方式進行標籤綁定，如在 Deployment 上打上 traffic.opensergo.io/label: gray 標籤代表灰度。對於一些複雜的 workload 打標場景（如數據庫實例、緩存實例標籤），我們可以利用 WorkloadLabelRule CRD 進行打標。示例：

apiVersion: traffic.opensergo.io/v1alpha1
kind: WorkloadLabelRule
metadata:
 name: gray-sts-label-rule
spec:
 workloadLabels: ['gray']
 selector:
 app: my-app-gray
 database: 'foo_db'

給流量打標：

假設現在需要將內部測試用戶灰度到新版主頁，測試用戶 uid=12345，UID 位於 X-User-Idheader 中，那麼只需要配置如下 CRD 即可：

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficLabelRule
metadata:
 name: my-traffic-label-rule
 labels:
 app: my-app
spec:
 selector:
 app: my-app
 trafficLabel: gray
 match:
 - condition: "=="    # 匹配表達式
 type: header       # 匹配屬性類型
 key: 'X-User-Id'   # 參數名
 value: 12345       # 參數值
 - condition: "=="
 value: "/index"
 type: path

通過上述配置，我們可以將 path 爲 /index，且 uid header 爲 12345 的 HTTP 流量，打上 gray 標，代表這個流量爲灰度流量。

按照標籤來路由：

在具體的路由過程中，接入了 OpenSergo 的微服務框架、Service Mesh 的 proxy 中，只要實現了 OpenSergo 標準並進行上述規則配置，那麼就能識別流量的標籤和 workload 的標籤。帶 gray 標籤的流量就會流轉到 gray 標籤的實例分組中；如果集羣中沒有 gray 實例分組（即沒有 workload 帶有這個標籤），則默認 fallback 到沒有標籤的實例上。後續版本標準將提供未匹配流量的兜底配置方式。

社區還在不斷完善流量路由相關的標準，並與各個社區合作共建，讓更多的框架組件支持 OpenSergo 標準，從而支持統一的流量路由管控。

流控降級與容錯

流控降級與容錯同樣是服務流量治理中關鍵的一環，以流量爲切入點，通過流控、熔斷降級、流量平滑、自適應過載保護等手段來保障服務的穩定性。在 OpenSergo 中，我們結合 Sentinel 等框架的場景實踐對流控降級與容錯抽出標準 CRD。一個容錯治理規則 (FaultToleranceRule) 由以下三部分組成：

無論是 Java 還是 Go 還是 Mesh 服務，無論是 HTTP 請求還是 RPC 調用，還是數據庫 SQL 訪問，我們都可以用這統一的容錯治理規則 CRD 來給微服務架構中的每一環配置容錯治理，來保障我們服務鏈路的穩定性。只要微服務框架適配了 OpenSergo，即可通過統一 CRD 的方式來進行流控降級等治理。

以下 YAML CR 示例定義的規則針對 path 爲 /foo 的 HTTP 請求（用資源名標識）配置了一條流控策略，全局不超過 10 QPS。當策略觸發時，被拒絕的請求將根據配置的 fallback 返回 429 狀態碼，返回信息爲 Blocked by Sentinel，同時返回 header 中增加一個 header，key 爲 X-Sentinel-Limit, value 爲 foo。

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: RateLimitStrategy
metadata:
 name: rate-limit-foo
spec:
 metricType: RequestAmount
 limitMode: Global
 threshold: 10
 statDuration: "1s"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: HttpRequestFallbackAction
metadata:
 name: fallback-foo
spec:
 behavior: ReturnProvidedResponse
 behaviorDesc:
 # 觸發策略控制後，HTTP 請求返回429 狀態碼，同時攜帶指定的內容和header.
 responseStatusCode: 429
 responseContentBody: "Blocked by Sentinel"
 responseAdditionalHeaders:
 - key: X-Sentinel-Limit
 value: "foo"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
 name: my-rule
 namespace: prod
 labels:
 app: my-app # 規則配置生效的應用名
spec:
 targets:
 - targetResourceName: '/foo'
 strategies: 
 - name: rate-limit-foo
 fallbackAction: fallback-foo

在中間件開發者峯會中，我們宣佈了 Sentinel 2.0 流量治理的全面升級。Sentinel 2.0 將原生支持流量治理相關 CRD 配置，結合 Sentinel 提供的各框架的適配模塊，讓 Dubbo, Spring Cloud Alibaba, gRPC 等 20+ 框架能夠無縫接入到 OpenSergo 生態中，用統一的 CRD 來配置流量路由、流控降級、服務容錯等治理規則。

社區規劃

讓異構微服務能夠用統一的服務協議與配置方式進行治理、讓更多微服務能夠互聯互通，塑造更加雲原生的微服務，是 OpenSergo 建立之初就樹立的長期發展目標。

在標準化建設上，OpenSergo 社區會聯合更多開源社區與企業，在數據庫治理、緩存治理、服務註冊發現、配置治理等更多領域層面上標準化微服務治理能力，讓企業能夠用一套通用語言來描述和治理自己的微服務架構，讓開發者專注於業務核心價值，讓微服務框架也能夠被客戶輕鬆採用。

在社區生態建設上，OpenSergo 社區將逐漸覆蓋從網關、RPC、數據庫、緩存到服務發現、服務配置等分佈式服務鏈路中的每一環生態，通過與各社區合作，讓各主流框架均可以藉助統一的 OpenSergo spec 來定義與實現服務治理的能力，開發者無需關注各框架、協議的概念與實現差異，降低開發者跨語言、跨框架、跨協議層面服務治理的管控成本。OpenSergo 社區將持續與 Kratos、CloudWeGo Kitex、Spring Cloud Alibaba、Dubbo 等社區進行合作，同時也會推進與 Apache APISIX、Envoy/Istio、gRPC、Druid、ShardingSphere 等更多社區的合作，將標準落地到各個框架中。我們也非常歡迎更多開源社區與企業一起加入 OpenSergo 的標準與生態共建。

在控制面建設上，OpenSergo 目前正在聯合社區打造 OpenSergo Dashboard 作爲統一的服務治理控制面，通過中立、通用的 OpenSergo 標準協議，讓所有的微服務框架、所有的通信協議都可以被同一套微服務門戶來治理。

歡迎加入

OpenSergo 自創立就是社區項目，通過 Apache License 2.0 協議開源。OpenSergo 正在與 Apache Dubbo, CloudWeGo Kitex (字節), Kratos (bilibili), Spring Cloud Alibaba, Apache APISIX 等社區進行合作，共同完善服務治理標準設計與實現，一起將 OpenSergo spec 推進和落地到更多微服務生態中。後續在 OpenSergo 服務治理標準的制定、發展上，也會通過公開、透明、民主的方式來制定標準、推動實施。社區也通過 GitHub issue、Gitter、郵件列表、社區雙週會等機制，確保通過社區協作的方式來共建標準與實現。歡迎大家通過這些形式一起來討論、共建。

參考閱讀：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/aBfEKuLFECNKunrwxAqB-w

猜你喜歡