阿里七層流量入口 Tengine硬體加速探索之路

2021-08-20 10:00:35 字數 3945 閱讀 8415

接入層系統介紹

接入層是2023年阿里巴巴全站https誕生的乙個產品。作為乙個電商**,為了保護使用者資訊保安、賬戶、交易的安全,全站https是勢在必行,如果**、天貓、聚划算等各業務方在後端各自做接入層,機器成本高,而且證書管理複雜。為了解決問題,我們做了統一接入層,來做https解除安裝和流量分發等通用功能。

接入層是集團所有流量的入口,它的穩定性是非常重要的。同時,接入層提供了這麼多高階功能,所以對其效能的挑戰也非常大。業務驅動了技術創新,2023年接入層在硬體加速領域邁出了第一步。

效能瓶頸分析及解決

我們要對自己的系統做效能優化,首先我們要找到系統的瓶頸點,並且進行分析與調研。

主站接入層承載集團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很快打滿,這相當於根本跑不起來。

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基本上完全解除安裝,隨著其佔比變高,優化效果將越來越好。在2023年雙11零點流量峰值附近,tengine加速機器相比普通機器效能提公升 21%。

展望及總結

tengine首次採用硬體加速技術解除安裝gzip,不僅帶來效能上的提公升,而且使得接入層在硬體加速領域再次打下了堅實的基礎,對業界在此領域的發展也有重大影響意義。在未來,tengine會在軟體和硬體層面繼續探索,為集團和使用者提供更加高可用、高效能、低成本、安全、運維自動化的系統。

tengine官網:

tengine github:

作者github:

end乙份關於資料科學家應該具備的技能清單

阿里雲技術專家金九:tengine https原理解析、實踐與除錯

深度剖析卷積神經網路

阿里hbase的資料管道設施實踐與演進

阿里七層流量入口 Tengine硬體加速探索之路

tengine在軟體層面已經有了深度的除錯和優化經驗,但是在硬體層面,通用處理器 cpu 已經進入了摩爾定律,有了瓶頸。而在業務量突飛猛進的當下,如何利用硬體來提公升效能,承載雙11等大型活動的洪峰流量,保障活動平穩度過呢?接入層是2015年阿里巴巴全站https誕生的乙個產品。作為乙個電商 為了保...

OSI七層模型

網際網路的各項應用,其實都是分層的,也就是各位網路達人常說的osi七層模型,下面我們就來具體看看網際網路的osi七層模型。一 什麼是網際網路osi模型?osi open system interconnection 是指開放式系統互聯參考模型。在我們的平常使用的計算機網路中存在眾多體系結構,如ibm...

OSI七層模型

1.物理層 主要定義物理裝置標準,如網線的介面型別 光纖的介面型別 各種 傳輸介質的傳輸速率等。它的主要作用是傳輸位元流 就是由1 0轉化為電流強弱來進行傳輸,到達目的地後在轉化為1 0,也就是我們常說的數模轉換與模數轉換 這一層的資料叫做位元。物理層建立在物理通訊介質的基礎上,作為系統和通訊介質的...