OpenSergo 社区建设进展和近期规划-阿里云开发者社区

OpenSergo 社区建设进展和近期规划

——鲁严波

OpenSergo 社区负责人

一、背景

随着企业用户云原生化进入深水区，企业微服务上云部署之后，微服务治理逐步成为企业下一阶段的核心诉求。

此前举办的容器 WorkShop 北京站和深圳站，有 74.59% 的客户对微服务治理最感兴趣。从 github 上相关项目反馈以及新兴项目趋势来看，微服务治理是容器用户和微服务用户最感兴趣的话题。

微服务治理的发展可以分为4个阶段：

第一阶段：云上部署。用户将机器通过 ECS 的方式上云，以机器为核心进行部署。

第二阶段：云原生部署。用户将业务做云原生化部署，即容器化部署，以容器为核心在云上运行。

第三阶段：微服务化。用户对业务做微服务化改造，以便实现更敏捷的开发和迭代，以应用为核心在云上部署。

第四阶段：微服务治理。用户希望在开发效率、运维效率和稳定性方面得到提升，以业务为核心进行微服务治理。

目前，开源领域并没有微服务治理的统一标准方案。比如作为微服务使用方，在工作负载上可以选择容器和 ECS ，在语言上可以选择 Java、 Golang ，在框架上可以 Spring Cloud 、Dubbo、Karos，在接入服务治理方式上可以选择 Java Agent、 Service Mesh或各个语言的 SDK。

对于企业而言，每一套选型都有不同的抽象和概念。比如 Dubbo 的service 和 Spring Cloud 的 HttpEndpoint 是完全不同的模型，其服务治理方法和能力也不一样。比如Java Agent 只支持 Java，Service Mesh支持多语言但无法获取内部信息。以上种种因素最终导致碎片化的结果，业务开发人员难以理解。

服务治理概念在企业内部比较难以落地。对于业务开发者，服务治理带来复杂的理解成本。而企业内部自建的服务治理平台、 Java Agent 或 SDK 等，可能要求业务开发者在适当的地方给流量打标，比如做全链路灰度时需要在网关给流量打标，需要在中间流量路径上根据流量标来做灰度等，这势必会与业务代码耦合，导致业务业务开发人员还需兼顾基础认知。

此外，对于业务开发者而言，现有的服务治理平台会限制新技术选型和尝试。比如从业务开发者角度，企业内部可能已经有一套 Java 的微服务治理平台运行得非常成熟，但如果要引入一套 Golang 微服务，比如 Golang、gRPC 协议微服务，则需要调研内部微服务治理平台是否支持 Golang 和 gRPC ，此类功能上的问题会限制新技术选型和尝试再结。

从中间件开发者角度出发，中间件在企业中落地，势必与现有微服务治理基础日志集成，意味着需要对企业做特定接入和定制化开发等。而定制化开发需要极高的开发成本，后续维护也较为麻烦，难以跟上最新迭代，因此新的中间件在企业中落地难度较大。

基于以上背景，我们推出了 OpenSergo 项目。其核心是构建一套开放、面向应用、贴近业务语义的服务治理标准和参考实现。

对于业务开发者而言，OpenSergo 建立了一套标准化的服务治理 spec 和参考实现，也使得开发者只需关注业务逻辑，能够更专注地实现业务价值，无需担心服务治理带来的厂商锁定，因为 OpenSergo 提供了跨云跨厂商部署的能力。

对于中间件开发者而言，OpenSergo 使中间件更容易在企业落地。此前，中间件需要对接不同的微服务治理系统，而现在只需对接一套系统即可实现在企业落地。另外， OpenSergo 能够实现中间件之间的互通，比如 gRPC 流量打到 Dubbo 后，除要做协议上的互通以外，还希望两者之间能够互相认可彼此的微服务治理规则，否则会出现流量错乱。

希望业务开发者和中间件开发者能够参与到 OpenSergo 微服务治理标准的制定中，使这套标准真正地为用户带来能力上的提升。

推出 OpenSergo 主要有以下三个目的：

①　制定标准，建设服务治理心智。让业务开发者和中间件开发者意识到服务治理模型是什么，减轻开发者的认知负担和维护负担。

