Istio为应用部署增加了很多功能，包括流量策略、可观察性和安全通信。但是，强行在集群中添加Istio是有代价的。虽然Istio 基准性能测试提供了在实验环境下Istio的极限性能，但是为了判断Istio是否适合您的情况并做出明智的决定，我们认为使用广泛落地实践的典型电商业务场景进行的性能测试显得更为重要。
为了模仿真实的业务场景，我们挑选了mall-swarm项目作为性能测试基准项目。
mall-swarm项目是mall项目的微服务化版本，是一套比较典型的电商系统，包括前台商城系统及后台管理系统，基于SpringBoot+MyBatis实现，采用Docker容器化部署，Github star 47.7k。
Istio选择1.6版本，并使用SolarMesh进行安装。SolarMesh是一款基于Istio的云原生流量监管平台，不仅提供应用网络观测能力，还有方便快捷的策略配置、安全可靠的Istio使用体验。同时，使用SolarMesh能快速安装Istio，并且在后续不断接入或移除Sidecar做对比试验的时候起到重要的作用。
首先准备1个K8s集群共有4个节点：
- 1个master
- 3个node
NAME STATUS ROLES AGE VERSION 10.10.13.34 Ready,SchedulingDisabled master 280d v1.15.0 10.10.13.35 Ready node 280d v1.15.0 10.10.13.36 Ready node 280d v1.15.0 10.10.13.37 Ready node 280d v1.15.0
每个节点的机器的主要配置如下：
- CPU: 4核 Intel® Xeon® CPU E5-2690 v2 @ 3.00GHz
- 内存: 8G
istio强依赖于kubernetes，云原生级服务更有利于istio的功能施展，先将mall-swarm项目改造成云原生微服务，也就是所有组件都部署到kubernetes的环境中。
$ kubectl get po -n mall NAME READY STATUS RESTARTS AGE elasticsearch-77d9b98ff6-t8xbq 1/1 Running 0 44h mall-admin-deployment-758dcf6-4dqg4 1/1 Running 0 44h mall-admin-web-686f5457bf-ltdgp 1/1 Running 0 44h mall-auth-deployment-d6fcff7f6-crqdr 1/1 Running 0 44h mall-gateway-deployment-945d96bf5-gmjh8 1/1 Running 0 44h mall-monitor-deployment-868dd95495-pwtsc 1/1 Running 0 44h mall-mysql-5bc5d5cf68-k5klr 1/1 Running 0 44h mall-portal-deployment-699b6858cd-bwdm7 1/1 Running 0 44h mall-search-deployment-5bc4cd9b5b-glk2f 1/1 Running 0 44h mongodb-6d57cbb84b-d66vr 1/1 Running 0 44h rabbitmq-768fd8c669-rk67t 1/1 Running 0 44h redis-5b95b8c54b-l4l8w 1/1 Running 0 44h # 为了方便暴露了一些nodeport端口 $ kubectl get svc -n mall NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE elasticsearch ClusterIP 10.70.152.1679200/TCP,9300/TCP 44h mall-admin ClusterIP 10.70.96.35 8080/TCP 44h mall-admin-web NodePort 10.70.44.19 8080:23399/TCP 44h mall-auth ClusterIP 10.70.60.16 8401/TCP 44h mall-gateway NodePort 10.70.154.213 8201:30201/TCP 44h mall-monitor ClusterIP 10.70.61.157 8101/TCP 44h mall-mysql NodePort 10.70.74.117 3306:33066/TCP 44h mall-portal ClusterIP 10.70.139.253 8085/TCP 44h mall-search ClusterIP 10.70.160.135 8081/TCP 44h mongodb ClusterIP 10.70.58.47 27017/TCP 44h rabbitmq ClusterIP 10.70.111.169 15672/TCP,5672/TCP 44h redis ClusterIP 10.70.194.34 6379/TCP 44h
工具与方法
测试工具选用jmeter。此次主要的验证为：在高并发(一定会超出极限)的场景下，有无istio对服务的影响。所以选择 200QPS 持续120s 的请求，分五次验证取平均的做法，对mall-swarm项目的商品推荐接口进行压力测试。
测试
未接入sidecar：
开始前pod的指标
CPU: 21m
内存: 1843Mi
CPU使用峰值平均数是 1609.2m 成功响应的平均时间为1169.2ms 平均error率是32.1%。
接入Sidecar
SolarMesh提供了Namespace级别的自动注入能力，只需要在SolarMesh的页面上开启自动注入就可以了。
开启自动注入之后，Sidecar将自动注入到指定Namespace下的所有Pod中。
$ kubectl get po -n mall NAME READY STATUS RESTARTS AGE elasticsearch-77d9b98ff6-t8xbq 2/2 Running 0 47h mall-admin-deployment-758dcf6-4dqg4 2/2 Running 0 47h mall-admin-web-686f5457bf-ltdgp 2/2 Running 0 47h mall-auth-deployment-d6fcff7f6-crqdr 2/2 Running 0 47h mall-gateway-deployment-945d96bf5-gmjh8 2/2 Running 0 47h mall-monitor-deployment-868dd95495-pwtsc 2/2 Running 0 47h mall-mysql-5bc5d5cf68-k5klr 2/2 Running 0 47h mall-portal-deployment-699b6858cd-bwdm7 2/2 Running 0 47h mall-search-deployment-5bc4cd9b5b-glk2f 2/2 Running 0 47h mongodb-6d57cbb84b-d66vr 2/2 Running 0 47h rabbitmq-768fd8c669-rk67t 2/2 Running 0 47h redis-5b95b8c54b-l4l8w 2/2 Running 0 47h
开始前Pod的指标 CPU: 30m 内存: 1869Mi
CPU使用峰值平均数是 1769.4m 成功响应的平均时间为1394.9ms 平均error率是9.4%。
总结
通过对比有无Sidecar的实际情况数据，我们可以发现：
在高并发压力测试的结果中，接入Sidecar的服务CPU使用相比没有接入Sidecar的服务有10%的CPU使用增长。
接入Sidecar的服务接口平均响应时间相比没有接入Sidecar的服务接口大约有19.3%的性能损失。
在没有Sidecar接入的情况下，接口出现高达32.1%的error率，在有Sidecar接入的情况下，这种error率被显著降低到9.4%。
综上所述，使用了Istio的服务确实会出现一些性能上的损耗，但是Sidecar一定程度下会保护接口，免于在高压环境下因Tomcat无法承受而大量地抛弃请求。而且此次测试是单机验证(每个服务只有一个replica)，使用标准的Istio，如果采取一些调优方案，或许还会有一个比较大的改善空间。
