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