从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践

作者 裴斐

在分布式体系下，微服务技术在经历多年发展之后渐趋成熟。进入云原生时代，微服务技术在云原生理念的驱动下被赋予了新的使命。在Info Q 2020年微服务技术年终盘点文章中，我们对传统的服务框架和云原生的服务网格分别进行了分析，指出了服务框架的进化与困局，服务网格的进步、分化、落地，并给出了企业微服务架构的演进方向。

本文将延续微服务架构演进这个话题，结合网易数帆旗下轻舟微服务团队在诸多企业业务落地的微服务治理实践，阐述企业应用在不同阶段采用不同的微服务治理策略，以及从服务框架到服务网格实现架构平滑演进的思路与方法。

服务框架：无侵入Agent服务治理

服务框架是传统微服务技术的核心所在。早期微服务技术中的服务注册、发现、调用、治理、观测都离不开服务框架。这也带来了一些问题，比如业务研发者需要明显感知服务框架并掌握其中各项非业务相关技术，框架版本升级困难，框架越来越重难于维护等等。网易的互联网业务比较多元，早期各业务没有统一的微服务技术规范和框架，大部分业务选型了Spring Cloud、Dubbo、g RPC等开源框架，也有少数业务选择自研RPC框架。服务框架在微服务架构下的问题随着业务、团队规模的扩大日益凸显，这也催生了网易新一代微服务平台——轻舟的建设落地。

2018年，我们以业务无侵入为核心理念构建了轻舟微服务平台，核心数据面基于字节码增强技术实现无侵入Agent服务治理能力，业务无需修改代码即可一键接入微服务治理全家桶能力，大幅提高了用户业务微服务化改造效率，降低了业务进行服务治理相关能力的研发成本。轻舟微服务平台目前已在网易集团内外诸多企业业务落地。

相较于传统服务框架，无侵入Agent服务治理有如下核心优势：

● 代码无侵入、业务无感知引入。业务无需对程序代码任何修改，只需在应用启动项添加Agent参数即可。

● 一键接入微服务治理全家桶（Spring Cloud/Sentinel/Apollo/Skywalking）。业务无需感知框架、版本等实现细节，快捷获得微服务治理All-In-One能力。

● 接管主流注册中心（Eureka/Nacos/Consul/Zookeeper/Kubernetes）。业务无需更换注册中心，服务注册与发现全托管。

● 兼容全系Java应用。基础框架无限制，支持任意Java应用快捷接入。

● 模块化设计，可按需热插拔、升级。业务可按需加载、卸载功能模块，组件灵活演进、升级。

无侵入Agent服务治理方式一定程度上对传统服务框架的组织与接入方式进行了重新定义，为单体应用、初步微服务化的应用提供了便捷的微服务治理套件落地方案。最近我们注意到一些大型互联网企业也开始使用无侵入Agent方式进行微服务治理落地，让我们更加坚定了这种设计的有效性与长期性。

总结：

无侵入Agent服务治理技术可以帮助企业业务高效完成微服务化改造，也为后续微服务架构的持续演进提供了技术基础。

服务网格：低门槛高性能推动企业级落地

服务网格（Service Mesh）是将无侵入服务治理定义的更为彻底的微服务架构方案。通过将微服务治理能力以独立组件（Sidecar）整合并下沉到基础设施，服务网格可以实现应用业务逻辑与服务治理逻辑完全分离，这也使支持多语言、热升级等高阶特性变得顺理成章。网易服务网格建设是随着严选、新闻等互联网业务容器化上云开始的。轻舟微服务平台与业务部门采用合作共建的方式，制定以业务无感知、平滑稳定为服务网格落地的最高宗旨。我们选择由Google、IBM背书的Istio作为服务网格基座进行扩展、增强，为实现业务无感知、平滑稳定接入进行了深入设计与反复论证，已经帮助多个企业核心业务大规模生产环境落地服务网格。

服务网格建设思路方面，我们主要从“低门槛”与“高性能”两个维度进行设计。

低门槛：业务平滑落地的支撑能力

真正意义上支撑不同业务的平滑接入是我们在服务网格平台建设初期的主要挑战，具体体现在：

● 不同业务有着不同的微服务架构现状：不同的框架、协议、注册中心

● 不同业务有着相同的要求：不希望业务有任何修改或感知

● 原生Istio易用性偏弱

为此，我们在支撑业务平滑落地方面做了大量工作，主要可以归纳为以下几个方面：

●业务平滑接入：业务无需修改代码、框架或注册中心，由基础层与平台层适配业务架构、框架

● 多协议支持：HTT、g RPC、Dubbo、Thrift等协议的完整流量管理与精细化治理能力，并沉淀了更多协议扩展能力

