服务网格把微服务治理能力下沉到基础设施层，可独立升级，支持异构语言接入，是云原生体系下重要的微服务技术，被广泛认为有较好的发展前景。

近几年，国内各大公司在大规模生产中落地服务网格，即构科技从 2021 年初开始也在进行服务网格的预研工作，通过对服务网格技术的深入研究和实践，与 2022 年 1 月份在一个业务场景中正式落地，目前在逐步推广中。

那么服务网格究竟是什么，它的性能如何？即构在服务网格落地的过程中又有哪些探索与实践？本篇文章为您详细解读！

一、服务网格的由来

微服务 A 调用微服务 B，当服务 B 的响应速度突然变得很慢时，如果防止把服务 A 拖垮？

当服务 A 有突发流量时，如何不把服务 B 打垮？

服务 A 处理一个服务请求用了多长时间，是否可查看整个微服务的往返时延、成功率？

如何抵御中间人攻击及如何审计谁在什么时候做了什么事情？

以上问题均涉及到微服务的流量管理、安全、可观测性。如果在每个服务中去建立这些功能，则会出现各业务团队重复建设、开发效率低等问题。

所以我们可以把以上这些功能封装为 SDK，由负责微服务框架的团队来进行维护，使业务团队只需要关注业务本身，这样就可以解放程序员的创造性，提升开发效率。

但封装为 SDK 时会面临两个问题：

问题一：SDK 如何快速升级。由于业务侧引用了 SDK，SDK 升级需要业务侧配合，这样会导致多版本 SDK 需要长期并存使用的情况；

问题二：异构语言如何接入。随着业务的发展，公司的开发人员往往会使用多语言进行开发。例如一家以 Java 语言做为主流语言的公司，在收购了一家使用 C++ 语言做为主流语言开发的公司后，就很难统一微服务治理框架。

图 1：在 SDK 中提供流量管理、安全、可观测功能

服务网格技术通常采用轻量级网络代理的形式来实现，网络代理可独立升级，支持任意开发语言接入，让开发者可以更加专注于业务逻辑，加快服务交付。

图 2： 在代理中提供流量管理、安全、可观测功能二、什么是 Istio

业界有很多开源的服务网格框架，例如 Istio、linkerd2、kuma、nginMesh、maesh 等，Istio 是目前在国内最流行的服务网格框架。

下面我们一起来看下 Istio 的架构：

图 3：Istio 架构图

从上图我们可以看出，Istio 服务网格从逻辑上分为数据平面（Data plane）和控制平面（Control plane）：

数据平面（Data plane）：直接处理入站和出站数据包，提供转发、路由、健康检查、负载均衡、熔断、认证、鉴权、故障注入、可观测能力。

控制平面（Control plane）：提供服务发现、配置和证书管理能力。

在构建大型分布式系统的时候，将控制面和数据面分离开是一种常见的模式。数据面会直接和具体的应用交互，而控制面的组件会下发一系列的配置和指令，帮助数据面完成具体的工作。

三、Istio 的性能

使用两台阿里云 ecs.g6.2xlarge 机器，其中一台部署压测工具 Fortio，另外一台部署 Service A 和 Service A 的边车。在使用 fannel 网格插件的情况下，用 30 并发进行压测，压测场景如下图所示，其中 Service A 接收到请求不做任何逻辑处理直接返回，Fortios 通过边车调用 Service A 的平均响应时间为 2.505ms。在同样的并发下，不部署 Service A 的边车，通过 Fortios 调用 Service A 的平均响应时间为 0.936ms。

图 4：有边车压测场景图片:

图 5：无边车压测场景

图 6：平均延时

图 7：qps

服务网格带来的性能损耗包含两个方面：

1、流量策略、可观察性和安全通信带来的损耗，这些损耗是任何微服务框架均存在的，需要不断优化 Envoy 本身的性能来提升。

2、服务网格微服务之间的调用经过边车后，与传统服务框架相比，多了两次网络调用，这是服务网格额外带来的性能损耗。

服务网格默认采用的是 iptables 流量劫持的方式，流量经过边车 Envoy 时，会经过两次 TCP/IP 协议栈，图 8 所示，当服务数量大的时候会有大量的 iptables 规则，影响网络性能。目前业界的一个思路是使用 eBPF 这样的技术来提高应用性能，基于 eBPF 使微服务跟边车直接通过 Socket 通讯，但是该技术对操作系统内核的版本要求比较高，因此很少有企业能够达到。

图 8：调用链路

微服务跟边车之间纯粹的网络通讯带来的延时为微秒级，在业务对延时没有那么敏感的情况下，可更多关注 Istio 可独立升级、语言无关的特性。

