Summary of the OpenSergo community biweekly meeting (Oct 12nd, 2022)

1. Our contributor @jnan806 submitted a PR of the initial version of OpenSergo Go SDK recently. He shared the detailed design and implementation of the SDK, and discussed about shared-client mode of OpenSergo SDK (see the issue for detail).

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

2. The community presented a demo show of Spring Cloud Alibaba + OpenSergo traffic-routing.

GitHub discussions: https://github.com/opensergo/opensergo-specification/discussions/47

Summary of the OpenSergo community biweekly meeting (Sep 28th, 2022)

1. We showed how a framework could leverage OpenSergo SDK to integrate with OpenSergo, and manage the service goverance rules via OpenSergo Control Plane.
2. Logging is an essential part of microservices. We've discussed ideas of log governance with iLogtail community.

GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/44

Summary of the OpenSergo community biweekly meeting (Sep 15th, 2022):

• The POC version of OpenSergo Control Plane has been open-sourced. Reviews are welcome: https://github.com/opensergo/opensergo-control-plane/pull/5
• We're pleased to announce that the v1alpha1 version of OpenSergo database goverance specification, which was cooperated with ShardingSphere and Database Mesh community, has been officially available. The community will make progress on spec support in Java SDK.
• The community discussed the management of the opensergo-proto project and polyglot gRPC stub code. See https://github.com/opensergo/opensergo-proto/issues/3 for the discussion.

GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/41

Summary of the OpenSergo community biweekly meeting (Aug 31st, 2022):

1. The community shared the detailed design of OpenSergo control plane and OpenSergo universal transport service.
2. A demo show of Sentinel + OpenSergo, which illustrates how OpenSergo fault-tolerance CRD takes effect in Sentinel (via OpenSergo data-source).

GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/36

Summary of the OpenSergo community biweekly meeting (Aug 17th, 2022):

1. Developers from ShardingSphere and Database Mesh community shared and discussed the detailed design of database governance v1alpha1 spec, which has been submitted to the community. Discussions are welcomed: https://github.com/opensergo/opensergo-specification/issues/15
2. The community shared the detailed design of traffic routing v1alpha1 spec, which covers more comprehensive detailed design of route matching, target destination, router chain. Communities including CloudWeGo, Kratos and SOFA, participated in related discussions. Proposal: https://github.com/opensergo/opensergo-specification/pull/29
3. The community introduced the progress of OpenSergo Control Plane and SDK, and discussed the design of gRPC transport and service. In terms of transport service, the community has decided to adopt a custom simple gRPC protocol (OpenSergo universal transport service) rather than on xDS (ECDS).

GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/27

Summary of the OpenSergo community biweekly meeting (Aug 4th, 2022):

1. We've discussed the design of the gRPC transport protocol between the OpenSergo SDK and the operator, and introduced two designs: OpenSergo universal transport service and OpenSergo on xDS (ECDS). For details, please refer to: https://github.com/opensergo/opensergo-specification/issues/22
2. Developers from the Database Mesh community shared the overall design of database governance v1alpha1 spec, including virtual database, traffic governance (load balancing, read-write separation, rate limiting), sharding, access control and other major areas. The spec proposal will be submitted soon.
3. Communities including CloudWeGo Kitex, Kratos, and Spring Cloud Alibaba are interested in capabilities such as traffic routing (gray). It's welcome to work together to improve the relevant specs and integrate them with the components.

GitHub discussion: https://github.com/opensergo/opensergo-specification/discussions/21

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/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) 由以下三部分组成：

• 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/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，提供服务治理、流控降级、注册配置中心、云原生网关、分布式事务等核心能力，欢迎大家体验。

背景​

软件架构的核心挑战是解决业务快速增长带来的系统复杂性问题。系统越复杂，对服务治理诉求越强烈，小的技术问题越可能被放大，从而造成大的线上故障。而微服务治理就是通过无损上线下、全链路灰度、流量防护等技术手段来减少、甚至避免发布和管理大规模应用过程中遇到的稳定性问题。

