跨不同开发语言和技术框架，微服务治理规范OpenSergo项目正式开源
近几年，由于企业规模变大、IT 系统迅速膨胀，以及市场环境变化越来越快，原先单体架构的 IT 系统已无法满足业务需求。为了能更高效、灵活地支撑业务发展，企业纷纷从单体架构转向了微服务架构。
微服务架构和企业自身的技术积累及业务特点紧密相关，很多互联网企业会在实际落地时结合自身特点打造自己的框架和组织形式。同时，微服务又离不开配套的治理能力，如服务可观测、全链路压测和跟踪、注册发现、配置中心、服务网格等。
在这些技术的发展过程中，业界逐渐形成百花齐放的局面，产生了不同的开发语言和框架，这给企业带来了繁重的维护负担。而且，不同框架之间的互通也存在各类损耗和高复杂度等问题。
面对这些痛点，阿里云于 2022 年 1 月开始和 bilibili、字节跳动等企业，以及 Nacos、Spring Cloud Alibaba、Apache Dubbo 等社区讨论合作服务治理规范化和标准化的事宜，共同成立了 OpenSergo 项目。目前该项目已通过 Apache License 2.0 协议开源。InfoQ 采访了阿里云和 bilibili，以了解如何构建一个微服务治理规范项目。
采访嘉宾：
张乎兴，阿里云高级技术专家；鲁严波，阿里云高级研发工程师；陈志辉，bilibili 基础架构团队研发工程师。
阿里云：在阿里巴巴内部，服务治理体系从形态上经历了从 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 等体系中使用。
阿里云：服务治理是微服务改造深入到一定阶段之后的必经之路。
随着越来越多的企业完成微服务化改造，服务治理的话题热度逐步升高，越来越多的架构师、开发者开始意识到服务治理的必要性。目前，服务治理在国内市场正处于快速发展的上升期。
一方面，经过十多年的微服务化历程，阿里巴巴的微服务实例规模已经达到百万级，Dubbo 3.0 和 HSF 融合顺利，即将完成三位一体的重大历史使命，服务治理的能力也非常成熟，并且已经具备商业化的服务能力，在一些头部互联网公司已经有非常深入的落地实践。
另一方面，除了一些头部互联网正在落地服务治理，其他已经完成服务化改造的企业也都对服务治理有着强烈的诉求，但是缺少完整的方法论和最佳实践，缺少开源的标准化方案，造成企业引入服务治理变得举步维艰。
综合看来，目前最大的痛点主要是：
业界对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念都不一致，造成很高的理解和沟通成本。
开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，Spring Cloud 中定义的微服务接口和 Dubbo 中定义的接口就没有办法互通，通过 Dubbo 和 Istio 管理的微服务也没有办法进行统一治理。
缺少真正面向业务、能够减轻认知负担的抽象和标准。开发者真正想要的可能是简单的、指定服务间的调用关系和配置规则。但对于业务来说，不仅需要了解不同微服务框架的部署架构，也要了解不同服务治理方式的概念和区别。
bilibili ：目前，我们基本都已经微服务化，随着新业务的快速增长，服务治理规范化也是越来越重要。因为当我们的业务发展起来了，一般都很难进行改造或者升级，或者说会带来很大的改造成本。所以在企业发展过程中，都是建议统一框架、统一治理，标准制定就成为了重要的环节。对于微服务之间的通信，我们选择了 gRPC 作为统一的协议，并做了统一的 BAPIs 仓库管理 Protobuf 接口定义，方便各个微服务开发和调用。
整体上看，对于我们主要的痛点有：
服务治理，主要是以落地和解决问题为主，没有很好地形成标准和规范化，对研发会有一定理解成本。
业务框架以 Go、Java 为主，对于主流框架，我们是倾向通过 Proxyless 方式提供业务使用，缺少开源统一 SDK 和 治理标准进行实现治理能力。
阿里云：随着阿里巴巴内部异构微服务业务的不断增加，以及越来越多的企业将微服务搬到云上，我们发现，由于语言异构、框架异构导致的微服务治理成本成指数级增加。每个开源框架和协议针对微服务治理的定义概念和能力都不一致，造成开源实现和云服务的实现无法完全对齐。使用开源方案的企业，无法顺畅地迁移到云厂商提供的服务治理相关的 PaaS 服务上。尤其是多云成为趋势的情况下，企业在选择不同的云厂商时，更是无法享受到标准的 PaaS 级服务治理能力。
对于使用者而言，不同的框架和协议代表着要选用不同的治理模型、治理规则，这给他们带来了额外的认知负担。现存的微服务治理框架极大地限制了新语言、新框架的采用，导致企业技术迭代受到非常大的限制。
考虑到这些点，我们在 2022 年 1 月开始和 bilibili、字节等企业，以及 Spring Cloud Alibaba、Nacos、Apache Dubbo 等社区讨论合作服务治理规范化和标准化的事宜，共同成立 OpenSergo 项目，该项目将以对开源使用方和其他云厂商都非常友好的 Apache 2.0 开源协议进行开源。
OpenSergo，Open 是开放的意思，Sergo 则是取了服务治理两个英文单词 Service Governance 的前部分字母 Ser 和 Go，合起来即是一个开放的服务治理项目。
bilibili ：在这两年时间里，我们海外业务快速发展，业务上基本没有太多的历史包袱，所以为了跑得更快，我们倾向这部分业务直接往云原生方向发展。基本上也是选择了社区生态比较好的开源软件和标准，比如 gRPC、OpenTelemetry、K8S 等等。同时也整合到我们开源的 Kratos 框架中，但是在这个过程中，我们发现社区里缺少比较好的服务治理标准，我们自己造轮子其实并不划算。所以，我们也跟阿里这边进行了多次的技术分享交流，并且发现都有各自的出发点，便共同讨论了业界的成熟的服务治理标准体系。我们打算通过开源社区进行孵化服务治理相关的实践，去解决所遇到的服务治理问题。
阿里云：OpenSergo 要解决的是不同框架、不同语言在微服务治理上的概念碎片化、无法互通的问题。OpenSergo 致力于在不同的微服务框架、通信协议之间达成共识，形成云原生服务治理规范，让框架的使用者不会因为语言的不同、框架的不同而产生割裂，让架构师能够用一种统一的规范来描述自己内部的微服务架构。这里面要解决的主要问题包括：
如何标准化地进行服务注册和发现；
服务的元信息格式如何统一；
如何声明式地指定服务治理应该具备哪些能力；
异构微服务之间如何互通；
如何标准化定义微服务的可观测性等。
阿里云：OpenSergo 主要包含三大部分：
控制面：用户可以通过 CRD 或者 Dashboard 的方式查看、修改服务治理配置，并将这些管控信息下发到数据面。
数据面：JavaAgent、Servcie Mesh、各个接入 OpenSergo 的微服务框架都能够接收到服务治理配置，并应用到当前的业务流量中。
OpenSergo Spec：Spec 规定了控制面和数据面的通信约定，确保用户使用一种 Spec 即可描述不同框架、不同协议、不同语言的微服务架构。
对于控制面，OpenSergo 统一了治理规则，用户不必再绑定到某个开源方案、某个云厂商提供的服务上。不同的数据面、控制面只要对接 OpenSergo Spec，即可无缝对接现有的服务治理体系。
对于数据面，OpenSergo 提供了不同的接入方式：
Spec/SDK 接入：微服务框架可以通过 OpenSergo 规范实现自助接入。各个框架也可以通过 SDK 简单地接入到 OpenSergo 中，这种接入方式能够获取到更多的框架内部信息，也能够省去 Sidecar 带来的额外性能、资源开销。
Sidecar 方式接入：对于多语言服务，OpenSergo 可以将服务治理规则推到 Sidecar 中，以 Sidecar 方式治理现有的微服务应用。
JavaAgent 接入：对于 Java 应用，JavaAgent 可以用无侵入的方式将服务治理能力增强到现有的微服务应用中，能够很好地将存量 Java 应用带入到统一的微服务治理体系中来。
阿里云：不同于其他开源项目先提供实现的方式，OpenSergo 从创立之初就秉承规范先行的理念，首先通过规范的形式约定服务治理的基础概念，并定义好服务治理的配置及对应语义。
OpenSergo 自创立就是社区项目，通过 Apache License 2.0 协议开源。后续在 OpenSergo 微服务规范的制定、发展上，也是通过公开、透明、民主的方式来制定标准、推动实施。未来也将通过 GitHub issue、邮件列表、社区双周会等机制，确保通过社区协作的方式确定相关规范。OpenSergo 对其他云厂商也是开放的，欢迎一起来共建。
阿里云：让异构微服务能够统一治理、让更多微服务能够互联互通，是 OpenSergo 建立之初就树立的长期发展目标。
后续，OpenSergo 社区将在服务注册与发现、服务治理能力上做进一步补齐，提供统一的服务治理控制面和 Dashboard，招募更多的企业和微服务框架进入社区。同时，我们看到控制面标准化、数据面多样化的趋势，Apache Dubbo-go-pixiu 等网关作为数据面的流量入口，与 SDK、Java Agent、Sidecar 等多种方式的数据面在能力上能够完全对齐，给更多用户带来简单、一致的、更加云原生的服务治理体验。