摘要：Tengine在軟件層面已經(jīng)有了深度的調(diào)試和優(yōu)化經(jīng)驗(yàn)寓落，但是在硬件層面括丁，通用處理器（CPU）已經(jīng)進(jìn)入了摩爾定律，有了瓶頸伶选。而在業(yè)務(wù)量突飛猛進(jìn)的當(dāng)下史飞，如何利用硬件來提升性能，承載雙11等大型活動(dòng)的洪峰流量考蕾，保障活動(dòng)平穩(wěn)度過呢祸憋？本文作者：王發(fā)康，花名毅松肖卧，負(fù)責(zé)集團(tuán)主站統(tǒng)一接入層Tengine的開發(fā)與維護(hù)蚯窥。
Tengine在軟件層面已經(jīng)有了深度的調(diào)試和優(yōu)化經(jīng)驗(yàn)，但是在硬件層面塞帐，通用處理器（CPU）已經(jīng)進(jìn)入了摩爾定律拦赠，有了瓶頸。而在業(yè)務(wù)量突飛猛進(jìn)的當(dāng)下葵姥，如何利用硬件來提升性能荷鼠，承載雙11等大型活動(dòng)的洪峰流量，保障活動(dòng)平穩(wěn)度過呢榔幸？
本文作者：王發(fā)康允乐，花名毅松矮嫉，負(fù)責(zé)集團(tuán)主站統(tǒng)一接入層Tengine的開發(fā)與維護(hù)。今天分享的主題是《阿里七層流量入口Tengine硬件加速探索之路》牍疏。
接入層系統(tǒng)介紹
接入層是2015年阿里巴巴全站HTTPS誕生的一個(gè)產(chǎn)品蠢笋。作為一個(gè)電商網(wǎng)站，為了保護(hù)用戶信息安全鳞陨、賬戶昨寞、交易的安全，全站HTTPS是勢在必行厦滤，如果淘寶援岩、天貓、聚劃算等各業(yè)務(wù)方在后端各自做接入層掏导，機(jī)器成本高享怀，而且證書管理復(fù)雜。為了解決問題碘菜，我們做了統(tǒng)一接入層凹蜈，來做HTTPS卸載和流量分發(fā)等通用功能限寞。
所有的阿里集團(tuán)流量通過四層LVS忍啸，到達(dá)統(tǒng)一接入層，統(tǒng)一接入層根據(jù)不同的維度域名轉(zhuǎn)發(fā)到對(duì)應(yīng)的后端APP履植，并且提供智能的流量分發(fā)策略计雌。因?yàn)槌橄蟪鲆粚樱ㄓ玫陌踩拦裘钓㈡溌纷粉櫟雀呒?jí)功能凿滤，都可以在這一層統(tǒng)一實(shí)現(xiàn)。
接入層是集團(tuán)所有流量的入口庶近，它的穩(wěn)定性是非常重要的翁脆。同時(shí)，接入層提供了這么多高級(jí)功能鼻种，所以對(duì)其性能的挑戰(zhàn)也非常大反番。業(yè)務(wù)驅(qū)動(dòng)了技術(shù)創(chuàng)新，2017年接入層在硬件加速領(lǐng)域邁出了第一步叉钥。
性能瓶頸分析及解決
我們要對(duì)自己的系統(tǒng)做性能優(yōu)化罢缸，首先我們要找到系統(tǒng)的瓶頸點(diǎn)，并且進(jìn)行分析與調(diào)研投队。
主站接入層承載集團(tuán)90%以上的入口流量枫疆，同時(shí)支持著很多高級(jí)功能，比如HTTPS卸載及加速敷鸦、單元化息楔、智能流量轉(zhuǎn)發(fā)策略寝贡、灰度分流、限流值依、安全防攻擊兔甘、流量鏡像、鏈路追蹤鳞滨、頁面打點(diǎn)等等洞焙，這一系列功能的背后是Tengine眾多模塊的支持。由于功能點(diǎn)比較多拯啦，所以這就導(dǎo)致Tengine的CPU消耗比較分散澡匪，消耗CPU比較大的來自兩個(gè)處HTTPS和Gzip，這就是性能瓶頸之所在褒链。
一唁情、HTTPS卸載篇
雖然全站HTTPS已經(jīng)是一個(gè)老生常談的話題，但是國內(nèi)為何能做到的網(wǎng)站卻還是屈指可數(shù)甫匹？原因簡單總結(jié)來說有兩點(diǎn)甸鸟，首先使用HTTPS后使得網(wǎng)站訪問速度變“慢”，其次導(dǎo)致服務(wù)器CPU消耗變高兵迅、從而機(jī)器成本變“貴”抢韭。
軟件優(yōu)化方案：如Session復(fù)用、OCSP Stapling恍箭、False Start刻恭、dynamic record size、TLS1.3扯夭、HSTS等鳍贾。 但軟件層面如何優(yōu)化也無法滿足流量日益增長的速度，加上CPU摩爾定律已入暮年交洗，使得專用硬件卸載CPU密集型運(yùn)算成為業(yè)界一個(gè)通用解決方案骑科。
Tengine基于Intel QAT的異步加速方案總體架構(gòu)
由三部分組成Tengine的ssl_async指令、OpenSSL + QAT Engine及QAT Driver构拳。其中Tengine通過適配OpenSSL-1.1.0的異步接口咆爽，將私鑰操作卸載至Intel提供的引擎(QAT engine)中，引擎通過 QAT驅(qū)動(dòng)調(diào)用硬件完成非對(duì)稱算法取回結(jié)果隐圾。
該方案在Tengine2.2.2中已經(jīng)開源伍掀。
Tengine啟用ssl_async QAT加速后的效果如何？
RSA套件提升3.8倍(8核時(shí))
ECDHE-RSA提升2.65倍(8核時(shí))
ECDHE-ECDSA(P-384) 提升2倍(16核時(shí))
ECDHE-ECDSA(P-256) 8核達(dá)到QAT硬件處理峰值16k左右暇藏， 只有23%的性能提升蜜笤。
HTTPS卸載方案可以減少物理機(jī)數(shù)量，節(jié)省CPU資源盐碱，為公司帶來價(jià)值把兔。
二沪伙、Gzip卸載篇
當(dāng)前接入層Gzip模塊的CPU占比達(dá)到15-20%，如果我們能卸載掉Gzip的CPU消耗县好，讓出來的CPU就可以用于處理更多請求和提升性能围橡。
然而目前業(yè)內(nèi)各大公司接入層針對(duì)于Gzip采用硬件加速還是一片空白，阿里在接入層結(jié)合硬件加速技術(shù)卸載Gzip調(diào)研了幾套方案：
方案一是和Intel合作的QAT卡的加速方案缕贡，直接把相關(guān)軟件算法固化到硬件中去翁授，鏈路會(huì)更精簡。
方案二智能網(wǎng)卡方案晾咪，需要把Tengine一部分業(yè)務(wù)邏輯抽取到網(wǎng)卡中做收擦，其成本及風(fēng)險(xiǎn)高，而且只是對(duì)zlib進(jìn)行軟件卸載谍倦，相對(duì)于QAT并不具有加速作用塞赂。
方案三是FPGA卡方案，相對(duì)來說開發(fā)成本較高昼蛀，且相關(guān)資源匱乏宴猾。
綜上評(píng)估，選擇方案一對(duì)Gzip進(jìn)行卸載及加速叼旋。
Tengine Gzip 硬件加速方案實(shí)踐
左邊的圖是軟件方案仇哆，請求進(jìn)來后，在軟件層面做一些壓縮送淆，全部是用CPU在做税产。右邊是通過QAT卡來加速怕轿，把紅色那部分全部卸載到QAT卡里偷崩，通過改造Tengine中的Gzip這個(gè)模塊，讓它去調(diào)用QAT的驅(qū)動(dòng)撞羽，通過硬件做壓縮阐斜，最終送回Tengine傳輸給用戶。
在這個(gè)過程中诀紊，我們也遇到了非常多的坑谒出。
使用的第一版驅(qū)動(dòng)Intel-Qat 2.6.0-60，當(dāng)QPS為1k左右時(shí)邻奠，從上圖可以看出笤喳，橫坐標(biāo)是時(shí)間，縱坐標(biāo)是CPU消耗百分比碌宴，跑到第五秒左右杀狡，CPU很快打滿，這相當(dāng)于根本跑不起來贰镣。
針對(duì)這個(gè)問題呜象，我們使用strace進(jìn)行相關(guān)系統(tǒng)熱點(diǎn)函數(shù)統(tǒng)計(jì)發(fā)現(xiàn)膳凝，其CPU主要消耗在ioctl系統(tǒng)函數(shù)上，如下所示：
ioctl主要是做上層應(yīng)用程序和底層通訊的恭陡，并且CPU消耗中90%以上都是消耗在內(nèi)核態(tài)蹬音。因?yàn)樽畛醯拿總€(gè)壓縮請求都要送到硬件中去，buffer需要開辟連續(xù)的物理內(nèi)存休玩，系統(tǒng)跑久了著淆，一旦遇到連續(xù)內(nèi)存分配不成功的情況，就會(huì)需要ioctl去分配內(nèi)存拴疤，出現(xiàn)頻繁調(diào)用 compact_zone進(jìn)行內(nèi)碎片整理牧抽，其調(diào)用熱的高達(dá)88.096%，如果分配失敗了遥赚，就會(huì)觸發(fā)內(nèi)存去做碎片整理扬舒，所以就會(huì)出現(xiàn)sys態(tài)CPU持續(xù)上升的情況。
這個(gè)問題解決后凫佛，也并沒有那么順利讲坎，我們遇到了下面的問題。
在日常壓測時(shí)愧薛，我們發(fā)現(xiàn)CPU用了Gzip卸載方案后晨炕，節(jié)省效果上并沒有明顯的提升。user態(tài)CPU降低了10%左右毫炉，但是sys態(tài)CPU相對(duì)于軟件版的CPU提升了10%瓮栗。所以，節(jié)省效果不明顯瞄勾。
經(jīng)分析费奸，我們發(fā)現(xiàn)使用QAT后，部分系統(tǒng)函數(shù)CPU占比變高进陡，如下圖所示(注:左邊的是使用QAT后各系統(tǒng)熱點(diǎn)函數(shù)愿阐，右邊是軟件版原生tengine的各系統(tǒng)熱點(diǎn)函數(shù))open、ioctl趾疚、futex執(zhí)行 時(shí)間占比高達(dá)8.95(注:3.91 + 2.68 + 2.36)缨历，而未使用版本對(duì)應(yīng)占比時(shí)間才0.44(注:0.24 + 0.14 + 0.06)。
open和ioctl是由于Zlib Shim適配層處理邏輯有一些問題糙麦，通過優(yōu)化改造后open辛孵、ioctl調(diào)用頻率明顯減少。但是其futex系統(tǒng)調(diào)用頻度卻沒有減少赡磅，還是導(dǎo)致內(nèi)核態(tài)的CPU占比較高魄缚，通過strace跟蹤發(fā)現(xiàn)一個(gè)http壓縮請求后會(huì)多次調(diào)用futex，Zlib Shim采用多線程方式仆邓，其futex操作來自zlib shim等待QAT壓縮或解壓縮數(shù)據(jù)返回的邏輯鲜滩，由于Tengine是多進(jìn)程單線程伴鳖、采用epoll異步IO事件模式，聯(lián)調(diào)Intel的研發(fā)同學(xué)對(duì)Zlib Shim進(jìn)行改造（去線程）徙硅，最終futex系統(tǒng)調(diào)用也明顯減少榜聂。
一路走來，通過無數(shù)次的性能優(yōu)化嗓蘑、功能測試须肆，我們與Intel研發(fā)同學(xué)一起探討之后，才使得QAT在功能桩皿、性能豌汇、架構(gòu)方面等眾多問題得以快速解決。
運(yùn)維與監(jiān)控
問題解決后泄隔，接下來我們進(jìn)行上線前的準(zhǔn)備拒贱。
一、壓測和演練佛嬉，這里主要關(guān)注高流量逻澳、壓縮與解壓縮流量混跑等情況下的性能提升情況，同時(shí)關(guān)注數(shù)據(jù)完整性校驗(yàn)暖呕。
二斜做、容災(zāi)保護(hù)，在運(yùn)行過程中湾揽，當(dāng)硬件資源缺乏導(dǎo)致Gzip執(zhí)行失敗瓤逼，會(huì)自動(dòng)切換軟件版本，硬件資源恢復(fù)后自動(dòng)切回库物。
三扼睬、監(jiān)控次洼，對(duì)硬件加速相關(guān)的資源指標(biāo)進(jìn)行實(shí)時(shí)監(jiān)控和報(bào)警蜈项，防患于未然瘪菌。
四、部署與發(fā)布毫目，因?yàn)榇嬖谟布蛙浖蓚€(gè)版本，所以采用單rpm軟件包诲侮、雙二進(jìn)制模式镀虐，從而降低軟件版與硬件加速版之間的耦合度，自動(dòng)識(shí)別部署機(jī)器是否開啟QAT沟绪，并選擇正確的二進(jìn)制執(zhí)行刮便。
硬件加速效果
上線后我們獲得了一些加速效果的數(shù)據(jù)。當(dāng)QPS為10k左右時(shí)绽慈，Tengine Gzip使用QAT加速后恨旱，CPU節(jié)省在15%左右辈毯，且Gzip基本上完全卸載，隨著其占比變高搜贤，優(yōu)化效果將越來越好谆沃。在2017年雙11零點(diǎn)流量峰值附近，Tengine加速機(jī)器相比普通機(jī)器性能提升 21%仪芒。
展望及總結(jié)
Tengine首次采用硬件加速技術(shù)卸載Gzip唁影，不僅帶來性能上的提升，而且使得接入層在硬件加速領(lǐng)域再次打下了堅(jiān)實(shí)的基礎(chǔ)掂名，對(duì)業(yè)界在此領(lǐng)域的發(fā)展也有重大影響意義据沈。在未來，Tengine會(huì)在軟件和硬件層面繼續(xù)探索饺蔑，為集團(tuán)和用戶提供更加高可用锌介、高性能、低成本猾警、安全掏湾、運(yùn)維自動(dòng)化的系統(tǒng)。
