作者：王發康（毅松）
主站接入層是阿裡2015年全站HTTPS項目誕生的産品，目前已經承載集團90%以上的入口流量。2016年主站接入層不僅在運維自動化、高可用領域取得重大突破，而且軟體層面上也做過很多性能優化，促使2016年雙11平穩度過。秉着軟硬體結合的性能優化思想，2017年主站接入層在硬體加速領域邁出了第一步。在剛過去的2017年雙11零點流量高峰的考驗下，主站接入層Tengine Gzip硬體加速機器運作平穩、同等條件下相比于未開啟QAT加速的機器性能提升21%左右。
衆所周知，通用處理器（CPU）的摩爾定律已入暮年，而機器學習和Web服務需要的運算能力卻指數級增長。随着如今硬體技術的成熟發展，普通CPU無論是在計算能力，還是資源成本上相對于一些專用加速硬體已經沒有絕對優勢，這也促使硬體加速技術得到各大公司的青睐，譬如三大網際網路巨頭百度、阿裡、騰訊内部的接入層采用類似KeyLess方案來加速HTTPS的解除安裝，不僅提高了使用者體驗，還節省了機器成本。根據目前調研結果發現：目前業内各大公司接入層針對于Gzip采用硬體加速還是一片空白，阿裡接入層首次結合硬體加速技術解除安裝Gzip不僅帶來了性能提升，而且對業界在此領域的發展也有重大影響意義。
接入層Tengine目前性能瓶頸是CPU，譬如Gzip子產品在Tengine中CPU占比高達15%-20%左右，相比于其它子產品CPU消耗高、占比呈增長趨勢（後端應用壓縮邏輯後續統一前置接入層）、且集中，是以Gzip子產品使用硬體解除安裝對于性能提升、成本優化是不可或缺。
分析前先簡單介紹下什麼是硬體加速： 硬體加速（Hardware Acceleration）就是利用硬體子產品來替代軟體算法以充分利用硬體所固有的快速特性（硬體加速通常比軟體算法的效率要高），進而達到性能提升、成本優化目的，目前主要是如下兩大加速方式：
FPGA 現場可程式設計門陣列，可針對某個具體的軟體算法進行定制化程式設計，譬如業内的智能網卡；
ASIC 專用內建電路，它是面向專門用途的電路、專門為一個使用者設計和制造的，譬如Intel的QAT卡僅支援特定加減密、壓縮算法；
FPGA與ASIC的對比如下表格所示：
模式
上市速度
性能
一次性成本
量産成本
可配置
FPGA
周期較短
較差(1x)
較低
高(100x)
靈活
ASIC
周期較長
好(4x)
較高
低(1x)
有限
主站接入層承載集團90%以上的入口流量，看似隻是作為一個七層流量轉發網關，但是卻做了非常之多的事情，譬如https解除安裝及加速、單元化、智能流量轉發政策、灰階分流、限流、安全防攻擊、流量鏡像、鍊路追蹤、頁面打點等等，這一系列功能的背後是Tengine衆多子產品的支援。由于功能點比較多，是以這就導緻Tengine的CPU消耗比較分散，其主流程處理如下圖所示:
各子產品CPU消耗占比Top 5如下表格所示：
子產品名稱
功能介紹
CPU占比
Gzip
解壓縮
15%-20%
Sinfo
流量鏡像
10%
TMD
限流
8%
Lua
lua相關業務
WAF
防火牆
6%
其它衆多子產品 ... ...
就目前接入層流量模型分析來看，Gzip單個子產品CPU消耗占比達到15%-20%左右（注：主要是壓縮消耗）且占比呈上升趨勢，是以對Gzip使用硬體解除安裝迫在眉睫。
QAT(Quick Assist Technology )是Intel公司推出的一種專用硬體加速卡，不僅對SSL非對稱加解密算法（RSA、ECDH、ECDSA、DH、DSA等）具有加速，而且對資料的壓縮與解壓也具有加速效果；QAT加速卡提供zlib壓縮算法、且zlib shim對其原生zlib與QAT之間做了适配，調用方式和zlib庫方式基本一緻，需在上層業務中開啟zlib QAT模式、相對來說對上層業務改造較少.
INIC（Intelligent Network Interface Card）是網絡研發事業部自研産品，以網絡處理器為核心的高性能網絡接入卡，對于網絡封包資料的處理非常合适，針對Tengine的gzip解除安裝有如下兩種方案：
提供壓縮API給host，把壓縮資料傳回host，由host封包發送；
host和網卡約定壓縮flag，host發送未壓縮封包，智能網卡收到後進行壓縮，并且重新封包發送；
FPGA（Field-Programmable Gate Array）現場可程式設計門陣列，需要對接入層使用的zlib算法使用硬體語言重新開發、進行電路燒寫，且上層互動驅動也需要從零開發；
智能網卡的方案1相比于QAT對zlib處理沒有性能上的優勢，智能網卡隻是對zlib進行軟體解除安裝、相對于QAT并不具有加速作用；其方案2需要把Tengine一部分業務邏輯抽取到網卡中做：如spdy、http2、chunked、ssl對稱加密、響應body限速等邏輯，其成本及風險高，方案3的FPGA方式相對來說開發成本較高、且相關資源匮乏。
綜上所述最終采用QAT加速卡對接入層Tengine的Gzip進行解除安裝、加速。
QAT驅動采用UIO（Userspace I/O）技術，其大部分處于使用者态、隻有少部分處理硬體中斷應答等邏輯處于核心态，這樣不僅友善使用者調試，而且還解決了核心不支援浮點數運算的問題。當然QAT加速卡也順應了Docker虛拟化的潮流，其采用SRIOV技術，可以在虛拟機之間高效共享PCIe（Peripheral Component Interconnect Express）裝置，目前DH895XCC系列晶片最高可支援32個虛拟機共享QAT，進而達到充分利用硬體資源。其次QAT屬于ASIC模式相比于FPGA具有更好的加速效果，主要原因是由于FPGA為了可重構，導緻其邏輯查找表、觸發器衆多以及相同邏輯電路在布線上延時變大。
接入層Tengine目前采用的是下圖左邊的實線加速鍊路，其中Zlib Shim、QAT User Space Api、QAT Driver作為Tengine Gzip與底層硬體QAT的通信适配層，此方式對上層業務入侵較小、其軟體架構如下圖所示：
雖然該方案看起來比較簡單，但是真正線上實施的時候還是遇到了非常多的問題（功能、性能方面），譬如：
使用的第一版驅動Intel-Qat2.6.0-60，當QPS為1k左右時CPU很快打滿（注：正常情況下QPS為1k時，CPU消耗6%左右），且CPU消耗中90%以上都是消耗在核心态，如下圖所示：
使用strace進行相關系統熱點函數統計發現，其CPU主要消耗在ioctl系統函數上，如下所示：
通過perf檢視ioctl主要是執行記憶體配置設定指令，由于Zlib Shim需要開辟連續的實體記憶體、是以出現頻繁調用 compact_zone進行内碎片整理，其調用熱的高達88.096%，如下圖所示（注：熱度表示該函數該函數自身的熱度、調出： 表示被調用函數的熱度總和、總體： 熱度 + 調出）：
同Intel研發聯調讨論後發現是由于目前Intel QAT的Zlib Shim的模型不合理所導緻，通過推動其改造采用OOT的記憶體管理子產品USDM（内部維護一個HugePage記憶體池）方案解決。
使用上述問題解決後的驅動intel-qatOOT31092，測試後發現CPU節省效果不佳（使用者态CPU減少、但是增加了核心态的CPU），經分析、發現使用QAT加速後，部分系統函數CPU占比變高，如 open、ioctl、futex，如下圖所示（注：左邊的是使用QAT後各系統熱點函數），使用QAT後open、ioctl、futex執行時間占比高達8.95（注：3.91 + 2.68 + 2.36），而未使用版本對應占比時間才0.44（注：0.24 + 0.14 + 0.06）；
分析其Tengine的worker程序堆棧資訊發現open、ioctl都是成對出現（即一次http請求出現4次該系統調用），該現象回報給Intel的研發同學後得知是由于新驅動的Zlib Shim導緻，通過優化改造後open、ioctl調用頻率明顯減少。但是其futex系統調用頻度卻沒有減少，還是導緻核心态的CPU占比較高，通過strace跟蹤發現一個http壓縮請求後會多次調用futex、如下圖所示，同Intel研發同學了解到Zlib Shim采用多線程方式，其futex操作來自zlib shim等待QAT壓縮或解壓縮資料傳回的邏輯。
由于Tengine是多程序單線程、采用epoll異步IO事件模式，聯調Intel的研發同學對Zlib Shim進行改造（去線程），最終futex系統調用也明顯減少。
通過分析并推動Intel對QAT進行多次架構上的改造，才使得QAT的加速特性更好的發揮。
使用QAT後執行reload，可能導緻請求響應異常，如下所示：
由于每個worker程序都需要配置設定一個QAT Instance用于資料解壓縮，Tengine在reload的瞬間worker程序數可能會翻倍、而QAT Instance初始版本隻有64個、是以新啟動的worker程序可能配置設定不到Instance、導緻請求失敗。
針對此問題Intel提供的新版本QAT，其Instance數量從64提高到256個避免此問題的發生，同時我們提出容災保護方案：當Instance無法配置設定了需要自動降級為軟體壓縮，提高其可用性。
Zlib Shim huge page記憶體洩漏，導緻QAT驅動core dump：
Tengine使用記憶體池模式進行記憶體的管理，即調用(In)DeflateInit配置設定的空間無需調用(In)DeflateEnd處理、在請求結束的時候會調用請求r相關的釋放操作，進行記憶體的歸還，但是由于Zlib Shim使用的huge page必須調用(In)DeflateEnd才釋放給USDM，通過改造Tengine Gzip相關代碼後，該問題得以解決，而QAT驅動的core dump也是由于hugepage的洩漏導緻無法成功配置設定導緻。
Zlib Shim狀态機不完善導緻特定場景下的壓縮、解壓縮請求異常，等衆多問題就不一一介紹。
一路走來，通過無數次的性能優化、功能測試，多次同Intel研發同學一起探讨之後，才使得QAT在功能、性能、架構方面等衆多問題得以快速解決，下面就準備上線前期準備工作。
部署釋出
采用單rpm軟體包、雙二進制模式，進而降低軟體版與硬體加速版之間的耦合度，自動識别部署機器是否開啟QAT，并選擇正确的二進制執行；
容災保護
運作過程中由于某種資源的缺乏導緻硬體加速版本Gzip執行失敗，将會自動切換為軟體版本、待資源可用時自動切換到硬體加速版本；
可維護與監控
雖然上線前做過一系列壓測、穩定性并未出現異常，但對硬體加速的相關資源名額進行實時監控還是必不可少；
測試機器
cpu型号：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 32核 核心：2.6.32 Zlib版本：zlib-1.2.8 QAT驅動版本：intel-qatOOT40052
資料對比
同等條件下，開啟QAT加速後CPU平均值為41%左右，未開啟QAT加速的CPU平均值為48%左右，如下圖所示：
相同條件下，開啟QAT加速後系統load平均值為12.09，關閉QAT加速時系統load平均值為14.22，如下圖所示：
相同條件下，開啟與關閉QAT加速後，響應RT波動不相上下，如下所示：
同等條件下，各子產品熱點函數圖對比如下所示，其中紅色圈中的是Gzip相關函數（注：左側是開啟QAT加速）：
同比條件下Tengine Gzip使用QAT加速卡後，CPU消耗從48%下降到41%，系統負載load下降2個，且根據子產品熱點函數圖對比發現Gzip基本上已經完全解除安裝。
場景
CPU消耗
系統負載load
響應時間RT（ms）
開啟QAT加速
41%
12.09
58.88
關閉QAT加速
48%
14.22
59.47
結論
綜上資料對比，當qps為10k左右時Tengine Gzip使用QAT加速後CPU節省15%左右，且Gzip基本上完全解除安裝、随着其占比變高，優化效果将越好。
在雙11零點高峰的考驗下，接入層Tengine Gzip硬體加速機器運作平穩、同等條件下相比于未開啟QAT加速的機器性能提升21%左右；
接入層Tengine Gzip硬體加速項目是阿裡存儲技術Tair&Tengine團隊及伺服器研發計算團隊與英特爾資料中心網絡平台團隊齊心協力下的産物，不僅帶來了性能提升，而且使得接入層在硬體加速領域再次打下了堅實的基礎、為明年SSL+Gzip架構上整合做好了沉澱，同時也填充了業内接入層對Gzip采用硬體加速的空白，對此領域的發展具有一定的影響意義。