现代应用程序通常由大量微服务组成，这些微服务在本地和云中分布的容器中运行。在这种情况下，服务网格是解决这些分布式微服务的安全性、连接性和可观察性挑战的基础设施层。但是，额外的组件层（来自 Mesh 基础设施）拦截所有流量对延迟的影响又如何呢？
在本文中，对不同的 Service Mesh 性能进行了测量和评估。下图说明了一个基本的 Service Mesh 基础设施，代理拦截流量并应用一组配置的功能，例如路由、访问控制、可观察性、负载平衡。控制平面为网格中所有正在运行的代理提供策略和配置，并维护服务视图。随着规则或环境的变化，它会动态更新代理。
已经比较了基本服务网格配置，同时确保配置等效以使措施有意义。还使用了没有 Service Mesh 的基线。然后，添加了额外的 Service Mesh 功能，并且还测量了这些功能对性能的影响。已经评估了不同的服务网格：
代码库：https ://github.com/ELCAIT/service_mesh_performance
出于评估目的，我们使用 Spring Boot 开发了一个简单的 Java REST API 微服务：counter-api。
counter-api 微服务是一个简单的计数器：第一个响应是 0，并且这个数字在每个新请求时递增。响应采用 JSON 格式。
服务网格比较
不同的 Service Mesh 之间存在一些差异，并且不同的 Service Mesh 默认配置没有可比性。为了公平地比较解决方案，必须使用“接近等效”的配置：
- 重试和超时在 Service Mesh 中有不同的默认配置。为了公平对待没有 Service Mesh 的基线，这些功能已被禁用。
- Sidecar 请求的 CPU 和 RAM在 Service Mesh 中是不同的。通常，Service Mesh sidecar 代理 CPU 请求在 50 到 150 毫 CPU 之间。但是，CPU 限制（如果设置）可以从 325 毫 CPU (Linkerd) 到 2000 毫 CPU (Istio) 或根本没有限制 (Consul)。为了公平起见，CPU 限制已设置为 200 毫 CPU（可在此处、此处和此处获取配置）。 在基准测试期间，尚未达到此限制。
- 默认情况下，安全性和可观察性功能在服务网格之间配置为不同的级别和粒度。为了公平地比较地面差异， 禁用了 mTLS 和可观察性功能。
结论
当服务没有压力时（RPS < 500），Linkerd 通常被测量为最快的 Service Mesh。这可以在中位数延迟以及 99.9% 的百分位数中看到。这个结果是意料之中的，因为 Linkerd 在市场上已经被称为轻量级和快速的 Service Mesh。
关于以不轻量着称的 Istio，观察到非常好的延迟结果令人惊讶，尤其是在高 RPS 的情况下。Istio 的缺点是 CPU 消耗，它平均消耗的资源是其他资源的两到三倍。
关于 Consul，在RPS > 200 之前，结果与其他结果相似，因此延迟测量始终落后于其他结果。
总的来说，最有趣的结果是测试服务的低到中等负载 . 事实上，由于 Kubernetes 云集群提供了弹性和可扩展性，负载的增加不应该像基准测试那样使服务饱和。
据观察，Service Mesh 将中值延迟从 0.5[ms] 增加到 2[ms] 。但是，平均延迟影响不太显着；在RPS < 200的情况下，使用 Service Mesh 的平均延迟有时会更好。这个结果出乎意料，但可以通过 Service Mesh 的高效流量管理来解释——尤其是根据活动请求的最少数量选择服务实例的能力——这降低了当数量过多时不必要地使服务饱和的风险RPS 低。
激活不同的功能后，没有观察到延迟影响模式。
通过这一观察，Service Mesh 操作员可以自由地添加更多功能，而不会对延迟产生巨大影响。
只有启用了 Istio 的Open Policy Agent才会对延迟产生重大影响。由于 OPA策略决策点在 pod 的本地网络中添加了一个额外的跃点，因此该结果是意料之中的。
最后，Service Mesh 边车使用的资源是可以接受的。关于 Service Mesh 带来的特性，CPU/RAM 的消耗并不显着。
但是，如果 CPU 资源受到限制，人们可能不想选择 Istio。
测试细节点击标题