● 流量动态拦截：按需对流量协议、端口动态拦截配置，降低企业mesh化门槛

● 核心组件热升级：Sidecar升级无需业务重启，助力服务框架升级效率提升4倍以上

● 治理能力增强：面向业务场景的熔断降级（动态、缓存降级），限流（全局、单机、自适应），接口级鉴权

●流量染色&穿梭：零配置实现请求流量染色、穿梭，快速实现多套测试环境部署与回收

●复杂场景统一管控：支持容器&非容器、多集群、多种组件部署模式（Sidecar、SDK）、多协议等复杂场景统一管控，支持业务迁移过程平滑、可观测

●Envoy API网关：基于Envoy与Istio Gateway CRD扩展实现具备全生态治理能力与高性能的API网关，平滑接管业务原有南北向流量，实现了微服务API网关全面向云原生化升级，达成了微服务集群南北向与东西向核心基础设施统一与共同演进

高性能：大规模微服务集群的支撑能力

业务平滑迁移是服务网格落地的基本条件，而支撑大规模微服务集群则是生产环境下对服务网格平台的"必考项"。早期Istio的设计更多着眼于模型的通用型、灵活性，对大规模生产及微服务集群的支撑能力比较弱，主要体现在：

● 请求多两跳带来的延时退化

● 全量配置分发带来的流量"洪峰"

● 控制平面无自我保护能力

● 无兜底降级能能力

为此我们在支持大规模微服务集群支撑能力方面做了大量工作，主要归纳为以下几个方面：

● 数据面性能、稳定性提升

● 基于用户态协议栈以及SRIOV容器网络的性能优化，时延性能较原生提升2倍以上

● 配置懒加载，实现配置的增量、按需分发

● 连接退避，避免对控制面带来集中"打击"

● 延时与启动速度优化

● 控制面支撑大规模集群

● 应对大规模集群变更

● 限流&熔断

● 主动断连

● 自我观测与监控报警

● 多级容灾：多级兜底降级，保障线上不掉流量

总结：

适应不同的业务架构、框架，提供相同的低门槛、高性能平台能力，是服务网格企业级落地的必备条件

双引擎多模式：从服务框架到服务网格的最后一公里

我们在顺利完成基于无侵入Agent服务治理、低门槛高性能服务网格平台在企业业务落地后，业务对我们提出了更高的要求：

● 无侵入Agent技术已经帮助业务快速落地微服务架构与治理，接下来如何平滑演进到服务网格？

● 服务网格架构虽然完美，但似乎部分应用进程内治理能力无法覆盖，如何解决？

我们自身在建设无侵入Agent服务治理、低门槛高性能服务网格过程中，也沉淀了一些可以支撑业务架构演进的技术方案：

● 无侵入Agent应用进程内服务治理能力，可以成为服务网格架构下缺失能力的补充。在彻底的服务网格架构下，无法实现进程内服务治理，如方法级的熔断、限流、容错、应用内监控等，可以通过Agent的All-In-One套件快速补齐。

● 无侵入Agent的字节码增强机制，可以为业务演进到服务网格提供工具支持。存量业务为引入一些特性而不得不修改代码时，如传递调用链上下文、寻址拦截、调用兜底等等，可以通过Agent在应用中”织入“逻辑进行增强。

● 无侵入Agent具备的模块化、可插拔设计，可以实现服务框架自身到服务网格的“蜕变”。业务在微服务化改造时接入Agent的主要治理特性，在演进到服务网格的过程中可以对一些与服务网格能力重叠的功能逐步“卸载”，逐步完成框架与架构的演进。

带着业务的需求，以及已经独立闭环的无侵入Agent、服务网格技术能力，轻舟微服务平台在2020年开启了新一轮从服务框架到服务网格"最后一公里"能力的探索，即“双引擎多模式”服务治理能力。

定义

●双引擎——狭义是指Agent、Sidecar两种服务治理引擎（组件）；广义是以Agent、Sidecar为核心的整体微服务平台能力。围绕双引擎分别垂直构建的微服务治理能力，旨在使平台基于每种引擎都具备独立支撑业务服务治理场景能力。长期演进上来讲，后续可能有更多引擎引入（比如多运行时Dapr，传统SDK等），这在垂直构建引擎能力设计上长期支持。

