We're glad to announce that Jiangnan Jia (GitHub ID: @jnan806) has been promoted to OpenSergo committer as a result of his nice contribution for OpenSergo Go SDK, proto management and Sentinel Go OpenSergo data-source.
Summary of the OpenSergo community biweekly meeting (Oct 12nd, 2022)
The Sentinel Go community is making progress on OpenSergo integration (thanks jnan806 and @binbin0325). See https://github.com/alibaba/sentinel-golang/pull/489 for details
GitHub discussions: https://github.com/opensergo/opensergo-specification/discussions/47
Summary of the OpenSergo community biweekly meeting (Sep 28th, 2022)
GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/44
Summary of the OpenSergo community biweekly meeting (Sep 15th, 2022):
GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/41
Summary of the OpenSergo community biweekly meeting (Aug 31st, 2022):
GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/36
Summary of the OpenSergo community biweekly meeting (Aug 17th, 2022):
GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/27
Summary of the OpenSergo community biweekly meeting (Aug 4th, 2022):
GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/21
在传统微服务架构中，我们将服务调用中各角色分为四大块：服务提供者、服务消费者、注册中心、监控。随着分布式服务架构的不断演进带来诸多复杂的稳定性与易用性问题，单一的监控已无法满足架构的演进。在现代微服务架构中，我们需要一些手段来对复杂的微服务架构进行“治理”。微服务治理就是通过全链路灰度、无损上下线、流控降级、异常流量调度、数据库治理等技术手段来减少甚至避免发布和管理大规模应用过程中遇到的稳定性问题，对微服务领域中的各个组件进行治理。服务提供者、消费者、注册中心、服务治理，构成现代微服务架构中重要的“四大件”。
在企业内部，往往存在着不同语言、不同通信协议的微服务，这种异构化的架构会导致治理微服务的过程中，业务开发者、架构师无法用统一的方式来对所有服务进行治理管控，并且这类异构会衍生出更多的痛点：
基于上面这些痛点，阿里巴巴在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 项目涵盖服务元信息、服务注册发现、流量治理、服务容错、数据库治理、缓存治理等领域。在我们的首个版本 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-Id header 中，那么只需要配置如下 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
在近期的 2022 中间件开发者峰会中，我们宣布了 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、邮件列表、社区双周会等机制，确保通过社区协作的方式来共建标准与实现。欢迎大家通过这些形式一起来讨论、共建。
也欢迎大家加入 OpenSergo 社区钉钉群（群号：34826335），一起来定义微服务治理的未来。
同时我们在阿里云也提供 OpenSergo 的企业级产品 MSE，提供服务治理、流控降级、注册配置中心、云原生网关、分布式事务等核心能力，欢迎大家体验。
软件架构的核心挑战是解决业务快速增长带来的系统复杂性问题。系统越复杂，对服务治理诉求越强烈，小的技术问题越可能被放大，从而造成大的线上故障。而微服务治理就是通过无损上线下、全链路灰度、流量防护等技术手段来减少、甚至避免发布和管理大规模应用过程中遇到的稳定性问题。
虽然大家都认为微服务治理很重要，但在落地过程中会遇到各种难题。
例如，在企业内部，往往存在着不同语言、不同通信协议的微服务，这会导致治理微服务的过程中，给业务开发者、架构师平添很多的认知负担，而这类异构会衍生出更多的痛点。
在阿里巴巴内部，服务治理体系从形态上经历了从 SDK 方式、到 Fat-SDK 方式、再到 Java Agent/Sidecar 化的演进历程。具体而言，阿里巴巴从 2008 年就开始了微服务的改造，诞生了服务框架 HSF 及配套的服务治理能力；2012 年，Dubbo 框架开源，提供了非常优秀的服务治理能力，这个阶段的服务治理能力是以 SDK 的方式和服务框架进行一体化演进的；2013 年开始，为了解决 SDK 升级成本高的问题，中间件团队推出轻量级隔离容器 Pandora，将服务治理能力通过 Fat-SDK 的方式从业务中剥离出来，大幅度提升了升级效率。
然而这种方式仍然面临较高的升级成本。为了将服务治理体系和业务彻底解耦，阿里巴巴从 2019 年开始，通过将服务治理能力下沉到 JavaAgent，实现了完全无需对业务做任何改造、就能接入服务治理的能力。后来，我们将这个技术方案进行产品化，通过阿里云微服务引擎 MSE 这款产品服务云上的企业客户。
同一时期，随着业务发展的多样化，多语言构建的业务在集团内部逐渐流行起来，阿里巴巴内部开始探索多语言的治理方案，采用了基于 Istio + Envoy 的 Sidecar 方式为异构语言服务，提供基础的服务治理能力。
在这个过程中我们逐渐发现，异构微服务框架之间有不同的体系和认知，在很多概念上无法完全对齐，用一套标准的服务治理方案治理各种微服务体系变得愈发困难。因此，我们迫切需要一个和语言无关、和技术形态无关，但贴近业务的统一服务治理规范，使得异构微服务体系能够互联互通以及进行统一治理。
总结下来，阿里巴巴内部的服务治理经历了从基础数据面建设、到治理能力探索、再到能力标准化建设三个阶段。
从 2016 年开始，bilibili 进行经历巨石架构到微服务的完整转型，整个过程中，也面临了很多服务治理问题。从单体到微服务整个部署和管理模式开始进行转变，我们为了提高研发效率和稳定性拆分了不同粒度的服务，所以我们于 2017 年开始思考如何管理微服务，从而开始通过容器部署和隔离，在管理方面极大地解决了我们的问题，同时也建设了统一的注册中心和配置中心基础中间件，整个微服务也围绕这两个基础中间件做了很多服务治理相关的。
在早期我们语言还是比较统一的，基本上是以 Go 语言为主，有统一的 Kratos 框架，所以服务治理也是优先选择了 SDK 方式进行管控。随着这几年的业务快速发展，内部出现 Java、C++ 等一些语言，我们尝试了 Service Mesh 通过 Sidecar 方式进行管理，在这个过程中我们逐渐发现，整个维护成本其实是不小的，并且性能损耗在降本增效的这个大环境下也有比较大的挑战。所以，我们也非常期待有一套服务治理标准，可以在 Kratos 框架、Java Agent、Istio 等体系中使用。
展望未来，微服务治理的发展趋势，是让业务迭代更加高效、业务和治理更加透明和解耦：
基于此，阿里巴巴在2022年1月开始和 bilibili、字节等厂商讨论服务治理如何规范化和更加普及，从而共同发起了 OpenSergo 项目。
我们观察到，目前不同框架、不同语言在微服务治理上的概念碎片化、无法互通。所以，OpenSergo 致力于在不同的微服务框架、通信协议之间达成共识，形成服务治理规范。
OpenSergo 主要包含三大部分：
控制面：用户可以通过 CRD 或者 Dashboard 的方式查看、修改服务治理配置，并将这些管控信息下发到数据面。
数据面：JavaAgent、Servcie Mesh、各个接入 OpenSergo 的微服务框架都能够接收到服务治理配置，并应用到当前的业务流量中。各个数据面都能够认可OpenSergo规定的服务治理配置、流量标签等信息，确保降低开发者理解成本。
OpenSergo Spec：Spec 规定了控制面和数据面的通信约定，确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构，让开发者不再需要关注底层差异。
对于控制面，OpenSergo 统一了治理规则，用户不必再绑定到某个开源方案、某个云厂商提供的服务上。不同的数据面、控制面只要对接 OpenSergo 规范，即可无缝对接现有的服务治理体系。
对于数据面，OpenSergo 提供了不同的接入方式：
从阿里巴巴集团内部和阿里云提供的服务治理经验来看，结合各个开源微服务框架、各公司内部的治理经验，从服务治理功能层面来说，目前业界认可的主要分为上图中的开发态、测试态、发布态、高可用、安全态五个部分：
从更大的角度来看，除了微服务框架、Service Mesh、Java Agent 方式的治理之外，服务治理还会关注网关、存储等完整的调用链路；在实现上，也会包括微服务服务发现、配置管理、分布式事务等微服务基础组件的治理和接入。
在图中的子领域中，OpenSergo 会采纳现有的规范、提出落地新的规范，来给业务开发者提供一套标准界面，能够对业务开发者、架构师屏蔽底层差异，让他们专注于核心业务价值，从而真正兑现云原生微服务的价值。
OpenSergo 致力于提供统一的服务治理能力，让业务开发者、架构师能够以云原生的方式来定义自己的微服务架构，来满足自己的业务发展，从而减少实施微服务治理时的阻力。
在以往，架构师在设计架构时，总是要考虑各种微服务框架的能力、各种通信协议的差异、各种服务治理带来的能力差异，导致设计时要考虑很多底层的实现，极大的增加了认知负担。业务开发者也要关注当前的微服务框架如何才能满足自己的治理要求、当前的通信协议如何灰度、如何调试、如何限流等。可以预见，业务开发者将耗费很大一部分的精力在微服务框架、服务治理上，在核心业务价值上的投入却少了很多。
OpenSergo 将对底层能力标准化，对架构师、对业务开发者屏蔽底层差异，用更加云原生的方式来治理微服务。架构师只需要用统一的能力模型设计业务架构，而业务开发者也只需要利用统一的能力模型来专注于业务开发。
此外，对于企业而言，现有的微服务治理体系，严重特化于现有框架，阻碍了微服务框架的选型，也阻碍了新技术、新业务的发展。所以 OpenSergo 的另一个重点，是帮助开源微服务框架在企业顺利落地。
对于各类微服务框架，在企业中落地的一个重要难点就是与现有的服务治理体系相结合。借助 OpenSergo 标准化的服务治理能力，开源微服务框架可以通过标准化的服务治理能力与企业现有的基础设施结合，迅速在企业落地，兑现业务价值。
微服务框架对接 OpenSergo 后，业务开发者只需要修改环境变量来接入，即可和现有的服务治理系统相结合，提供上述的服务治理能力。而此前，每个企业都要对接各自的微服务治理体系，OpenSergo 能够提升企业接入新框架、新技术的速度，也能减少服务框架开发者的服务治理对接成本，扩大微服务框架的采纳率、影响力。
让异构微服务能够统一治理、让更多微服务能够互联互通，塑造更加云原生的微服务，是 OpenSergo 建立之初就树立的长期发展目标。
在数据面建设上，OpenSergo 社区将在服务注册与发现、服务治理能力上做进一步补齐，提供统一的服务治理控制面和 Dashboard，招募更多的企业和微服务框架进入社区。同时，我们看到控制面标准化、数据面多样化的趋势，Nginx、Ingress、Apache Dubbo-go-pixiu 等网关作为数据面的流量入口，与 SDK、Java Agent、Sidecar 等多种方式的数据面在能力上能够完全对齐，给更多用户带来简单、一致的、更加云原生的服务治理体验。
在标准化建设上，OpenSergo 社区会联合各个微服务框架、相关厂商、企业、用户等相关方，在更多领域层面上标准化微服务能力，让企业能够用一套语言来描述自己的微服务架构，让开发者专注于业务核心价值，让微服务框架也能够被客户轻松采用。
在控制面建设上，OpenSergo 社区目前已经提供 OpenSergo Dashboard 来直观实用，也将会给微服务标准功能提供一个参考控制面，并通过中立的 OpenSergo 协议，让所有的微服务框架、所有的通信协议都可以被同一套微服务门户来治理。
OpenSergo 自创立就是社区项目，通过 Apache License 2.0 协议开源。后续在 OpenSergo 微服务规范的制定、发展上，也会通过公开、透明、民主的方式来制定标准、推动实施。未来也将通过 GitHub issue、邮件列表、社区双周会等机制，确保通过社区协作的方式确定相关规范。欢迎大家通过这些形式一起来讨论、共建。