虽然大家都认为微服务治理很重要，但在落地过程中会遇到各种难题。

例如，在企业内部，往往存在着不同语言、不同通信协议的微服务，这会导致治理微服务的过程中，给业务开发者、架构师平添很多的认知负担，而这类异构会衍生出更多的痛点。

• 业内对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念不一致，造成很高的理解和沟通成本。
• 开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，Spring Cloud 中定义的微服务接口和 Dubbo 中定义的接口就没有办法互通，通过 Dubbo 和 Istio 管理的微服务也没有办法进行统一治理。
• 缺少真正面向业务、能够减轻认知负担的抽象和标准。开发者真正想要的可能是简单的、指定服务间的调用关系和配置规则。但现在对于业务开发者来说，不仅需要了解不同微服务框架的部署架构，也要了解不同服务治理方式的概念和能力区别，认知成本很大。

企业级微服务治理实践​

阿里巴巴的微服务实践​

在阿里巴巴内部，服务治理体系从形态上经历了从 SDK 方式、到 Fat-SDK 方式、再到 Java Agent/Sidecar 化的演进历程。具体而言，阿里巴巴从 2008 年就开始了微服务的改造，诞生了服务框架 HSF 及配套的服务治理能力；2012 年，Dubbo 框架开源，提供了非常优秀的服务治理能力，这个阶段的服务治理能力是以 SDK 的方式和服务框架进行一体化演进的；2013 年开始，为了解决 SDK 升级成本高的问题，中间件团队推出轻量级隔离容器 Pandora，将服务治理能力通过 Fat-SDK 的方式从业务中剥离出来，大幅度提升了升级效率。

然而这种方式仍然面临较高的升级成本。为了将服务治理体系和业务彻底解耦，阿里巴巴从 2019 年开始，通过将服务治理能力下沉到 JavaAgent，实现了完全无需对业务做任何改造、就能接入服务治理的能力。后来，我们将这个技术方案进行产品化，通过阿里云微服务引擎 MSE 这款产品服务云上的企业客户。

同一时期，随着业务发展的多样化，多语言构建的业务在集团内部逐渐流行起来，阿里巴巴内部开始探索多语言的治理方案，采用了基于 Istio + Envoy 的 Sidecar 方式为异构语言服务，提供基础的服务治理能力。

在这个过程中我们逐渐发现，异构微服务框架之间有不同的体系和认知，在很多概念上无法完全对齐，用一套标准的服务治理方案治理各种微服务体系变得愈发困难。因此，我们迫切需要一个和语言无关、和技术形态无关，但贴近业务的统一服务治理规范，使得异构微服务体系能够互联互通以及进行统一治理。

总结下来，阿里巴巴内部的服务治理经历了从基础数据面建设、到治理能力探索、再到能力标准化建设三个阶段。

bilibili 的微服务实践​

从 2016 年开始，bilibili 进行经历巨石架构到微服务的完整转型，整个过程中，也面临了很多服务治理问题。从单体到微服务整个部署和管理模式开始进行转变，我们为了提高研发效率和稳定性拆分了不同粒度的服务，所以我们于 2017 年开始思考如何管理微服务，从而开始通过容器部署和隔离，在管理方面极大地解决了我们的问题，同时也建设了统一的注册中心和配置中心基础中间件，整个微服务也围绕这两个基础中间件做了很多服务治理相关的。

在早期我们语言还是比较统一的，基本上是以 Go 语言为主，有统一的 Kratos 框架，所以服务治理也是优先选择了 SDK 方式进行管控。随着这几年的业务快速发展，内部出现 Java、C++ 等一些语言，我们尝试了 Service Mesh 通过 Sidecar 方式进行管理，在这个过程中我们逐渐发现，整个维护成本其实是不小的，并且性能损耗在降本增效的这个大环境下也有比较大的挑战。所以，我们也非常期待有一套服务治理标准，可以在 Kratos 框架、Java Agent、Istio 等体系中使用。

微服务治理的发展趋势​

展望未来，微服务治理的发展趋势，是让业务迭代更加高效、业务和治理更加透明和解耦：

