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

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 方式为异构语言服务，提供基础的服务治理能力。

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

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