●多模式——狭义是指服务+不同引擎的多种治理模式，包括基于Agent的服务治理模式、基于Sidecar的服务治理模式、整合Agent+Sidecar的服务治理模式等；广义上可结合业务情况将服务以不同模式接入平台，服务可以包含多种接入模式的实例，支持不同接入模式的服务实例互相发现、统一治理与平滑演进。围绕“多模式”水平构建以业务应用服务为核心、以引擎驱动业务架构平滑演进的平台能力与解决方案。长期演进上来讲，可以支撑更多治理模式下应用服务的统一纳管、治理、演进，如Agent模式、Sidecar模式、Agent+Sidecar模式、多运行时模式、SDK模式等等。

核心能力

为了完整支撑微服务的治理纳管与演进迁移，我们对双引擎多模式的核心能力进行梳理与分级（从基础L0到高阶L3），用以指导平台建设能力完整性与落地优先级。整体如下：

平台支持Agent、Sidecar分别独立闭环的服务治理能力L0

微服务平台的基础能力，平台具备每种引擎（Agent、Sidecar）相关的整体能力。业务可以选择一种长期使用。对平台来说，即具备：

● 无侵入Agent服务治理体系与平台

● 服务网格治理体系与平台

多种治理模式下服务管理统一视图L0

采用不同治理模式的服务可以在平台上统一展现，包括服务、实例列表，调用拓扑，全平台服务概览等功能。

平台具备业务的服务、实例在演进迁移过程可视化能力，如观测迁移过程中的调用情况（包含跨集群、环境信息）、服务列表、实例列表、监控数据等。

多种治理模式下服务互相发现、调用L1

采用不同治理模式的服务可以实现互相调用和发现，具备演进迁移过程服务的可达性。

具体来说，具备几方面能力：

● 服务在Agent、Sidecar、Agent+Sidecar多种模式下互相发现、调用

● 多注册中心打通，实现服务在注册中心随架构迁移时可发现

多种治理模式服务平滑迁移L2

迁移过程的平滑，具体来说主要包括：

● 治理模式切换。Agent、Sidecar支持平滑迁入、迁出。

● 注册中心切换。多注册中心打通，支持迁移过程平滑切换注册中心。

● 跨环境、集群、网络的服务发现。支持业务跨环境、集群、网络迁移过程的调用可达。

● 存量治理策略迁移。业务已有治理策略的迁移。

多种治理模式的服务治理统一、互补L2

服务处在Agent、Sidecar、Agent+Sidecar等不同治理模式下，治理能力需要形成统一、互补。

●统一是指相同治理功能在不同治理模式下行为一致，各项治理能力不因模式不同对业务产生差异，进而保障迁移过程的平滑性。

●互补是指Agent、Sidecar分别具备的治理能力，在代码、方法级与服务、进程级形成互补，加强服务治理的完整性。

多种治理模式的服务治理用户无感知技术选型L3

应用微服务托管/治理平台在治理方面的高阶设计目标，是用户无需感知底层使用SDK、Agent、Sidecar，仅在平台层按功能需求配置、管控。

目前，经过一年多努力，轻舟微服务平台已经主体实现上述L0-L2的能力，并在L3持续探索，提升平台易用性。

场景覆盖

在打通已有Agent和服务网格能力、形成多模式治理后，微服务平台可以覆盖比较完整的业务场景：无论业务现有技术栈是基础框架，或是增强过的SDK，都可以选择自己的演进路线，通过Agent、Sidecar完成长期的微服务架构平滑演进、升级。

总结：双引擎多模式服务治理能力可以充分利用已有的微服务平台能力，比较好地填补从服务框架到服务网格平滑演进过程的技术空白，提供更整体、更平台化的微服务架构演进支撑能力。

未来展望

轻舟微服务平台未来会沿着双引擎多模式架构路线持续建设，主要包括：

● 垂直平台引擎之深耕：无侵入Agent服务治理、低门槛高性能服务网格等垂直方向持续深耕，继续夯实无侵入Agent、Sidecar的能力

● 水平业务模式之演进：多种治理模式平滑迁移覆盖更完整的业务场景，能力高度平台化，继续降低企业微服务架构演进的成本，保证平滑与稳定

● 与未来同行，历久弥新：深度整合多运行时、Spring Native等技术，保持架构先进性，持续为业务带来价值

参考资料

网易轻舟从微服务框架到服务网格架构平滑演进最佳实践（详见内文第4部分）

解读微服务的2020：框架在左网格在右，云原生时代的微服务路在何方

落地三年，两次架构升级，网易Service Mesh实践之路

云原生时代的流量入口：Envoy Gateway

作者简介

裴斐，网易数帆云计算技术专家、资深架构师。10余年企业级平台架构和开发经验，目前主要负责网易轻舟微服务治理团队，专注于企业微服务架构及云原生技术的研究与落地工作。带领团队完成网易轻舟Service Mesh、微服务框架NSF、API网关等多个项目在网易集团落地及商业化产品输出。