服务网格把微服务治理能力下沉到基础设施层，可独立降级，反对异构语言接入，是云原生体系下重要的微服务技术，被宽泛认为有较好的发展前景。
近几年，国内各大公司在大规模生产中落地服务网格，即构科技从 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对立业务服务框架。
即构在服务网格上还做了很多工作，比方混沌平台能够和管制立体和数据面对接，进行故障注入；反对服务网格近程调试，晋升开发人员的开发联调效率；反对服务网格全局限流及自适应熔断。
后续，即构在服务网格推广的过程中，会一直打磨欠缺平台能力，晋升服务网格的性能，更好的为业务服务！