基于龙蜥操作系统指令加速，降低云原生网关的构建成本

技术背景

网络信息传输的可靠性、机密性和完整性要求日渐提升，HTTPS 协议已经广泛应用。HTTPS 的 SSL/TLS 协议涉及加解密、校验、签名等密码学计算，消耗较多 CPU 计算资源。因此 CPU 硬件厂商推出过多种加速卸载方案，如 AES-NI，QAT，KAE，ARMv8 安全扩展等。

业界软件生态在优化 HTTPS 的性能上也做了诸多探索（参考[1]），传统的软件优化方案有 Session 复用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS 等, 但软件层面的优化无法满足流量日益增长的速度，CPU 硬件加速成为业界一个通用的解决方案。

CPU 新特性

不久前发布的第三代英特尔® 至强® 可扩展处理器（代号 Ice Lake），单核性能提升 30%，整机算力提升 50% 以上（参考[9]）。

ISA 指令集

在传统的 AES-NI 加速指令基础上，Ice Lake 新增了基于 Intel® Advanced Vector Extensions 512（Intel® AVX-512）的 Intel® Crypto Acceleration 特性，包括 Vector AES（VAES）、Integer Fused Multiply Add（IFMA 大数计算）、Galois Field New Instructions（GFNI）等（参考[2]）。同时也补充支持了 SHA extension(SHA-NI)，补足了上一代的 SHA256 性能短板。

title=

图 1 Ice Lake 新增 Intel AVX512 指令集

Multi-buffer

Multi-buffer 是一种集中批量请求进行并发处理的技术（参考[10]）。应用软件通过异步 SSL 配合 multi-buffer library 使用 SIMD 向量指令（AVX/AVX2/AVX512）加速密码学计算。OpenSSL (BabaSSL，BoringSSL)，Nginx (Tengine)，DPDK Cryptodev，dm-crypt, ISA-L 等开源软件生态已部分支持。

title=

图 2 Multi-buffer 配合 SIMD 加速

龙蜥操作系统

阿里云操作系统通过龙蜥社区和 Intel 工程师合作（参考[2]），率先支持云上 Ice Lake CPU，输出了最新的指令加速特性（参考[10]）。Ice Lake 单核 AES 性能加速 2.2 倍，达到上一代 Cascade Lake 的 3.4 倍。RSA 单核加速 4.9 倍，达到上一代的 5.1 倍。Tengine (Nginx)单核 SSL/TLS 握手性能相应地加速 3.1 倍，达到上一代的 3.2 倍。

title=

图 3 系统 OpenSSL 基础性能

title=

图 4 端到端应用HTTPS TLS短连接性能（左图 Tengine、右图 Nginx）

加速软件栈

受益于以往的 QAT 方案，OpenSSL，Nginx (Tengine)，DPDK，Envoy 等主流软件已经支持 SSL/TLS 加速。Intel® Crypto Acceleration方案沿用和扩展了 QAT 的软件框架 QAT Engine（参考[2]），使之从专用的硬件加速卡场景扩展到了通用的 CPU 指令加速场景，极大扩展了适用范围。

title=

图 5 Intel SSL/TLS 加速软件栈

Tengine 加速方案

阿里统一接入网关 Tengine 承担着集团所有的入口流量（参考[1]），随着 HTTPS 化的全面推进，对于网关的性能挑战也非常大。业务驱动了技术创新，2017 年接入网关在硬件加速领域也迈出了第一步，开始尝试 QAT 卡硬件加速方案。在经历 Tengine QAT 的探索实践后，阿里云推出了基于开源 Envoy 构建的 MSE 云原生网关产品（参考[5]）。

Tengine 从 2.2.2 版本开始支持 async SSL，支持 QAT 加速 SSL/TLS（参考[3]），支持的底层 lib 版本为：OpenSSL-1.1.0f 和 QAT_Engine-0.5.30（参考[4]）。龙蜥 OS 引入 CPU 加速后升级到：OpenSSL-1.1.1g 和 QAT_Engine-0.6.6，不需要 QAT 驱动和 qatlib。

云原生网关演进

阿里巴巴在 2018 年，开启了云原生上云的序幕，将容器、服务网格作为核心技术点进行演进，并尝试阿里巴巴和蚂蚁通过这次技术演进，来统一双方的中间件技术栈，让业务更聚焦业务开发，屏蔽底层分布式复杂度。作为服务网格一个重要方向，我们开启了下一代网关的探索之路。

传统网关

传统网关通过流量网关与业务网关两层网关来构建（参考[1]），流量网关提供全局性的、与后端业务无关的策略配置，例如 Tengine 就是典型的流量网关；业务网关提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关。

title=

图 6 传统网关

MSE 云原生网关

在容器技术与 K8s 主导的云原生时代，下一代的网关模式仍然会是传统的流量网关与微服务网关的两层架构吗？带着这个问题，并结合阿里巴巴内部沉淀的网关技术与运维经验，我们尝试来回答下，什么是下一代网关。

title=

图 7 下一代网关的产品画像

我们对其中几个非常核心的要素展开说明下：

云原生：要支持标准 K8s Ingress、K8s Gateway API 以及 K8s 服务发现，在云原生时代，K8s 已经成为云 OS，而 K8s 原生集群内外部的网络是隔离的，负责外部流量进入，K8s 集群的规范定义就是 K8s Ingress，K8s Gateway API 是 K8s Ingress 的进一步演化，基于此，作为下一代网关，势必要支持这种特性。

拥抱开源：要基于开源生态构建网关，借助开源并助力开源，相信这点大家应该都不陌生。

高扩展：任何一个网关的能力都不可能覆盖所有的用户诉求，要具备可扩展能力，例如 K8s 的蓬勃发展其开放的扩展能力功不可没。

服务治理：随着应用架构演进到分布式微服务，网关本身就是为后端业务提供流量调度能力，其支持基本的服务治理能力也就顺其自然了。

丰富的可观测性：分布式微服务架构带来协同效率提升等益处的同时，对于问题排查及运维带来了更大的挑战，作为流量桥头堡的网关需要具备丰富的可观测数据，帮助用户来定位问题。

基于以上的分析和实践，我们认为在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。

MSE 云原生网关将流量网关与微服务网关（Ingress）二合一，通过硬件加速、内核调优等手段在性能不打折的情况下，用户部署网关的资源成本直降 50%。

title=

图 8 云原生网关

MSE 云原生网关优势：

网关直连业务 Pod IP，不经过传统 Cluster IP，RT 更低。
支持 HTTPS 硬件加速，QPS 提升 80%。
支持 Wasm 插件市场，插件热加载，满足用户多语言自定义插件诉求。
自研 Multi-Ingress Controller 组件支持多集群 Ingress 复用同一个网关实例。
原生兼容原生 K8s Ingress 规范，且支持 Nginx Ingress 核心功能注解的无缝转换。

title=

图 9 云原生网关技术架构

客户案例分享

上海费芮网络科技有限公司之前一直使用 Nginx Ingress，使用过程中遇到运维成本高、安全差、原生功能弱等痛点，期望能够找到一款替代产品；在接触 MSE 云原生网关后，在上线前的测试过程中对于 HTTPS 硬件加速功能非常认可，测试验证开启后的加速效果非常明显；结合网关提供的 Nginx Ingress 注解兼容功能 + HTTPS 硬件加速两个差异功能，用户最终选择使用 MSE 云原生网关来替代 Nginx Ingress 网关。

title=