vivo統一接入閘道器VUA轉發效能最佳化實踐

vivo互联网技术發表於2024-03-14

作者：vivo 網際網路伺服器團隊 - Qiu Xiangcun

本文將探討如何透過使用Intel QuickAssist Technology（QAT）來最佳化VUA的HTTPS轉發效能。我們將介紹如何使用QAT透過硬體加速來提高HTTPS轉發的效能，並探討QAT在不同應用場景中的表現。最後，我們將討論如何根據實際情況進行最佳化，以獲得最佳轉發效能。

VLB 全稱 vivo load balance。

vivo負載均衡作為vivo網際網路業務的IDC流量入口，承接了很多重要業務的公網流量。本文針對 VLB 的七層負載VUA HTTPS 效能最佳化進行探索，以獲取最佳轉發效能。

一、vivo VLB整體架構

▲ 圖1 vivo VLB整體架構

VLB 整體架構的核心包括：基於DPDK的四層負載VGW，基於Apache APISIX和NGINX擴充套件功能的七層負載VUA，以及統一管控運維平臺。

其主要特點為：

高效能：具備千萬級併發和百萬級新建能力。
高可用：透過 ECMP、健康檢查等，提供由負載本身至業務伺服器多層次的高可用。
可擴充：支援四層/七層負載叢集、業務伺服器的橫向彈性伸縮、灰度釋出。
四層負載能力：透過 BGP 向交換機宣告VIP；支援均衡演算法如輪詢、加權輪詢、加權最小連線數、一致性雜湊；FullNAT 轉發模式方便部署等。
七層負載能力：支援基於域名和 URL 的轉發規則配置；支援均衡演算法如輪詢、加權輪詢等。
SSL/TLS 能力：證書、私鑰、握手策略的管理配置；支援 SNI 配置；支援基於多種加速卡的 SSL 解除安裝硬體加速等。
流量防控：提供一定的 Syn-Flood 防護能力；提供網路流量控制手段如 QoS 流控、ACL 訪問控制等。
管控平臺：支援多種維度的網路和業務指標配置、監控和告警。

本文針對 VLB 中七層負載VUA的 SSL/TLS 效能最佳化兩種方法進行概述性介紹：

基於硬體技術的QAT_HW
基於指令集最佳化的QAT_SW

二、VUA七層負載均衡

2.1 VUA介紹

目前公司接入層最大的能力痛點，就是動態上游、動態路由、動態證書、流量灰度、黑白名單、動態排程、日誌查詢與追蹤等。為了支援公司業務的持續發展，特別是業務的全面容器化，亟需建設一個統一接入平臺，融合目前線上的NGINX叢集及Ingress NGINX，用於承載公司web端、移動端、合作伙伴、內部系統、IOT裝置流量，對齊行業的接入層能力，保障業務的順利發展。

VUA定義：vivo Unified Access。

vivo 統一接入層，是基於APISIX-2.4的二次開發。

2.2 VUA架構

▲ 圖2 APISIX 架構（圖片來源：Github-apache/apisix）

Apache APISIX：OpenResty 1.19.3.1 + Lua組成（元件本身是無狀態的）。
Manager-api：由 Go 語言開發，用於配置的管理和變更。
APISIX-Ingress-Controller：基於K8S原生Controller機制開發完成，支援多副本Leader-Election熱備機制。主要監聽K8s api server，用於pod資訊上報到Manager-api。
Etcd：用於儲存路由、upstream等配置資訊。

▲ 圖3 VUA 架構

三、QAT加速技術

Intel QuickAssist 技術 OpenSSL引擎 (QAT_Engine) 支援硬體加速以及基於向量化指令的最佳化軟體。這一特性始於第三代Intel® Xeon®可擴充套件處理器，為使用者提供了更多加速其工作負載的選項。

3.1 非同步架構

VUA 基於 NGINX 原生的非同步處理框架上擴充出針對非同步硬體引擎的非同步事件處理機制，整體互動流程如下圖所示：

ASYNC_start_job：NGINX 呼叫 ssl lib 庫介面 SSL_do_handshake, 開啟一個非同步任務。
RSA/ECDH 加解密操作。
QAT 引擎將加密訊息傳送給驅動，建立非同步事件監聽 fd，將 fd 繫結到非同步任務的上下文中。
qat_pause_job: 呼叫該介面儲存非同步任務執行的堆疊資訊，任務暫時被掛起，等待硬體加解密操作完成。同時程序堆疊切換到 NGINX IO 呼叫主流程，ssl 返回 WANT_ASYNC，NGINX開始處理其他等待時間。
NGINX IO處理框架獲取儲存在非同步任務上下文中的 asyncfd，並新增到 epoll 佇列中啟動監聽。
加速卡處理任務完成，QAT 引擎呼叫 qat_wake_job 介面喚醒任務（也就是將 async fd 標記為可讀）。QAT 為 NGINX 提供了多種輪詢方式去輪詢加速卡響應佇列，目前 VUA 採用的是啟發式輪詢的方式，具體引數可以在配置檔案中定義。
NGINX 處理非同步事件重新呼叫非同步任務框架的 ASYNC_start_job 介面，這時候程式切換上下文，堆疊執行後跳回之前 pause job 的地方。