②　兼容多种服务治理方式，比如 Java Agent、Service Mesh以及各种 SDK 模式等，能够将现有微服务框架轻松接入，也能够让微服务框架按照 OpenSergo 的标准模式来治理。

③　希望更多业界伙伴一起参与共建微服务治理标准，演进出更强大的服务治理能力。

OpenSergo 包含三个部分，分别是标准、SDK、接入&集成。

标准：包括流量治理、流量防护、服务发现、数据库治理等标准。很多标准会与对应的开源项目做结合，让用户真正能够通过 OpenSergo 来描述自己的微服务架构。

SDK：为了方便各个厂商的接入和集成，OpenSergo 提供了 Java 、Golang 等语言 SDK 。此外，用户也可以自己写挂载的第三方 SDK 。

接入和集成：目前已经接入Kratos 、Spring Cloud Alibaba、CloudWeGo等， Service Mesh和 Java Agent 正在接入中。另外，微服务链路中流量入口网关部分也正在积极地推进，比如与ShenYu、APISIX等网关对接。与此同时，包含了注册中心、配置中心、消息队列、数据库、日志缓存等基础设施的对接，能够让用户公司按照标准化方式进行管理。

OpenSergo作为服务治理的标准和参考实现，具有以下几个特征：

标准：提供一致、标准的微服务治理模型，降低用户上云和维护成本。

开放：支持多语言、多框架治理模式，比如Mesh+Java Agent+proxyless治理模式等。并持续与行业伙伴共建开放的服务治理标准，比如与 Bilibili、字节跳动CloudWeGo、快手、 Dubbo、SOFA、ShenYu 网关等都有合作，为业界带来价值增量。

价值：减少微服务开发者在面对服务治理时的心智负担，屏蔽各个微服务框架在治理能力上的差异，让微服开发者专注于业务价值的开发。

全方位、全生命周期：提供全方位、全生命周期的服务治理标准。在各个微服务基础设施，比如注册中心、配置中心、消息队列等都会提供标准化能力，抽象形成业务和基础知识之间的统一标准界面，提供更加云原生化的微服务模式。

OpenSergo 的趋势是数据面多样化，控制面标准化。OpenSergo 能够提供管控面实现，中间提供了一套标准 spec，由 Markdown 加 protocol 实现。接入 spec 可以通过 Java Agent、 SDK 以及 Service Mesh 三种方式接入。其具体功能分为开发态、测试态、发布态、高可用和安全态五个方面。

上图为 OpenSergoSpec 架构图。

中间是 Opensergo 标准，包含流量治理标准、流量防护标准、可观测标准、服务发现标准等。管控面通过中间的标准来管控各个微服务，Opensergo Dashboard 能够按照 spec 来治理服务，企业也可以根据标准来自建 Dashboard ，也可以基于 Kubernetes来做 CR 和 CRT 的定义等。

数据面除了可以通过 Java Agent 和Service Mesh来治理服务外，我们正在积极地推进与各个开源框架的对接，比如 Spring Cloud Alibaba、Kratos、Kitex 已经基本对接完成，gRPC 和 Dubbo 等正在推进中。

二、进展

目前，Opensergo管控面 Dashboard 已开源，Kubernetes CR 定义正在积极推进中。

Opensergo 已经将服务元数据标准抽象并整理成标准文档，流量治理、流量防护、服务发现等标准正在积极推进中，也会与相关开源项目进行合作，比如流量防护与 Sentinel 合作，服务发现和 Nacos 合作。

此外，Opensergo 与 Spring Cloud Alibaba、Kratos、Kitex等框架已经基本对接完成，gRPC 和 Dubbo 正在积极推进中。

以上为 Opensergo 页面截图。

OpenSergo 的未来规划主要为三个部分，分别是 spec 制定、数据面建设和管控面建设。2022Q2 将完成流量治理相关规范，2022Q3 将专注于服务发现等微服务基础设施的标准化以及数据面、管控面的建设，2022Q4 将集中补足可观测性能力，2023年将进行互联互通的尝试，让各个微服务之间提升互操作性。