Tengine在軟件層面已經有了深度的調試和優化經驗，但是在硬件層面，通用處理器（CPU）已經進入了摩爾定律，有了瓶頸。而在業務量突飛猛進的當下，如何利用硬件來提升性能，承載雙11等大型活動的洪峯流量，保障活動平穩度過呢？
本文作者：王發康，花名毅鬆，負責集團主站統一接入層Tengine的開發與維護。今天分享的主題是《阿里七層流量入口Tengine硬件加速探索之路》。
接入層系統介紹
接入層是2015年阿里巴巴全站HTTPS誕生的一個產品。作爲一個電商網站，爲了保護用戶信息安全、賬戶、交易的安全，全站HTTPS是勢在必行，如果淘寶、天貓、聚划算等各業務方在後端各自做接入層，機器成本高，而且證書管理複雜。爲了解決問題，我們做了統一接入層，來做HTTPS卸載和流量分發等通用功能。
所有的阿里集團流量通過四層LVS，到達統一接入層，統一接入層根據不同的維度域名轉發到對應的後端APP，並且提供智能的流量分發策略。因爲抽象出一層，通用的安全防攻擊、鏈路追蹤等高級功能，都可以在這一層統一實現。
接入層是集團所有流量的入口，它的穩定性是非常重要的。同時，接入層提供了這麼多高級功能，所以對其性能的挑戰也非常大。業務驅動了技術創新，2017年接入層在硬件加速領域邁出了第一步。
性能瓶頸分析及解決
我們要對自己的系統做性能優化，首先我們要找到系統的瓶頸點，並且進行分析與調研。
主站接入層承載集團90%以上的入口流量，同時支持着很多高級功能，比如HTTPS卸載及加速、單元化、智能流量轉發策略、灰度分流、限流、安全防攻擊、流量鏡像、鏈路追蹤、頁面打點等等，這一系列功能的背後是Tengine衆多模塊的支持。由於功能點比較多，所以這就導致Tengine的CPU消耗比較分散，消耗CPU比較大的來自兩個處HTTPS和Gzip，這就是性能瓶頸之所在。
一、HTTPS卸載篇
雖然全站HTTPS已經是一個老生常談的話題，但是國內爲何能做到的網站卻還是屈指可數？原因簡單總結來說有兩點，首先使用HTTPS後使得網站訪問速度變“慢”，其次導致服務器CPU消耗變高、從而機器成本變“貴”。
軟件優化方案：如Session複用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS等。 但軟件層面如何優化也無法滿足流量日益增長的速度，加上CPU摩爾定律已入暮年，使得專用硬件卸載CPU密集型運算成爲業界一個通用解決方案。
Tengine基於Intel QAT的異步加速方案總體架構
由三部分組成Tengine的ssl_async指令、OpenSSL + QAT Engine及QAT Driver。其中Tengine通過適配OpenSSL-1.1.0的異步接口，將私鑰操作卸載至Intel提供的引擎(QAT engine)中，引擎通過 QAT驅動調用硬件完成非對稱算法取回結果。
該方案在Tengine2.2.2中已經開源。
Tengine啓用ssl_async QAT加速後的效果如何？
RSA套件提升3.8倍(8核時) ECDHE-RSA提升2.65倍(8核時) ECDHE-ECDSA(P-384) 提升2倍(16核時) ECDHE-ECDSA(P-256) 8核達到QAT硬件處理峯值16k左右， 只有23%的性能提升。
HTTPS卸載方案可以減少物理機數量，節省CPU資源，爲公司帶來價值。
二、Gzip卸載篇
當前接入層Gzip模塊的CPU佔比達到15-20%，如果我們能卸載掉Gzip的CPU消耗，讓出來的CPU就可以用於處理更多請求和提升性能。
然而目前業內各大公司接入層針對於Gzip採用硬件加速還是一片空白，阿里在接入層結合硬件加速技術卸載Gzip調研了幾套方案：
方案一是和Intel合作的QAT卡的加速方案，直接把相關軟件算法固化到硬件中去，鏈路會更精簡。 方案二智能網卡方案，需要把Tengine一部分業務邏輯抽取到網卡中做，其成本及風險高，而且只是對zlib進行軟件卸載，相對於QAT並不具有加速作用。 方案三是FPGA卡方案，相對來說開發成本較高，且相關資源匱乏。
綜上評估，選擇方案一對Gzip進行卸載及加速。
Tengine Gzip 硬件加速方案實踐
左邊的圖是軟件方案，請求進來後，在軟件層面做一些壓縮，全部是用CPU在做。右邊是通過QAT卡來加速，把紅色那部分全部卸載到QAT卡里，通過改造Tengine中的Gzip這個模塊，讓它去調用QAT的驅動，通過硬件做壓縮，最終送回Tengine傳輸給用戶。
在這個過程中，我們也遇到了非常多的坑。
使用的第一版驅動Intel-Qat 2.6.0-60，當QPS爲1k左右時，從上圖可以看出，橫座標是時間，縱座標是CPU消耗百分比，跑到第五秒左右，CPU很快打滿，這相當於根本跑不起來。
針對這個問題，我們使用strace進行相關係統熱點函數統計發現，其CPU主要消耗在ioctl系統函數上，如下所示：
ioctl主要是做上層應用程序和底層通訊的，並且CPU消耗中90%以上都是消耗在內核態。因爲最初的每個壓縮請求都要送到硬件中去，buffer需要開闢連續的物理內存，系統跑久了，一旦遇到連續內存分配不成功的情況，就會需要ioctl去分配內存，出現頻繁調用 compact_zone進行內碎片整理，其調用熱的高達88.096%，如果分配失敗了，就會觸發內存去做碎片整理，所以就會出現sys態CPU持續上升的情況。
這個問題解決後，也並沒有那麼順利，我們遇到了下面的問題。
在日常壓測時，我們發現CPU用了Gzip卸載方案後，節省效果上並沒有明顯的提升。user態CPU降低了10%左右，但是sys態CPU相對於軟件版的CPU提升了10%。所以，節省效果不明顯。
經分析，我們發現使用QAT後，部分系統函數CPU佔比變高，如下圖所示(注:左邊的是使用QAT後各系統熱點函數，右邊是軟件版原生tengine的各系統熱點函數)open、ioctl、futex執行 時間佔比高達8.95(注:3.91 + 2.68 + 2.36)，而未使用版本對應占比時間才0.44(注:0.24 + 0.14 + 0.06)。
open和ioctl是由於Zlib Shim適配層處理邏輯有一些問題，通過優化改造後open、ioctl調用頻率明顯減少。但是其futex系統調用頻度卻沒有減少，還是導致內核態的CPU佔比較高，通過strace跟蹤發現一個http壓縮請求後會多次調用futex，Zlib Shim採用多線程方式，其futex操作來自zlib shim等待QAT壓縮或解壓縮數據返回的邏輯，由於Tengine是多進程單線程、採用epoll異步IO事件模式，聯調Intel的研發同學對Zlib Shim進行改造（去線程），最終futex系統調用也明顯減少。
一路走來，通過無數次的性能優化、功能測試，我們與Intel研發同學一起探討之後，才使得QAT在功能、性能、架構方面等衆多問題得以快速解決。
運維與監控
問題解決後，接下來我們進行上線前的準備。
一、壓測和演練，這裏主要關注高流量、壓縮與解壓縮流量混跑等情況下的性能提升情況，同時關注數據完整性校驗。 二、容災保護，在運行過程中，當硬件資源缺乏導致Gzip執行失敗，會自動切換軟件版本，硬件資源恢復後自動切回。 三、監控，對硬件加速相關的資源指標進行實時監控和報警，防患於未然。 四、部署與發佈，因爲存在硬件和軟件兩個版本，所以採用單rpm軟件包、雙二進制模式，從而降低軟件版與硬件加速版之間的耦合度，自動識別部署機器是否開啓QAT，並選擇正確的二進制執行。
硬件加速效果
上線後我們獲得了一些加速效果的數據。當QPS爲10k左右時，Tengine Gzip使用QAT加速後，CPU節省在15%左右，且Gzip基本上完全卸載，隨着其佔比變高，優化效果將越來越好。在2017年雙11零點流量峯值附近，Tengine加速機器相比普通機器性能提升 21%。
展望及總結
Tengine首次採用硬件加速技術卸載Gzip，不僅帶來性能上的提升，而且使得接入層在硬件加速領域再次打下了堅實的基礎，對業界在此領域的發展也有重大影響意義。在未來，Tengine會在軟件和硬件層面繼續探索，爲集團和用戶提供更加高可用、高性能、低成本、安全、運維自動化的系統。
###Tengine官網：http://tengine.taobao.org ###Tengine Github：https://github.com/alibaba/tengine ###作者Github：https://github.com/wangfakang
【招聘廣告】Tengine資深開發工程師/研發專家
- 負責阿里巴巴集團基礎Web服務平臺軟件設計與開發；
- 負責阿里巴巴集團圖片處理服務平臺的構建和研發；
- 主導架構設計，系統的演進和技術難題攻關，滿足迅速增長的阿里巴巴集團平臺的業務與性能要求；
- 負責通過軟硬件結合的方式來提升整體性能；
- 熟悉nginx/tengine/openresty/openssl 等至少一種開發經驗；
歡迎志同道合的夥伴加入，聯繫郵箱: [email protected]