共计 2631 个字符，预计需要花费 7 分钟才能阅读完成。
作者：张添翼 (澄潭)
为了防止混同，咱们先对一些要害定义做一些厘清：
- 传统网关：未作容器化革新，未启用 K8s，通过流量网关与业务网关两层网关来构建，流量网关提供全局性的、与后端业务无关的策略配置，例如 Tengine 就是典型的流量网关；业务网关提供独立业务域级别的、与后端业务紧耦合策略配置，随着利用架构模式从单体演进到当初的散布式微服务，业务网关也有了新的叫法 – 微服务网关。
- K8s 网关：即云原生网关，也被称为下一代网关，Ingress 成为 K8s 生态的网关规范，促使流量网关和业务网关，合二为一。基于 Ingress 标准的实现次要分为基于 Nginx 和基于 Envoy 两大阵营，基于 Nginx 的 Nginx Ingress Controller 是目前大多数 K8s 集群的抉择，基于 Envoy 的实现作为后起之秀，大有赶超之势。
- MSE 云原生网关：是基于 Envoy，做了深度优化的云上服务。
本文将从性能和老本、可靠性、安全性 3 方面，对两大开源实现进行比对，心愿对正在做 K8s 网关选型的企业有所借鉴。
性能和老本
MSE 云原生网关的吞吐性能简直是 Nginx Ingress Controller 的一倍，尤其是传输小文本时性能劣势会更显著，如下图所示，网关 CPU 使用率达到 30% 时的吞吐比照：
网关规格：16 核 32 G * 4 节点
ECS 型号：ecs.c7.8xlarge
当 CPU 负载升高时，吞吐差距会更加显著，下图是 CPU 使用率达到 70% 时的状况：
高负载下 Nginx Ingress Controller 吞吐降落起因是呈现了 pod 重启，详情见下一节“可靠性”中的剖析。
随着网络安全更加受器重，当初互联网上曾经广泛应用 HTTPS 进行传输加密，在网关侧，用于实现 HTTPS 的 TLS 非对称加密算法是占用 CPU 资源的大头。针对此场景，MSE 云原生网关应用了 CPU SIMD 技术实现了 TLS 加解密算法的硬件加速：
从上图压测数据能够看出应用 TLS 硬件加速后，相比一般 HTTPS 申请 TLS 握手时延升高一倍，极限 QPS 晋升 80% 以上。
基于以上数据，应用 MSE 云原生网关，只需一半的资源，就能达到 Nginx Ingress Controller 的吞吐，在做过硬件加速优化的 HTTPS 场景下，吞吐还能进一步晋升。
可靠性
前文提到高负载下，Nginx Ingress Controller 会呈现 pod 重启导致吞吐降落，导致 pod 重启的起因次要有 2 点：
- 存活健康检查（livenessProbe）在高负载时容易超时失败，社区在 0.34 版本通过缩小冗余检测进行了肯定的优化，但问题依然存在。
- 在开启了 prometheus 采集监控指标的状况下，高负载时会呈现 OOM，导致容器被 kill，具体起因见相干 issue：https://github.com/kubernetes…
这两个问题，实质上皆是因为 Nginx Ingress Controller 的部署架构不合理导致。其管制面（Go 实现的 Controller）和数据面（Nginx）过程混跑在一个容器内，高负载下，数据面过程和管制面过程呈现了 CPU 抢占。其中管制面过程负责了健康检查和监控指标采集，因为没有足够的 CPU 导致申请积压引起 OOM 以及健康检查超时。
这种状况是极危险的，会在高负载下引发网关的雪崩效应，对业务造成重大影响。MSE 云原生网关应用了数据面和管制面隔离的架构，在架构上具备可靠性劣势：
从上图能够看到，MSE 云原生网关并不部署在用户的 K8s 集群中，而是纯托管的模式，这种模式在可靠性上还有更多劣势：
- 不会与业务容器混跑在一个 ECS 节点上
- 网关的多个实例不会混跑在一个 ECS 节点上
- 提供网关可用性的 SLA 保障
如果应用 Nginx Ingress Controller 要实现高牢靠部署，个别须要独占 ECS 节点，同时还须要部署多个 ECS 节点，来防止单点故障，这种状况下资源老本会直线回升。此外，Nginx Ingress Controller 因为部署在用户集群中，也无奈提供网关可用性的 SLA 保障。
安全性
Nginx Ingress Controller 的不同版本都还存在着一些 CVE 破绽隐患，具体影响版本见下表：
从 Nginx Ingress Controller 迁徙到 MSE 云原生网关后，将一次性修复所有 CVE 破绽隐患；并且，MSE 云原生网关提供了平滑降级计划，一旦呈现新的安全漏洞，能够疾速对网关版本进行降级，同时确保降级过程对业务影响最小化。
此外，MSE 云原生网关内置了阿里云 Web 利用防火墙（WAF），相比传统 WAF 用户申请链路更短、RT 更低，且相比 Nginx Ingress Controller 能够做到细粒度路由级防护，应用老本是目前阿里云 Web 利用防火墙架构的 2/3。
MSE 云原生网关
阿里云容器服务利用市场曾经上架 MSE 云原生网关，可用于代替默认装置的网关组件 Nginx Ingress Controller。
MSE 云原生网关在阿里团体外部作为网关中间件曾经大规模应用，其强劲的性能和牢靠的稳定性已被多年双十一流量所验证。
在 K8s 容器服务场景下，比照默认装置的 Nginx Ingress Controller，次要有以下劣势：
- 更强劲的性能，更正当的架构，能够将网关资源老本升高至多 50%
- 更好的可靠性和 SLA 保障，纯托管免运维，背靠阿里云技术团队提供反对
- 更优的安全性保障，一次性解决现存 CVE 安全漏洞隐患，且内置 WAF 防护性能
同时在路由策略、灰度治理、可观测等方面提供了更丰盛的性能，并且反对应用多种语言开发自定义的扩大插件，具体比照请参考：https://help.aliyun.com/docum…
平滑迁徙计划
部署 MSE 云原生网关并不间接影响原有网关流量，通过 DNS 权重配置能够实现业务流量的平滑迁徙，对后端业务齐全无感知，外围的流量迁徙过程如下图所示：
残缺步骤如下：
- 步骤一：在容器服务的利用市场中找到 mse-ingress-controller，并装置到指标 ACK 集群
- 步骤二：在 K8s 中配置 MseIngressConfig（配置指引），主动创立指定规格的 MSE 云原生网关
- 步骤三：从 Ingress 的 address 字段中获取 MSE 云原生网关的 IP，本地绑定 host，将业务域名解析到该 IP，实现业务测试
- 步骤四：批改业务域名的 DNS 权重配置，增加云原生网关 IP，并逐渐调高权重，进行流量灰度
- 步骤五：实现灰度后，将业务域名原先的 IP 从 DNS 配置中移除，实现全副流量切到云原生网关
点击此处，理解更多云原生网关产品信息~
