在传统的微服务架构中，我们将服务调用中的角色分为四个部分：服务提供者、服务消费者、注册中心和监控。随着分布式服务架构的不断演进，出现了许多复杂的稳定性和可用性问题，单一的监控已经不能满足架构的演进。在现代微服务架构中，我们需要一些手段来“管理”复杂的微服务架构。微服务治理是通过全链路灰度化、线上线下无损、流量控制降级、异常流量调度、数据库治理等技术手段，减少甚至避免大型应用发布和管理过程中遇到的稳定性问题，对微服务领域的各个组件进行管理。服务提供者、消费者、注册中心和服务治理构成了现代微服务架构中的重要环节。
在企业内部，往往存在不同语言、不同通信协议的微服务。这种异构架构会导致业务开发者和架构师在管理微服务的过程中，无法统一管理和控制所有的服务，而这种异构会导致更多的痛点：
行业内对服务治理的能力和边界没有清晰的认识，各企业定义的服务治理理念不一致，导致理解和沟通成本高。
开源的微服务框架很多，服务治理的标准化协议很少。比如Spring Cloud中定义的微服务接口和Dubbo中定义的接口无法互通，Dubbo和Istio管理的微服务无法统一管理。开发者无法用统一的方式管理和控制不同框架和语言的服务。
缺乏真正面向业务并能减轻认知负担的抽象和标准。开发者真正想要的可能很简单，指定服务之间的调用关系和配置规则。然而现在对于业务开发者来说，不仅要了解不同微服务框架的部署架构，还要了解不同服务治理方式的概念和能力的差异，认知成本非常高。
基于以上痛点，阿里巴巴于2022年1月开始与哔哩哔哩、字节跳动等厂商探讨如何规范和普及服务治理，从而共同启动了OpenSergo项目。OpenSergo是一个开放的、通用的服务治理标准，面向分布式服务架构，覆盖全链路异构生态。基于行业中的服务治理场景和实践，形成了通用的服务治理标准。OpenSergo最大的特点是以统一的一套配置/DSL/协议定义服务治理规则，面向多语言异构化架构，做到全链路生态覆盖.无论微服务的语言是Java、go、Node.js还是其他语言，无论是标准微服务还是Mesh访问，从网关到微服务，从数据库到缓存，从服务注册发现到配置，开发者都可以通过同一套OpenSergo CRD标准配置统一管理和控制每一层，无需关注各种框架和语言的差异，从而降低异构和全链路服务管理和控制的复杂性。
OpenSergo标准基于微服务治理相关领域的实践和场景抽象，涵盖服务元信息、流量治理、服务容错、数据库/缓存治理、服务注册发现、配置治理等十几个关键领域。并覆盖微服务的完整生命周期(从开发到测试，到发布，再到运行)。无论我们是想为Spring Cloud Dubbo服务链路配置流量灰色隔离，还是想为一个Go gRPC服务控制流量，或者是想自动融合服务访问数据库的缓慢SQL调用，我们都可以使用OpenSergo规范中定义的CRD标准进行统一配置，而不必关注每个框架不同的声明式API和不兼容的配置格式。
OpenSergo生态由以下部分组成：
OpenSergo规范：统一服务协议和CRD标准定义
OpenSergo多语言SDK:为每个框架组件提供统一的标准CRD对接模块，以对接OpenSergo规范。
OpenSergo数据平面：即与OpenSergo spec接口的框架组件，可由OpenSergo标准统一管理。
OpenSergo控制平面：提供一个统一的控制台来查询ser
我们希望与各个社区合作，将更多的框架和组件连接到OpenSergo生态系统中。每个框架都是OpenSergo的数据平面，可以通过OpenSergo CRD对其进行管理和控制。
那么OpenSergo标准到底是什么样子的呢？我们能用OpenSergo标准做什么？下面用几个例子来介绍一下。
OpenSergo
g>标准介绍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 进行打标。示例：
给流量打标：
假设现在需要将内部测试用户灰度到新版主页，测试用户uid=12345，UID位于 X-User-Idheader 中，那么只需要配置如下CRD 即可：
通过上述配置，我们可以将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。
在中间件开发者峰会中，我们宣布了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、邮件列表、社区双周会等机制，确保通过社区协作的方式来共建标准与实现。欢迎大家通过这些形式一起来讨论、共建。
活动预告
<
