NextArch 基金会旗下微服务标准化方案已开源：支持不同开发语言和技术框架

作者 | Tina

今年，腾讯、字节跳动、快手、BIGO、好未来、七牛云、中国移动、蓝色光标等多达 10 家企业和 go-zero/CloudWeGo/GoFrame/TARS 开源社区的技术专家，在 Linux 下一代架构基金会下成立了微服务技术组 SIG（Special Interest Group），共同探讨微服务治理标准化的解决方案，并向 NextArch 基金会提交了首个落地方案。

微服务技术发展至今，业界涌现出了一大批微服务开发框架，比如 PolarisMesh、TARS、go-zero、GoFrame、CloudWeGo 和 Spring Cloud Tencent ，技术和实践的多样化是不可避免的，但是微服务架构里面所涉及的服务治理体系却可以做到统一和规范化。SIG 旨在提供统一服务治理体系，解决共性问题，将促进微服务框架和技术的进一步演进和发展。InfoQ 采访了部分专家，以了解项目背景、进展和规划。

嘉宾简介：

王洪智：腾讯云微服务产品技术总监，微服务引擎 TSE、开源项目 PolarisMesh 负责人。在腾讯长期从事云原生中间件的研发工作，先后负责过注册配置中心、服务治理框架和 Serverless 应用平台等多个项目。

单家骏：腾讯技术专家，PolarisMesh 社区联合发起人，具备 10 年以上中间件研发经验，目前在腾讯负责微服务引擎 TSE 研发工作，以及北极星开源社区项目的技术规划、代码开发和社区运营等工作。曾是 Qcon、掘金开发者大会、CIF 研发效能大会的分享讲师。

张乐：腾讯云技术专家，开源项目 Spring Cloud Tencent 负责人，配置中心 Apollo PMC。长期从事微服务中间件研发工作，目前在腾讯负责微服务引擎 TSE 的研发工作。

1 微服务治理标准化，需要解决什么问题

微服务和业务紧密相关，很多互联网企业无论大小都会在实际落地时结合当前业务场景、技术沉淀来打造自己的框架。同时，微服务又离不开配套的微服务治理，如治理平台、监控、链路跟踪、注册发现、配置中心、服务网格等。这些服务治理体系经过了一个三阶段的演进历程：

第一阶段是在 2014 年之前，是微服务和服务治理萌芽期，在这个阶段，移动互联网应用呈现了爆发式增长，为了处理海量的用户请求，大型互联网企业开始采用分布式架构。业务系统按照业务域拆分为多个高内聚的分布式模块，不同的模块之间通过 RPC 方式进行通信，从而提升系统的并发量和可扩展性。开发者需要额外解决流量调度、故障容错、异常分析等由于引入分布式架构带来的问题，这些问题都属于服务治理的范畴。

第二阶段是 2014 到 2016 年，在这个阶段业界正式提出微服务的概念，开始涌现出一批优秀的微服务框架，例如广为人知 Pivotal 开源的 Spring Cloud 框架。Spring Cloud 框架为 Java 微服务开发者提供服务发现、负载均衡、熔断降级和调用链跟踪等一站式开箱即用的服务治理能力。随着 Spring Cloud 框架的普及，开发者对服务治理的概念和作用有了初步的认识。

第三阶段是 2017 年至今，微服务和服务治理爆发期。基于微服务框架的服务治理体系持续发展，微服务也开始往多语言、多技术栈、异构基础设施的方向发展。基于此背景下，腾讯开源了支持多语言的微服务框架 TARS，阿里也宣布重新维护 Dubbo 开发框架。但是当前服务治理体系都是围绕某个开发框架构建，服务治理功能高度耦合在开发框架中，不同开发框架对服务治理的理解和实现都不一致。以 Istio 为代表的服务网格提出采用流量代理的方式，解决不同开发框架的统一服务治理问题。这种方式本质上就是把服务治理从服务框架中剥离出来，这样就能够做到统一的服务治理。不得不说，Istio 提供了一种很好的思路来解决多服务框架带来的异构问题。但是 Istio 这种流量代理的方式带来了额外性能和资源损耗，增加了业务架构和运维的复杂性。