• 服务治理数据面透明化、多元化：微服务数据面会逐渐下沉为基础设施，业务开发者会将数据面当作一个标准组件来使用。同时，服务治理也会通过多种形态来支持不同的数据面，对齐服务治理数据面能力。
• 服务治理数据面标准化：微服务框架会直接对接标准的服务治理标准，减轻微服务框架的对接负担；业务开发者也只需要理解标准的服务治理数据面标准，不需要了解底层能力，降低认知负担。
• 数据面实现互操作性：各个微服务框架、各个通信协议提供的能力会标准化，能够让用户用统一的模式来认知和治理。

OpenSergo 的使命和愿景​

基于此，阿里巴巴在2022年1月开始和 bilibili、字节等厂商讨论服务治理如何规范化和更加普及，从而共同发起了 OpenSergo 项目。

我们观察到，目前不同框架、不同语言在微服务治理上的概念碎片化、无法互通。所以，OpenSergo 致力于在不同的微服务框架、通信协议之间达成共识，形成服务治理规范。

• 让业务开发者，不会因为不同的语言、不同的框架而产生割裂。
• 让架构师，能够用统一的规范来描述自己内部的微服务架构。
• 让中间件开发者，能够和现有微服务框架对齐，增强微服务框架之间的互操作能力，促进微服务框架在企业落地。

OpenSergo 总览​

OpenSergo 主要包含三大部分：

• 控制面：用户可以通过 CRD 或者 Dashboard 的方式查看、修改服务治理配置，并将这些管控信息下发到数据面。

• 数据面：JavaAgent、Servcie Mesh、各个接入 OpenSergo 的微服务框架都能够接收到服务治理配置，并应用到当前的业务流量中。各个数据面都能够认可OpenSergo规定的服务治理配置、流量标签等信息，确保降低开发者理解成本。

• OpenSergo Spec：Spec 规定了控制面和数据面的通信约定，确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构，让开发者不再需要关注底层差异。

对于控制面，OpenSergo 统一了治理规则，用户不必再绑定到某个开源方案、某个云厂商提供的服务上。不同的数据面、控制面只要对接 OpenSergo 规范，即可无缝对接现有的服务治理体系。

对于数据面，OpenSergo 提供了不同的接入方式：

• Spec/SDK 接入：微服务框架可以通过 OpenSergo 规范实现自助接入。各个框架也可以通过 SDK 简单地接入到 OpenSergo 中，这种接入方式能够获取到更多的框架内部信息，也能够省去 Sidecar 带来的额外性能、资源开销。
• Sidecar 方式接入：对于多语言服务，OpenSergo 可以将服务治理规则下发到 Sidecar 中，以 Sidecar 方式治理现有的微服务应用。
• Java Agent 接入：对于 Java 应用，Java Agent 可以用无侵入的方式将服务治理能力增强到现有的微服务应用中，能够很好地将存量 Java 应用带入到统一的微服务治理体系中来。

从阿里巴巴集团内部和阿里云提供的服务治理经验来看，结合各个开源微服务框架、各公司内部的治理经验，从服务治理功能层面来说，目前业界认可的主要分为上图中的开发态、测试态、发布态、高可用、安全态五个部分：

• 开发态：方便业务开发者了解微服务定义，方便开发调试；提升研发效率，让开发更快捷。
  • 服务契约：能够让各个微服务框架来定义提供了哪些接口、每个接口的参数、以及接口的业务说明；便于开发者迅速了解应用。
  • 服务调试：能够填写入参、迅速发起一个服务调用，不再需要自己写代码。
  • 服务Mock：在开发过程中，能够暂时模拟应用行为，防止应用依赖阻碍开发进度。
  • 开发环境隔离：通过逻辑隔离的方式，为每一个正在开发的功能特性隔离出一个独立的环境， 在低成本的前提下，划分出多个完整的独立环境，使得各功能特性的开发调试不会互相影响， 提升开发迭代的效率。
