服务网格（Service Mesh）被很多人认为是云原生时代继 Kubernetes 之后的下一件“大事”。 

自微服务架构诞生以来，服务间的通信就一直是业界首要攻克的难题之一。在传统的一体式架构中，各个模块之间可以通过应用内调用（进程间通信）完成交互。但在微服务架构下，各个模块以微服务的形式被拆分到了不同的进程甚至节点上，服务间通信只能使用复杂的 RPC 通讯，这也成为了微服务架构的一个性能瓶颈。 

2016 年，开源软件创业公司 Buoyant 推出针对微服务架构服务间通讯的解决方案 Linkerd，并首次提出了 Service Mesh 的概念。Service Mesh 的定位非常明确，就是用来处理服务与服务之间的通讯的云原生基础设施。 

很快，这种将原本“散落”的微服务重新整合分布到一张网状结构中，同时将服务间通信从业务层解耦的架构设计获得了业内的高度认可，各大云厂商也开始跟进这一技术。Service Mesh 框架 Linkerd 与服务代理项目 Envoy 先后纳入 CNCF 云原生生态版图，谷歌联合 IBM、Lyft 推出 Service Mesh 框架 Istio，Nginx 推出 Nginmesh，AWS 推出 App Mesh …… 

其中，背靠谷歌，在 Service Mesh 的基础上提供了诸如容错、金丝雀部署、A/B测试、监控等丰富功能的 Istio，在近年来的市场竞争中脱颖而出，成为市场份额最高的 Service Mesh 产品，大有成为“下一个 K8s”之势，并吸引了一些新的周边开源项目出现，如网易数帆旗下轻舟微服务团队近期开源的 Slime，就是一个基于 Istio 的智能网格管理器。

属于 Service Mesh 的云原生 2.0 时代是否已经到来？Istio 是否能复刻 K8s 的神话，一统 Service Mesh 天下？带着这些问题，我们邀请到了网易数帆轻舟事业部技术团队，这些来自云原生开发一线的网易工程师们为我们分享了他们眼中的 Service Mesh，以及相关技术在网易内部的落地实践。

什么是 Service Mesh?

Service Mesh 作为新一代微服务架构，采用 Sidecar（边车） 模式，实现了业务逻辑和微服务治理逻辑的物理解耦，降低微服务框架的开发与运维成本。

▲ 边车，Sidecar 一词十分形象地描述了 Service Mesh 的架构设计

从服务代理模式演进角度说，Service Mesh 架构的 Sidecar 模式是传统微服务架构下反向代理模式和 SDK 模式的自然演进，既解决了反向代理模式的集中式和单点故障问题，也解决了 SDK 模式的胖客户端和业务侵入问题，Sidecar 模式在效率、稳定性和性能等方面取了折中。 

当然，Sidecar 只负责网络通信，还需要有个组件来统一管理所有 Sidecar 的配置。在 Service Mesh 中，负责网络通信的部分叫数据平面（data plane），负责配置管理的部分叫控制平面（control plane）。数据平面和控制平面构成了 Service Mesh 的基本架构。 

传统微服务架构例如 Spring Cloud 实现服务治理的方式，通常是将服务治理与业务逻辑耦合在一起，部署、运维都耦合了微服务本身的操作。比如一个 RPC 框架的 bugfix 会引发所有微服务旷日长久的升级发布，同时带来业务开发人员开发、测试、回归、发布的巨大重复工作量。 

而 Service Mesh 通过将与业务逻辑无关的服务治理逻辑下沉，让业务开发人员与基础技术开发人员关注点分离，各司其职，大大提升了研发效能。结合网易数帆团队的体验，Service Mesh 的主要好处如下：

1. 与业务解耦，对业务代码无侵入
2. 具备跨语言特性
3. 提供了丰富的微服务服务治理功能
4. 可以解决中台架构下微服务化存在的问题

Service Mesh 在网易的落地实践

2017 年，网易严选业务首先开始落地 Service Mesh 架构。在技术选型方面，数据平面采用了 Nginx，控制平面及注册中心采用 Consul，Nginx 和 Consul Agent 形成 Sidecar。通过 Nginx 实现了负载均衡、环境路由、熔断降级和限流等服务东西向流量的管理，通过 Consul 实现了服务注册发现、配置同步、指令下发等控制面流量下发，服务对外调用的流量都通过本地部署的 Nginx，如下图：