从上述阶段的历程可以看出，服务框架发展得已经相对成熟，但也还存在一些多样性的问题。大型企业在实际实践中通常存在多种开发语言和框架，一个复杂业务系统可以使用不同的技术栈开发，例如：腾讯的开发语言以 Go 和 C++ 为主，Java、Nodejs、Python 等其他语言也有不少业务使用，还存在 tRPC、TARS 和 SPP 等几种开发框架。同时，企业的基础设施的演进是渐进式的，往往在很长一段时间会同时出现两种或者多种基础设施并存的情况（比如容器和虚拟机共存），这里涉及的场景就包含跨虚拟机和容器、跨应用部署平台和混合云等多种场景。

因此，微服务治理标准化需要解决以下两个问题：

支持多种语言和框架：如果业务开发采用 Proxyless 模式，标准化实现需要提供不同语言的标准化的服务治理 SDK，服务治理 SDK 不和开发框架绑定，方便不同的开发框架集成。如果业务开发采用 Proxy 模式，除了更加轻量级的服务治理 SDK，还需要支持不同通信协议的流量代理。

支持异构基础设施：微服务治理标准化的模型不与具体的部署架构、网络及存储架构绑定，实现上不绑定具体的基础设施，支持容器、虚拟机、多云等场景下都可以无缝对接并互通。

2 业界微服务治理实践经验

目前，业界的服务治理分为微服务框架和服务网格两种类型的方案，这两种类型的方案也称为 Proxyless 和 Proxy 服务治理模式。

虽然服务治理涉及的功能非常多，但是单个功能的实现并不是特别复杂。难点在于服务治理功能的完整性和灵活性，使能够同时满足应用场景、研发模式和基础设施的多样性诉求。目前，不同的微服务框架和服务网格对服务治理功能的理解和实现不一致，没有形成统一的标准和最佳实践，这个是非常大的痛点。开发者需要在自身基础设施的基础上，选择适当的工具，才可以解决微服务落地过程中的各种问题。

但 Proxyless 和 Proxy 两种治理模式是可以共存于同一个系统的。

腾讯于 2019 年发起了北极星项目，面向多语言、多框架和异构基础设施，提供统一的服务发现和治理组件。经过几年的发展，在公司内部覆盖了 90% 的业务部门，基本上形成统一。北极星可以同时支持 Proxyless 和 Proxy 两种服务治理模式。

Proxyless 模式：北极星的 Proxyless 服务治理模式和业界有很大的区别，北极星的 Porxyless 服务治理实现和开发框架解耦，采用独立的轻量级的多语言 SDK 实现，SDK 提供了一批标准化的服务治理接口。公司内部不同的开发框架基于标准化服务治理接口快速集成，从而达到不同的开发框架具备语义相同的服务治理能力。

Proxy 模式：北极星的 Proxy 服务治理模式主要是和社区主流的 ServiceMesh 数据面集成，例如 Istio 的 Envoy 数据面。

Proxyless 和 Proxy 模式可以采用统一的服务治理平面。这也是标准化服务治理的好处。腾讯内部绝大部分的业务采用 Proxyless 模式，因为 Proxyless 模式具备更高的性能，没有额外的资源消耗，对业务的流量没有侵入性，不需要运维 Sidecar。同时，北极星的 SDK 集成在开发框架中，业务开发不需要直接使用北极星的 SDK，对终端开发者透明。

3 SIG 项目的使命和愿景

当前社区的多个开源框架和组件都提供服务治理的能力：

CloudWeGo：提供 RPC 框架 Kitex，在框架之上提供可扩展的服务治理能力， 可以快速搭建一套完善的微服务体系。

go-zero：提供 RPC 框架 zRPC，内建级联超时控制、限流、自适应熔断、自适应降载等微服务治理能力，无需配置和额外代码即可使用。

GoFrame：提供模块化、高性能的企业级应用开发框架，在服务治理上通过扩展的能力提供服务注册发现、配置管理等能力。

PolarisMesh：提供可视化控制面和数据面，提供框架无关、平台无关的服务发现和治理能力，满足多技术栈、异步基础设施的服务治理诉求。

Spring Cloud Tencent：基于 Spring Cloud 框架，提供高度的可扩展性，与社区成熟的开源组件结合，便于 Spring Cloud 技术栈的用户快速构建微服务应用。

多个框架和组件的服务治理语义不仅相同，因此假如一个企业使用了多个框架和组件进行引用开发，则存在互通性的问题。而且目前又没有开箱即用的解决方案，大家必须在不同的基础设施和适当的工具之间做出抉择。SIG 微服务技术组的成立，就是致力解决这些问题。

王洪智认为，现在推动服务治理规范建设是一个比较好的时间点，主要有以下两个方面的考虑：