• 测试态：方便测试人员压测、回归、验证功能；提升测试效率，让测试更快更准更全面。
  • 服务压测：快速发起压测，迅速了解微服务的容量是否偏离基线，确保应用性能
  • 自动化回归：通过自动化的方式进行回归测试，自动发起测试并自动比对结果进行验证，无需人工重复测试，保障业务代码逻辑的正确性
  • 流量录制：将线上流量录制下来，自动生成测试用例进行回归测试，通过真实的请求丰富测试用例
  • 流量回放：将录制好的流量重新运行，验证当前的业务运行结果是否和录制好的请求的结果匹配，保障业务逻辑的正确性
• 发布态：解决业务发布的时候的流量治理问题，让应用发布能够顺畅稳定。
  • 无损下线：确保应用在发布、停止、扩容时，所有请求都不会被影响，确保微服务下线的过程中业务无损。
  • 服务预热：应用刚启动时可能会存在一些资源未初始化完成、未预热完毕的情况，服务预热可以确保在这个场景下不影响业务。
  • 金丝雀发布：满足特定流量特征的请求才会进入微服务的灰度节点，通过小流量验证微服务 新版的逻辑是否符合预期。
  • 全链路灰度：一个迭代的多个应用同时发布，希望经过灰度的上游流量只能达到下游的灰度 节点，确保灰度流量只在灰度环境中流转。
• 高可用：提供限流、降级、熔断等能力，保障业务稳定性、可用性。
  • 限流：针对超过阈值的流量进行限流控制，保障机器和整体业务的稳定性。
  • 降级：在资源有限的情况下，针对某些不重要的请求返回预设的降级结果，把有限的资源让给重要的请求。
  • 熔断：客户端访问后端服务不可用的情况下，返回预先定义的异常或结果，避免引起业务异常，甚至雪崩。
  • 离群实例摘除：在单个服务提供者节点持续不可用的情况下，在消费者侧摘除这个异常节点，保障业务的高可用。
  • 临近路由：微服务多可用区部署的情况下，确保流量优先在同一个可用区内流转，降低业务的整体时延。
  • 就近容灾路由：当某个可用区发生故障，可以把流量尽快的切到正常的可用区，让业务以最快速度恢复。
• 安全态：保护敏感业务、提供零信任能力，保障业务安全。
  • 服务鉴权：保护敏感微服务，确保敏感服务只能被已授权的应用访问和调用。
  • 漏洞防护：微服务框架通常会陆陆续续被发现许多漏洞，整体的升级成本很高，需要通过不升级框架的方式实现漏洞的防护，可以通过流量拦截、动态程序修改等技术来修复和缓解。
  • 配置鉴权：对于敏感配置，不希望任何微服务都有权限访问，控制只有受限的微服务才能访问。

从更大的角度来看，除了微服务框架、Service Mesh、Java Agent 方式的治理之外，服务治理还会关注网关、存储等完整的调用链路；在实现上，也会包括微服务服务发现、配置管理、分布式事务等微服务基础组件的治理和接入。

在图中的子领域中，OpenSergo 会采纳现有的规范、提出落地新的规范，来给业务开发者提供一套标准界面，能够对业务开发者、架构师屏蔽底层差异，让他们专注于核心业务价值，从而真正兑现云原生微服务的价值。

OpenSergo 减少实施微服务治理时的阻力​

OpenSergo 致力于提供统一的服务治理能力，让业务开发者、架构师能够以云原生的方式来定义自己的微服务架构，来满足自己的业务发展，从而减少实施微服务治理时的阻力。

在以往，架构师在设计架构时，总是要考虑各种微服务框架的能力、各种通信协议的差异、各种服务治理带来的能力差异，导致设计时要考虑很多底层的实现，极大的增加了认知负担。业务开发者也要关注当前的微服务框架如何才能满足自己的治理要求、当前的通信协议如何灰度、如何调试、如何限流等。可以预见，业务开发者将耗费很大一部分的精力在微服务框架、服务治理上，在核心业务价值上的投入却少了很多。

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、邮件列表、社区双周会等机制，确保通过社区协作的方式确定相关规范。欢迎大家通过这些形式一起来讨论、共建。