基于 Nginx+Consul 的 Service Mesh 1.0 架构在支撑网易严选业务快速发展的过程中发挥了重要作用，不仅解耦了基础架构和业务服务化架构，使得他们能够独立演进，也提供了不改造即可接入服务治理能力，对齐了跨团队间对服务治理的理解，降低沟通协作成本，提升了业务团队生产力，到 2017 年底就基本上在严选全面落地了。随着严选规模变大以及业务进一步复杂，业务方对基础架构的诉求需要更灵活的流量调度、更多功能的服务治理、更大范围的基础组件解耦、更敏捷的快速迭代，更弹性的 IT 资源，之前架构存在一定不足，需要继续演进。

2019 年初，伴随以 Kubernetes、Envoy、Istio 为代表的云原生技术体系成熟，网易严选开始实施基于轻舟服务网格的 Service Mesh 2.0 架构。 

Service Mesh 2.0 最大的不同在于全面拥抱云原生技术。底座采用 Kubernetes，通过容器化和混合云基础设施解决快速迭代和 IT 资源弹性的问题。同时对基础组件做了升级，数据面组件采用 Envoy，控制面组件采用 Istio，如下图：

为什么选择了 Istio？

前面提到，市场上的 Service Mesh 框架还有很多，甚至还有堪称服务网格鼻祖并且已纳入 CNCF 版图的 Linkerd 项目，为什么如今最火的却是身为后来者的 Istio 呢？网易数帆团队结合他们当初的选型经验分享了自己的看法。 

首先，Istio 具有深厚的云原生背景及大厂背书。Istio 项目的主导者包括 Google、IBM、Lyft 等互联网巨头，Google 在 Kubernetes 项目及云原生领域的成功经历让 Istio 自诞生起就成为Service Mesh 领域的明星项目，再加上其本身设计的全面性与通用性，我们认为Istio有潜力成为 Service Mesh 标准架构选型。 

其次，Istio 的数据面选型 Envoy 是云原生数据面的事实标准。与“年轻”的 Service Mesh、Istio 不同，Envoy 作为 CNCF 第三个毕业的项目，具备非常丰富的网络代理能力与强劲的性能，在大规模生产环境历练多年。数据面组件在 Service Mesh 体系中承载了几乎全部核心流量，不容有失，而 Envoy 的强大、成熟与标准，能够很好的支撑 Istio 构建的 Service Mesh 体系。 

再次，Istio 足够流行。优秀的出身、全面的身手、通用的设计，Istio 项目一直都具备“流量”属性：Istio 在 Github 的 Star 数超过 2.5 万，还有超过 600 位全球贡献者，每三月一次的稳定发布节奏…… Istio 有着活跃的社区、足量的受众群体和稳定的发展轨迹，整体呈现出较强的生命力，这也使得企业选择Istio可以有更加长远和稳定的演进支撑。

最后，Istio 的发展方向是一切为了企业落地与易用。在 Istio 的发布版本进入 1.x 后，网易团队注意到几乎所有的新特性和优化都是为了企业的落地与易用。包括提升性能与稳定性的 MixerV2、WASM，控制面多组件 Pilot、Galley、Citadel 合并为 Istiod，明确了多集群能力、非容器能力，简化了安全模型，丰富了排障工具……一切的一切，都是为了企业更好的使用 Service Mesh 架构。

补足 Istio 短板的“史莱姆”

占得市场先机的 Istio，获得赞誉的同时也引来了不少非议。项目的优势自不必说，Istio 有着一套行之有效的上层抽象，通过配置 VirtualService，DestinationRule 等 CR 可以实现基本的流量管理，但是在面对本地限流，黑白名单，降级等微服务治理的高阶功能时，这套抽象显得力有不逮。

起初 Istio 给出的解决方案是 Mixer，将这些原本属于数据面的功能上升到 Mixer Adapter 中，虽然解决了功能扩展的问题，但其集中式的架构遭到了不少关注者对其性能的质疑。最终，Istio 自断其臂，弃用了 Mixer，使得高阶功能的扩展成为目前版本的空白。而向后展望，基于Envoy WASM 的 MixerV2 虽然解决了数据面扩展的问题，但是接口扩展仍是短板（需要通过通用接口 EnvoyFilter 下发配置）。基础平台能否形成百花齐放之生态的关键之一是其接口扩展性，正如 K8s 平台如果缺少 Operator，仅仅以靠原生接口无法实现服务自动部署，弹性伸缩等高阶服务编排功能，如果 Istio 框架想要成为流量管理领域的 K8s，也需要补齐其接口扩展能力。网易自研框架 Slime，正是对这一角色的一次尝试。 

