OpenSergo 正式开源 _OpenSergo

文章插图

OpenSergo，Open 是开放的意思，Sergo 则是取了服务治理两个英文单词 Service Governance 的前部分字母 Ser 和 Go，合起来即是一个开放的服务治理项目。该项目由阿里云、bilibili、字节跳动，以及 Spring Cloud Alibaba、Nacos、Apache Dubbo 社区共同维护，旨在构建一个和语言无关、和技术形态无关，但贴近业务的统一服务治理规范和实现，欢迎大家加入共建。

开源背景软件架构的核心挑战是解决业务快速增长带来的系统复杂性问题。系统越复杂，对服务治理诉求越强烈，小的技术问题越可能被放大，从而造成大的线上故障。而微服务治理就是通过无损上下线、全链路灰度、流量防护等技术手段来减少、甚至避免发布和管理大规模应用过程中遇到的稳定性问题。
虽然大家都认为微服务治理很重要，但在落地过程中会遇到各种难题。
例如，在企业内部，往往存在着不同语言、不同通信协议的微服务，这会导致治理微服务的过程中，给业务开发者、架构师平添很多的认知负担，而这类异构会衍生出更多的痛点。

业内对服务治理的能力和边界没有明确的认识，每个企业所定义的服务治理概念不一致，造成很高的理解和沟通成本。
开源微服务框架众多，对于服务治理缺乏一些标准化的约定。例如，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 经历了巨石架构到微服务的完整转型，整个过程中，面临了很多服务治理问题，从单体到微服务整个部署和管理模式开始进行转变，为了提高研发效率和稳定性拆分了不同粒度的服务。bilibili 于 2017 年开始思考如何管理微服务，通过容器部署和隔离在管理方面极大地解决了问题，同时也建设了统一的注册中心和配置中心基础中间件，整个微服务也围绕这两个基础中间件做了很多服务治理的探索。
在早期，bilibili 的语言还是比较统一的，基本上是以 Go 语言为主，有统一的 Kratos 框架，所以服务治理也是优先选择了 SDK 方式进行管控。随着这几年的业务快速发展，内部出现 Java、C++ 等一些语言，尝试了 Service Mesh 通过 Sidecar 方式进行管理，在这个过程中逐渐发现整个维护成本其实是不小的，并且性能损耗在降本增效的这个大环境下也有比较大的挑战。所以，bilibili 也非常期待有一套服务治理标准，可以在 Kratos 框架、Java Agent、Istio 等体系中使用。