出口网关性能调查

验证添加出口网关对性能的影响。

2019年1月31日 | 作者：Jose Nativio，IBM

本次调查的主要目标是确定在服务网格中添加出口网关以访问外部服务（在本例中为 MongoDB）时对性能和资源利用率的影响。在博客使用外部 MongoDB 服务中描述了为外部 MongoDB 配置出口网关的步骤。

用于本次调查的应用程序是 Acmeair 的 Java 版本，它模拟航空预订系统。此应用程序用于 Istio 每日构建的性能回归巡逻，但在该设置中，微服务已通过其 sidecar 直接访问外部 MongoDB，而无需出口网关。

下图说明了回归巡逻目前如何与 Acmeair 和 Istio 一起运行

另一个区别是应用程序使用纯 MongoDB 协议与外部数据库通信。本研究进行的第一个更改是在 MongoDB 及其在应用程序中运行的客户端之间建立 TLS 通信，因为这是一种更现实的场景。

测试并描述了从网格访问外部数据库的几种情况。

出口流量案例

在这种情况下，sidecar 不会拦截应用程序和外部数据库之间的通信。这是通过使用 MongoDB 的 CIDR 设置 init 容器参数 -x 来实现的，这使得 sidecar 忽略到/来自此 IP 地址的消息。例如

    - -x
    - "169.47.232.211/32"

当 sidecar 注入到应用程序 pod 中时，这是默认配置。所有消息都由 sidecar 拦截，并根据配置的规则路由到目标，包括与外部服务的通信。MongoDB 被定义为一个ServiceEntry。

为访问 MongoDB 定义了出口网关以及相应的目标规则和虚拟服务资源。所有到/来自外部数据库的流量都通过出口网关（envoy）进行。

在这种情况下，sidecar 和网关之间存在额外的安全层，因此预计性能会受到一些影响。

此场景用于评估需要另一个代理来访问通配符域的情况。由于 envoy 的当前限制，这可能是必需的。在出口网关 pod 中创建了一个 nginx 代理作为 sidecar。

Jmeter 用于生成工作负载，该工作负载包括一系列 5 分钟的运行，每次运行使用越来越多的客户端发出 http 请求。使用的客户端数量为 1、5、10、20、30、40、50 和 60。

下图显示了不同情况下获得的吞吐量

如您所见，在应用程序和外部 MongoDB 之间存在 sidecar 和出口网关不会造成重大影响，但启用双向 TLS 然后添加 SNI 代理会导致吞吐量分别下降约 10% 和 24%。

在使用 20 个客户端驱动流量时，收集了不同请求的平均响应时间。下图显示了每种情况下平均值、中位数、90%、95% 和 99% 的平均值

同样，前 3 种情况的响应时间差别不大，但双向 TLS 和额外的代理会增加明显的延迟。

在运行期间，收集了所有 Istio 组件以及 sidecar 的 CPU 使用情况。为了进行公平的比较，Istio 使用的 CPU 通过给定运行获得的吞吐量进行了归一化。结果显示在下图中

就每个事务的 CPU 消耗而言，Istio 仅在出口网关 + SNI 代理的情况下使用了更多的 CPU。

在本调查中，我们尝试了不同的选项来访问启用了 TLS 的外部 MongoDB 以比较其性能。出口网关的引入对性能没有重大影响，也没有明显的额外 CPU 消耗。只有在启用 sidecar 和出口网关之间的双向 TLS 或使用额外的 SNI 代理用于通配符域时，我们才能观察到一些性能下降。