当然脱离了实际功能的接口扩展无异于浮沙筑台，Slime 项目最开始的提出正是为了解决服务限流的问题。"业务方希望绕过 Mixer 组件实现自适应的服务级限流，于是我们提出了本地限流替代全局限流的方案，这个方案中我们第一次对 Istio 接口进行了扩展，扩展出的上层接口叫做 SmartLimiter，我们取了其中的字母 Slime 作为组件名称。后面基于 Slime 框架实现的模块会越来越多，其意义也不局限于限流了，更多的是想表达该框架灵活易扩展的特点，就像卡通形象史莱姆一样。"

正如网易团队所表示的那样，Slime 的定位是 Istio 的智能网格管理器，利用 Slime 框架，用户可以扩展出基于服务状态，实现动态，智能网格管理的模块。目前网易开源出来的 Slime 模块有三个：

配置懒加载： 自动按需加载配置/服务发现信息，解决了大规模场景下配置全量下发的性能问题

Http插件管理: 使用新的 CRD pluginmanager/envoyplugin 包装了可读性，可维护性差的 envoyfilter，更加便于 Istio 的插件和插件管理。

自适应限流: 实现了本地限流，同时可以结合监控信息自动调整限流策略，弥补了 Istio 在限流方面的短板。 

据悉，参与 Slime 项目研发的网易工程师中有多位 Istio 社区成员和 Envoy 社区成员，在 Slime 项目推出伊始，团队就与 Istio 社区进行了深入的沟通。“我们非常乐意将该项目回馈给 Istio 社区，希望能够帮助更多的服务网格使用者。”网易团队说。

下一个 K8s ?

背靠大厂，市场份额不断攀升，参与者众多，生态日趋完善……这样的 Istio 是否有望成为像 K8s 一样的云原生基础设施建设事实标准？ 

网易数帆轻舟业务部总经理陈谔表示，从应用场景来看，目前 Service Mesh 还是作为支撑微服务架构的基础设施，并不像 Kubernetes 那样能够广泛应用于对基础设施层的抽象。“我们的判断是当前的应用场景还不足以驱动 Service Mesh 领域出现能够类比 Kubernetes 的项目成为云原生的基础设施。然而 Service Mesh 向我们展示的是一种颠覆传统 RPC 模式的全新的应用层访问模式，有望像网络协议栈一样成为支撑应用分布式架构的标准，而当前 Istio 又是社区的引领者，我们对 Istio 成为比肩 Kubernetes 的云原生基础设施是充满期望的。”陈谔说。

作为云原生一线从业者，陈谔以自己的视角为我们分享了 Service Mesh 在国内的发展趋势，以及在 2021 年开发者需要关注的 Service Mesh 发展动向。 

如果技术人员希望推进 Service Mesh 的应用，首先建议关注与企业落地相关的工作，以轻舟团队的经验来看，Service Mesh 在企业成功落地需要关注平滑性，如：企业已有框架、注册中心的业务服务无缝接入；存量虚拟机/物理机部署的服务，与容器化服务一起纳管治理；支撑存量使用私有协议、异构语言实现的业务服务接入 Service Mesh。 

另一方面可关注如何支撑企业大规模落地。Service Mesh 在性能、稳定性方面需要更好的优化、支撑：复杂的生产环境配置处理的综合性能提升；Service Mesh 系统的韧性以及极端情况整体故障兜底能力等。 

另外建议开发者关注 Istio 社区周边生态的发展，尤其是能够提升 Service Mesh 易用性、可维护性的工作。 

最后是社区 roadmap 中的重点能力也值得关注，如 Service Mesh 跨多 Kubernetes 集群跨网络平面，解决故障域隔离、区域路由优先之类的问题；虚机工作负载支持和完善；Envoy 上WASM 机制完善，多语言插件开发的真正落地等。

虽然把 Istio 当成“下一个 K8s”为时尚早，但 Service Mesh 架构蕴藏的巨大潜力已经在众多厂商的落地实践中得到了验证，发展前景非常乐观，值得云原生开发者持续关注。