四、Istio 在即构的探索和实践

在服务网格技术选型上，即构选择了国内最流行的服务网格开源实现 Istio。下面向大家讲解一下即构在 Istio 落地过程中的探索与实践。

1、服务网格管理台建设

Istio 限流、熔断等 yaml 配置较为复杂，如果让业务同学直接操作 yaml，需要全部理解透 Istio 的配置，学习成本高，而且容易配置错误。我们开发了一个平台，通过引导式的界面操作，让业务同学更方便的使用限流、熔断、负载均衡、超时重试的个性化配置能力。

图 9：选择服务引导页

图 10：添加熔断配置页

2、Thin SDK

前面提到的【服务网格】就是把流量管理、安全和可观测性能力下沉到基础设施中，从而实现让业务多语种皆拥有微服务治理能力，且不再需要业务侧频繁配合 SDK 升级。那么是否就意味着从此不再需要在微服务中引入 SDK 了呢？

微服务中的日志打印、报文头信息传递、网络通讯（如暴露 http 服务，调用 http 服务）能力都是轻量级的公共能力，也是无法完全下沉到基础设施层的能力，这些能力较为稳定，一般不需要升级改动，可封装为 Thin SDK 给业务使用。

3、配置部分加载性能调优

Istio 默认将整个网格内所有服务的路由信息全量下发到所有的边车，服务数量过多时，会导致 Envoy 配置量太大、Envoy 内存占用过高、新上的应用长时间处于 Not Ready 状态等问题。目前腾讯云开源的 Aeraki、网易开源的 Slime 都实现了配置懒加载，其原理为在系统运行时监控服务调用关系，动态生成 sidecar scope 来防止配置全量下发。

我们通过 thin SDK 进行约束，要求服务网格中调用方的应用把所调用的服务方域名维护在应用的配置文件中，在 DevOps 过程中读取配置文件中的调用关系，根据调用关系自动生成 sidecar 配置文件，并把 sidecar 配置应用到服务网格中。

由于不需要在运行时动态产生 sidecar scope，相对配置懒加载设计上简单很多，性能更高。

4、容器支持多测试环境共享

通过报文头中携带的测试环境信息（此报文头信息会全链路携带）进行测试环境的选择，有相应项目环境的服务则优先走该环境服务，没有则默认走稳定版本测试环境服务，从而防止任意项目环境皆需要部署全套服务，节省测试资源。

例如，某个项目改动了服务 A 和服务 C，没有改动服务 B，把服务 A 和服务 C 部署在项目测试环境 1。如图 11 黄色箭头所示调用链路，当从项目测试环境 1 发出请求时，由于服务 B 没有项目测试环境 1，这时请求会导流到稳定测试环境，当服务 B 调用服务 C 时，由于服务 C 有项目测试环境 1，这时会导流到项目测试环境 1。

图 11：多测试环境调用关系

5、通过 wasm 进行 Envoy 的扩展即构在几个业务需求场景（自适应熔断等）通过 Wasm 插件来实现 Envoy 的扩展， Istio 1.12 也引入 Wasm 插件配置 API 用于扩展 Istio 生态，Wasm 性能我们也在持续关注。为什么没有选择 Lua 来扩展或用 C++ 编写过滤器集成到 Envoy 的源代码中来扩展呢？总结下来有如下几点：

1）Lua 环境都是针对工作线程的，这意味着没有真正的全局数据，只能做到工作线程维度的熔断，无法做到工作负载维度的熔断。Wasm 支持不同工作线程间共享数据。

2）C++ 编写过滤器集成到 Envoy 的源代码中，并编译新的 Envoy 版本，这种方法需要维护 Envoy 版本，并不断使期与官方发行版保持同步，且每次更新过滤器都需要重新编译部署。Wasm 可以动态加载到正在运行的 Envoy 进程中，且支持多种流程的编程语言。

3）Wasm 插件一直是 Istio 的一个重点项目，发展速度快，前景美好。

图 12：wasm 插件机制

五、总结和展望

即构在服务网格的接入过程中，充分利用了服务网格的流量治理能力来做多测试环境隔离、金丝雀发布、熔断、限流；利用服务网格的可观测能力来做链路追踪、监控告警；利用 Thin sdk 统一业务服务框架。

即构在服务网格上还做了很多工作，比如混沌平台可以和控制平面和数据面对接，进行故障注入；支持服务网格远程调试，提升开发人员的开发联调效率；支持服务网格全局限流及自适应熔断。

后续，即构在服务网格推广的过程中，会不断打磨完善平台能力，提升服务网格的性能，更好的为业务服务！