效能提升1倍，成本直降50%！基於龍蜥指令加速的下一代雲原生閘道器

文 / Intel Arch SIG

技術背景

網路資訊傳輸的可靠性、機密性和完整性要求日漸提升，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 效能短板。

（圖 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 等開源軟體生態已部分支援。

（圖 2/ Multi-buffer 配合 SIMD 加速）

龍蜥作業系統（Anolis OS）

阿里雲作業系統透過龍蜥社群和 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 倍。

（圖 3/系統 OpenSSL 基礎效能）

（圖 4/端到端應用HTTPS TLS短連線效能（左圖 Tengine、右圖 Nginx））

加速軟體棧

受益於以往的 QAT 方案，OpenSSL、Nginx (Tengine)、DPDK、Envoy 等主流軟體已經支援 SSL/TLS 加速。Intel®Crypto Acceleration 方案沿用和擴充套件了 QAT 的軟體框架 QAT Engine（參考[2]），使之從專用的硬體加速卡場景擴充套件到了通用的 CPU 指令加速場景，極大擴充套件了適用範圍。

（圖 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 就是典型的流量閘道器；業務閘道器提供獨立業務域級別的、與後端業務緊耦合策略配置，隨著應用架構模式從單體演進到現在的分散式微服務，業務閘道器也有了新的叫法 - 微服務閘道器。

（圖 6/傳統閘道器）

MSE 雲原生閘道器

在容器技術與 K8s 主導的雲原生時代，下一代的閘道器模式仍然會是傳統的流量閘道器與微服務閘道器的兩層架構嗎？帶著這個問題，並結合阿里巴巴內部沉澱的閘道器技術與運維經驗，我們嘗試來回答下，什麼是下一代閘道器。

（圖 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%。

（圖 8/雲原生閘道器）

MSE 雲原生閘道器優勢：

• 閘道器直連業務 Pod IP，不經過傳統 Cluster IP，RT 更低。

• 支援 HTTPS 硬體加速，QPS 提升 80%。

• 支援 Wasm 外掛市場，外掛熱載入，滿足使用者多語言自定義外掛訴求。

• 自研 Multi-Ingress Controller 元件支援多叢集 Ingress 複用同一個閘道器例項。

• 原生相容原生 K8s Ingress 規範，且支援 Nginx Ingress 核心功能註解的無縫轉換。

（圖 9/雲原生閘道器技術架構 ）

客戶案例分享

上海費芮網路科技有限公司之前一直使用 Nginx Ingress，使用過程中遇到運維成本高、安全差、原生功能弱等痛點，期望能夠找到一款替代產品；在接觸 MSE 雲原生閘道器後，在上線前的測試過程中對於 HTTPS 硬體加速功能非常認可，測試驗證開啟後的加速效果非常明顯；結合閘道器提供的 Nginx Ingress 註解相容功能 + HTTPS 硬體加速兩個差異功能，使用者最終選擇使用 MSE 雲原生閘道器來替代 Nginx Ingress 閘道器。

（圖 10/費芮客戶遷移雲原生閘道器）

業務配置

MSE 雲原生閘道器已經將 HTTPS 硬體加速功能產品化，只需要在購買時開啟即可，開啟後的示意圖如下：

（圖 11/雲原生閘道器開啟硬體加速）

加速效果

加速後：

• 1C2G 壓測 HTTPS QPS 從 1004 提升到 1873，提升約 86%。

• TLS 握手 RT 從 313.84ms 降到 145.81ms，下降一倍。

方案優點：

• 無需獨立專用的硬體支援，運維成本低且易於彈性擴縮容。

• 通用 CPU 加速特性的適用場景更廣泛。

參考連結（[1]-[12]）可移步龍蜥公眾號（OpenAnolis龍蜥）2022年8月30日相同推送檢視。

—— 完 —