OpenSergo 是什么

在传统微服务架构中，我们将服务调用中各角色分为四大块：服务提供者、服务消费者、注册中心、监控。随着分布式服务架构的不断演进带来诸多复杂的稳定性与易用性问题，单一的监控已无法满足架构的演进。在现代微服务架构中，我们需要一些手段来对复杂的微服务架构进行“治理”。微服务治理就是通过全链路灰度、无损上下线、流控降级、异常流量调度、数据库治理等技术手段来减少甚至避免发布和管理大规模应用过程中遇到的稳定性问题，对微服务领域中的各个组件进行治理。服务提供者、消费者、注册中心、服务治理，构成现代微服务架构中重要的几环。

在企业内部，往往存在着不同语言、不同通信协议的微服务，这种异构化的架构会导致治理微服务的过程中，业务开发者、架构师无法用统一的方式来对所有服务进行治理管控，并且这类异构会衍生出更多的痛点：

• 业内对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念不一致，造成很高的理解和沟通成本。

• 开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，Spring Cloud中定义的微服务接口和Dubbo 中定义的接口就没有办法互通，通过Dubbo 和Istio管理的微服务也没有办法进行统一治理。开发者无法通过统一的配置方式来对不同框架、不同语言的服务进行统一治理管控。

• 缺少真正面向业务、能够减轻认知负担的抽象和标准。开发者真正想要的可能是简单的、指定服务间的调用关系和配置规则。但现在对于业务开发者来说，不仅需要了解不同微服务框架的部署架构，也要了解不同服务治理方式的概念和能力区别，认知成本很大。

基于上面这些痛点，阿里巴巴在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 spec：统一的服务协议与CRD 标准定义

• OpenSergo 多语言SDK：提供统一的标准CRD 对接模块，供各个框架组件对接OpenSergo spec

• OpenSergo 数据面：即对接OpenSergo spec 的框架组件，均可通过OpenSergo 标准方式进行统一治理

• OpenSergo 控制面：提供统一的控制台来进行服务元信息查询以及流量路由、流量控制等治理规则配置。

我们期望与各个社区进行合作共建，将更多的框架与组件对接到OpenSergo生态中，每个框架都是OpenSergo 的数据面，可以通过OpenSergo CRD 进行统一治理管控。

那么OpenSergo标准到底是什么样子的呢？我们可以利用OpenSergo 标准来做哪些事情呢？下面我们来结合几个例子来进行介绍。

OpenSergo标准介绍

OpenSergo项目涵盖服务元信息、服务注册发现、流量治理、服务容错、数据库治理、缓存治理等领域。在我们的首个版本v1alpha1 版本中，我们提供了 服务契约（元数据）、流量路由、流控降级 这几个领域的CRD 标准。下面我们来介绍一下流量路由与流控降级这两个领域的示例。

流量路由

流量路由，顾名思义就是将具有某些属性特征的流量，路由到指定的目标。流量路由是流量治理中重要的一环，我们可以基于流量路由标准来实现各种场景，如全链路灰度、金丝雀发布、容灾路由等。

流量路由规则(v1alpha1)主要分为三部分：

• Workload 标签规则(WorkloadLabelRule)：将某一组workload（如Kubernetes Deployment, Statefulset 或者一组pod，或某个JVM 进程，甚至是一组DB 实例）打上对应的标签

• 流量标签规则(TrafficLabelRule)：将具有某些属性特征的流量，打上对应的标签
  

• 按照Workload 标签和流量标签来做匹配路由，将带有指定标签的流量路由到匹配的workload 中

我们以广泛使用的全链路灰度场景为例。全链路灰度通过一系列的流量路由规则，将链路上的多个服务的相同版本划分到同一个泳道中，从而约束流量只在指定泳道中流转，实现全链路的流量隔离的目的。

整个流程可以用下图概括，我们通过通用的Workload标签规则与流量标签规则，来以统一的标准方式对完整的服务链路实现灰度的能力。

给Workload打标签：

我们对新版本进行灰度时，通常会有单独的环境，单独的部署集。我们将单独的部署集打上gray标签（标签值可自定义），标签会参与到具体的流量路由中。

我们可以通过直接在Kubernetes workload上打label 的方式进行标签绑定，如在Deployment 上打上 traffic.opensergo.io/label: gray标签代表灰度。对于一些复杂的workload 打标场景（如数据库实例、缓存实例标签），我们可以利用WorkloadLabelRule CRD 进行打标。示例：

apiVersion: traffic.opensergo.io/v1alpha1kind: WorkloadLabelRulemetadata: name: gray-sts-label-rulespec: workloadLabels: ['gray'] selector: app: my-app-gray database: 'foo_db'

给流量打标：

假设现在需要将内部测试用户灰度到新版主页，测试用户uid=12345，UID位于 X-User-Idheader 中，那么只需要配置如下CRD 即可：

apiVersion: traffic.opensergo.io/v1alpha1kind: TrafficLabelRulemetadata: name: my-traffic-label-rule labels: app: my-appspec: 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) 由以下三部分组成：

• Target: 针对什么样的请求

• Strategy: 容错或控制策略，如流控、熔断、并发控制、自适应过载保护、离群实例摘除等

• FallbackAction: 触发后的fallback 行为，如返回某个错误或状态码

  
  

无论是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/v1alpha1kind: RateLimitStrategymetadata: name: rate-limit-foospec: metricType: RequestAmount limitMode: Global threshold: 10 statDuration: "1s"---apiVersion: fault-tolerance.opensergo.io/v1alpha1kind: HttpRequestFallbackActionmetadata: name: fallback-foospec: behavior: ReturnProvidedResponse behaviorDesc: # 触发策略控制后，HTTP 请求返回429 状态码，同时携带指定的内容和header. responseStatusCode: 429 responseContentBody: "Blocked by Sentinel" responseAdditionalHeaders: - key: X-Sentinel-Limit value: "foo"---apiVersion: fault-tolerance.opensergo.io/v1alpha1kind: FaultToleranceRulemetadata: 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、邮件列表、社区双周会等机制，确保通过社区协作的方式来共建标准与实现。欢迎大家通过这些形式一起来讨论、共建。

活动预告

↓↓↓

GIAC 全球互联网架构大会 2022 将于 7 月 22 - 23 日在深圳举行，本届 GIAC 议题共设置有 24 个专题，覆盖各类架构热点领域，每个主题由业内知名架构师、技术负责人等专家担任出品人，负责议题选取和质量把控。本次大会包括数据智能平台演进（由白海科技创始人兼CEO卢亿雷担任出品人）和湖仓一体（由Shopee Data Infra Team罗李担任出品人）等专题，将有更多本文相关内容演讲，点击阅读原文查看 GIAC 详细日程。

点击【阅读原文】，了解更多活动信息。