首先，微服务和服务治理概念已经普及。随着各行各业开始数字化转型，越来越多企业开始采用微服务架构，经历了微服务框架的大规模使用以及服务网格的推广，企业和开发者对服务治理已经有了比较深入的了解。

其次，不同的微服务框架和服务网格对服务治理功能的理解不一致，但在完善度和易用性参差不齐。而且服务框架开发者聚焦于服务治理的底层技术功能的重复建设，缺少面向真实业务场景的最佳实践，用户可能无法将某个功能和生产实践中遇到的问题对应起来。不利于微服务技术的进一步发展。

业内 PolarisMesh/polaris、go-zero、CloudWeGo/Kitex 等开源框架已经实现了服务治理的部分功能，SIG 微服务技术组在这个基础之上，希望构建一个标准化的微服务解决方案，建立统一的语义，为企业提供多框架、多语言服务的统一管理。

4 标准化方案现状及后续计划

服务治理标准化的解决方案包含两个部分，一部分是服务治理的标准化功能定义和最佳实践，一部分是服务治理面和数据面的标准化协议和接口。

一方面，标准化项目会提供实现。标准化实现包含三个部分：

第一部分是服务治理控制平面：治理平面面向用户，通过提供可视化界面支持服务治理功能的管控（包括规则的编辑、治理效果的监控等），并下发规则到数据平面。

第二部分是数据平面：数据平面主要面向框架或应用，提供 API 接口进行功能的暴露。过程中会接受治理平面下发的规则进行，并执行具体的服务治理逻辑处理。

第三部分是开发框架：数据平面可以单独使用，更常见的是集成在开发框架中，通过扩展开发框架的拦截器或接口，实现标准化实现与框架的集成。

北极星（PolarisMesh）会在现有的基础上支持服务治理标准化控制面和数据面，go-zero、GoFrame、CloudWeGo 和 Spring Cloud Tencent 等多个开源社区也会提供标准化开发框架实现，为各个社区的用户提供开箱即用的实现。这些开源项目都经过了企业内外部用户的验证，在性能和稳定性上都有保障，可以加速标准化的落地。

另一方面，标准化解决方案分为以下几个部分：

1. 标准化 Spec 建设：各个企业和社区在下一代架构基金会微服务技术组的组织下，融合当前的服务治理实践经验，共同制定服务治理标准化规范，通过文档及协议的方式对用户呈现。
2. 控制面支持：当前 PolarisMesh（北极星）已经提供了可视化的服务治理控制台及可观测性能力，计划会接入中立的服务治理 Spec 的语义，将规则通过标准协议接口暴露出去，便于数据面及社区开发框架进行统一接入。
3. 数据面支持：如前所述，当前 PolarisMesh（北极星）已支持 proxyless 和 proxy 的数据面接入方式，提供了多语言的 SDK，高性能无侵入的 Sidecar，以及基于字节码机制的 Java Agent，计划会接入中立的服务治理 Spec 的语义，通过统一的治理语义对接社区标准的控制面。
4. 开发框架支持：开发框架保持自身服务治理能力的基础上，对标准化 Spec 进行实现，从而增强自身服务治理能力，实现互联互通的目标。计划会通过以下开发框架进行对标准化 Spec 进行支持：
5. go-zero：内建级联超时控制、限流、自适应熔断、自适应降载等微服务治理能力，未来也会通过中间件能力开放的方式对微服务治理标准化进行实现。
6. CloudWeGo/Kitex：当前已支持服务注册发现、负载均衡、熔断限流、可观测性等服务治理能力，具备高可扩展性，未来会实现服务治理 Spec。
7. GoFrame：当前模块化、高性能的企业级应用开发框架，未来会提供基于服务治理标准化的服务注册发现、配置管理等能力。
8. Spring Cloud Tencent：基于服务治理标准化语义对 Spring Cloud 框架进行扩展，便于 Spring Cloud 技术栈的用户快速接入并构建微服务应用。

目前项目的路线已有了明确的规划，并在稳步推进中：

相关项目地址

服务治理标准化 Spec：https://github.com/nextarch/SIG-Microservice

PolarisMesh/polaris：https://github.com/polarismesh

go-zero：https://github.com/zeromicro/go-zero

CloudWeGo/Kitex：https://github.com/cloudwego/kitex

GoFrame：https://github.com/gogf/gf

Spring Cloud Tencent：https://github.com/Tencent/spring-cloud-tencent