3.2 QAT元件架構概覽

Application

應用層主要包含兩塊內容：

（1）QAT 非同步框架的 patch，該 patch 提供對非同步模式的支援；

（2）QAT 引擎，engine 是 openssl 本身支援的一種機制，用以抽象各種加密演算法的實現方式，intel 提供了 QAT 引擎的開原始碼用以專門支援 QAT 加速。

SAL（service access layer）

服務接入層，給上層 Application 提供加速卡接入服務，目前 QAT 主要提供 crypto 和 compression 兩種服務，每一種服務都相互獨立，接入層封裝了一系列實用的介面，包括建立例項，初始化訊息佇列、傳送\接受請求等。

ADF（acceleration driver framework）

加速卡驅動框架，提供 SAL 需要的驅動支援，如上圖，包括 intel_qat.ko、8950pci 驅動、usdm 記憶體管理驅動等。

3.3 QAT_HW和QAT_SW

QAT_HW基於QAT硬體加速卡，透過Openssl引擎使用qatengine.so庫中連結的QAT驅動程式。

QAT_SW是基於QAT軟體加速，透過Openssl引擎使用qatengine.so庫中連結的crypto_mb和ipsec_mb庫。基於intel AVX-512 整數乘加 (IFMA) 操作緩衝區庫，當使用者構建指令支援qat_sw時，透過批處理佇列中維護的多個請求執行操作，並使用 OpenSSL 非同步基礎架構將批處理請求最多提交到8個 Crypto Multi-buffer API，後者使用AVX512 向量指令並行處理它們。主要面向非對稱 PKE 和 AES-GCM 的英特爾® QAT 軟體加速，RSA支援金鑰大小 2048、3072、4096，AES128-GCM、AES192-GCM 和 AES256-GCM。

如果平臺同時支援 QAT_HW 和 QAT_SW，則預設是使用 QAT 硬體加速非對稱演算法和對稱鏈式密碼，使用 QAT 軟體加速對稱 GCM 密碼。如果平臺沒有 QAT 硬體支援，那麼它將使用 QAT_SW 加速來實現 qatengine 中支援的非對稱演算法。

下圖說明了 QAT_Engine 的高階軟體架構。NGINX 和 HAProxy 等應用程式是與 OpenSSL介面的常見應用程式。OpenSSL是一個用於 TLS/SSL 協議的工具包，從 1.1.0 版本開始，它開發了一個模組化系統來插入特定於裝置的引擎。如上所述，QAT_Engine 中有兩個獨立的內部實體，透過它們可以執行加速。

▲（圖片來源：Github-intel/QAT_Engine）

四、最佳化方案效能提升對比

4.1 QAT_HW

本方案採用intel 8970型號加速卡進行測試，採用RSA證書進行HTTPS加解密。

（1）測試方法

執行機部署適配 QAT 引擎後的VUA，發包測試機進行壓測灌包，在 CPU 負載達到 100%後比較得出VUA在進行 QAT 最佳化後的新建 QPS對比。

（2）測試場景

（3）本地測試資料對比

使用QAT加速卡效能對比

QAT卡最佳化方案，透過 VUA進行 HTTPS 打流業務實測，與採用OpenSSL 軟體加解密場景做對比：

使用QAT加速卡，同worker下，RSA 平均QPS提升1.27倍。
隨著程序數的增加，QAT加速卡達到瓶頸，趨於穩定，在56 worker下，最高可達4.4w qps。

此最佳化方案所帶來的效能提升主要依賴於：

QAT採用使用者態驅動的方式，實現了核心態到使用者態記憶體零複製。
VUA採用非同步模式呼叫 OpenSSL API，代替傳統的同步模式呼叫。
QAT驅動程式支援多加速卡同時進行解除安裝加速。

4.2 QAT_SW

本方案採用icelake 6330型號（支援AVX512指令集）進行測試，採用RSA證書進行HTTPS加解密。

（1）測試方法

執行機部署適配指令集最佳化的VUA，發包測試機進行壓測灌包，在 CPU 負載達到 100%後比較得出VUA在進行指令集最佳化後的新建 QPS對比。

（2）測試組網