服務質量分析：騰訊會議&騰訊雲Elasticsearch玩出了怎樣的新操做？

時間 2021-02-14

原文原文鏈接

導語 | 騰訊會議於2019年12月底上線，兩個月內日活突破1000萬，被普遍應用於疫情防控會議、遠程辦公、師生遠程授課等場景，爲疫情期間的復工復產提供了重要的遠程溝通工具。上線100天內，騰訊會議快速迭代20個版本，知足不斷增加的用戶需求，屢次登頂APP STROE中國區免費榜總榜No.1。算法

極速增加的會議需求，讓騰訊會議服務質量分析系統經受着巨大的考驗。爲了向全網用戶提供高效穩定的服務，以及對重要的大型會議進行保障護航。在充分討論調研了大量方案後，騰訊會議服務質量分析團隊與騰訊雲Elasticsearch（下文簡稱「ES」）團隊展開合做，積極探索雲端服務質量數據分析引擎架構的更多可能。數據庫

1、數據極速增加，業務穩定面臨挑戰

伴隨爆發增加的用戶需求，騰訊會議的日活也在不斷地刷新着歷史記錄。安全

從1月29日起，爲了應對疫情下遠程辦公的需求，騰訊會議天天都在進行資源擴容，日均擴容雲主機接近1.5萬臺，8天總共擴容超過10萬臺雲主機，共涉及超百萬核的計算資源投入。網絡

在會議中，偶爾存在會議實時音視頻卡頓、音視頻不一樣步等會議質量問題，形成上述問題的可能因素比較多，當前運行的網絡有丟包或鏈接不穩定的狀況就是其中一種。架構

爲了幫助運營團隊快速精準地定位分析問題，須要大量運行時的會議質量數據支撐，如網絡相關的入網類型、碼率、丟包率、網絡切換、ip切換等數據，以及客戶端相關的CPU使用率、內存使用率、操做系統版本、產品版本等數據信息。併發

因會議是一個多用戶參與交互的過程，定位問題不只須要涉及到單個用戶的狀況，也要從房間的維度洞察各個用戶之間的聯繫。經過騰訊會議客戶端實時上報的會議質量信息，運營團隊能夠快速地對單用戶、單房間的視頻會議質量狀況有直觀的瞭解，爲分析問題提供了數據支撐。運維

除了數據的實時上報，另外一方面，藉助多維分析，咱們還能夠在實時數據中挖掘出異常狀況。如某個地區大面的卡頓，某個版本出現特定的問題等。經過dashboard或數據報表的形式，幫助運營團隊及時掌控全局狀況，快速發現潛在問題。分佈式

快速增加的用戶數以及不斷刷新紀錄的同時在線房間數，讓騰訊會議服務質量分析系統經受高壓力，給運營團隊及時排查用戶問題帶來了巨大的挑戰。深究根本緣由，是由於服務質量分析系統在如此高壓力、高吞吐的場景下，寫入性能嚴重不足致使。因爲系統最關鍵的部分，是一個基於lucene自研的搜索引擎，擴容能力比較差，依賴於研發團隊針對業務的優化。在數據量暴漲的背景下，不能進行快速擴容以知足需求。ide

2、選型ES及技術考量

爲了保證全網騰訊會議用戶都能高效穩定地進行會議溝通，保證運營團隊能對用戶會議中的卡頓等問題及時進行排查，以及對重要的大型會議進行保障護航。在充分討論調研了大量方案後，騰訊會議服務質量分析團隊決定從原來的自研服務質量數據分析系統，緊急遷移至使用騰訊雲ES做爲數據分析引擎的架構上。高併發

新老架構對比圖

在進行架構方案選型的過程當中，主要從如下幾個方面進行了考慮：

1. 高性能

騰訊會議服務質量數據上報至ES的流量，峯值高達1000+w/s。在如此高吞吐的極限寫入場景下，能持續穩定地提供數據讀寫服務，確實是一個挑戰。在騰訊內部，也存在着相似騰訊會議這樣的大批量、大吞吐寫入場景，在使用過程當中，業務部門常常會發現寫入性能不高，且CPU使用率不穩定的問題，資源利用率嚴重不足。

騰訊雲ES內核團隊對相似的高壓力寫入場景進行了追蹤及分析，並在一樣的場景下進行了多個方案的壓力測試，發現ES單節點的壓力寫入測試與lucene基準的寫壓力測試有較大的差距。經過對調用火焰圖進行分析並對比測試translog的一些調優參數，最終定位發現translog文件的rollGeneration操做與flush操做有互斥，兩個操做互相頻繁的加鎖干擾，一次rollGeneration操做的平均耗時達到了570ms，在高壓力寫入場景下，頻繁的rollGeneration會嚴重影響寫入性能。

在與社區進行了大量的討論及壓測以後，最終肯定了優化方案：採用rollGeneration的過程當中，在關閉原translog文件以前，先執行一次flush，巧妙地避免了操做的互斥。這個方案對流程的改造最輕量優雅，且優化後的寫入性能提升了20%以上。這部分優化的代碼經騰訊內部的業務驗證後，最終整理提交回饋給了社區。因爲這個優化在ES寫入的全部場景下均適用，且對性能的提高很是顯著，Elastic的創始人對該PR高度讚賞，並給騰訊雲總裁發來了公開感謝信。

騰訊雲ES在社區開源的內核之上，根據雲上的內外部業務的場景案例積累，作了大量的內核優化。除了上面介紹的translog的優化，還有帶「_id」的寫入操做剪枝優化、查詢計劃優化等等，知足了客戶在性能方面的須要，並積極將一些通用的優化提交至社區，截至目前爲止，騰訊雲提交的pr約有50+被合併到了主幹。

2.擴容能力

在疫情期間，繼續沿用原有的架構很難知足快速擴容的需求，致使服務質量數據上報寫入慢，數據大量堆積在隊列中。騰訊雲ES有着完善的分佈式設計，單個集羣支持擴容至數百甚至上千個節點。有可靠完備的選主算法邏輯以及sharding路由策略作保障。數據分片支持數據冗餘，防止因爲硬件故障致使的數據丟失，並提高集羣的讀性能。同時，數據能夠按索引維度設置數據分片及副本數目，能夠根據業務特色更靈活地設置合理的數值，下降了數據存儲的成本。

騰訊雲ES依託於騰訊雲CVM進行構建，資源池充足，僅在疫情剛開始的一個月內就擴容了3W核，集羣彈性伸縮的便利性獲得了驗證。擴容節點數目及變動節點配置等均爲自動化功能，支持控制檯及API一鍵操做，擴容過程平滑，不影響業務讀寫。

在集羣擴容的場景中，相信不少業務都遇到過使用ES進行擴容後，大量新寫入數據有讀寫熱點，都堆積到新加入的節點上，致使節點被打掛，影響整個集羣的寫入性能。隨着數據的增加，騰訊會議業務也擴容至千級節點的規模，那麼上面的問題在騰訊雲ES中是如何解決的呢？

社區開源版本的ES，在shard分配的時候，會優先考慮各個節點上已有的shard數量，目的是儘可能保持各個節點的shard和數據的均衡。當集羣數據在各節點之間已經處於balance狀態時，這時候增長新節點。因爲新節點上面的shard數最少，就會形成上面的問題，新寫入的數據都分配在新的節點上，形成新的節點壓力太高而宕機。

爲了幫助客戶解決上述問題，騰訊雲ES內核團隊在原有allocationDecider責任鏈基礎上，開發了一個新的decider分配算法，將一個index的全部分片，儘可能平均地分配在各個節點上，使得新寫入數據的讀寫流量被均勻分擔，避免了新寫入數據的訪問熱點。

3. 穩定性

騰訊會議服務質量分析系統，從2月份進行ES架構的方案切換開始，寫入吞吐從5w/s不斷攀升，現已達到100w+/s。業務的突發增加有時候來的很忽然，並不能在前期作有效的評估。社區中的不少用戶也遇到過相似的問題，因爲沒有預估到業務突發的增加，而且在業務層沒有作好服務降級等機制，致使突發的寫入查詢流量打崩了整個集羣，使ES服務甚至整個業務長時間不可用。那麼，在相似騰訊會議這樣的場景中，是怎樣解決ES突增寫入查詢流量的問題的呢？

例如早期咱們內部一個日誌集羣，寫入量一天突增 5 倍，集羣多個節點 Old GC 卡住脫離集羣，集羣 RED，寫入中止，這個痛點確實有點痛。咱們對掛掉的節點作了內存分析，發現大部份內存是被反序列化先後的寫入請求佔用。咱們來看看這些寫入請求是堆積在什麼位置。

ES high level 的寫入流程，用戶的寫入請求先到達其中一個數據節點，咱們稱之爲數據節點。而後由該協調節點將請求轉發給主分片所在節點進行寫入，主分片寫入完畢再由主分片轉發給從分片寫入，最後返回給客戶端寫入結果。右邊是更細節的寫入流程，而咱們從堆棧中看到的寫入請求堆積的位置就是在紅色框中的接入層，節點掛掉的根因是協調節點的接入層內存被打爆。

針對這種高併發場景，咱們的優化方案是服務限流。除了要能控制併發請求數量，還要能精準地控制內存資源，由於內存資源不足是主要的矛盾。另外通用性要強，能做用於各個層級實現全鏈限流。

在不少數據庫使用場景，會採用從業務端或者獨立的 proxy 層配置相關的業務規則的限流方案，經過資源預估等方式進行限流。這種方式適應能力弱，運維成本高，並且業務端很難準確預估資源消耗。

ES原生版本自己有限流策略，是基於請求數的漏桶策略，經過隊列加線程池的方式實現。線程池大小決定了處理併發度，處理不完放到隊列，隊列放不下則拒絕請求。可是單純地基於請求數的限流不能控制資源使用量，並且只做用於分片級子請求的傳輸層，對於咱們前面分析的接入層沒法起到有效的保護做用。原生版本也有內存熔斷策略，可是在協調節點接入層並無作限制。

咱們的優化方案是基於內存資源的漏桶策略。咱們將節點 JVM 內存做爲漏桶的資源，當內存資源足夠的時候，請求能夠正常處理；當內存使用量到達必定閾值的時候分區間階梯式平滑限流。例如上圖中淺黃色的區間限制寫入，深黃色的區間限制查詢，底部紅色部分做爲預留 buffer，預留給處理中的請求、merge 等操做，以保證節點內存的安全性。

限流方案裏面有一個挑戰是：咱們如何才能實現平滑限流？由於採用單一的閾值限流很容易出現請求抖動，例如請求一上來把內存打上去立刻觸發限流，而放開一點點請求又會涌進來把內存打上去。咱們的方案是設置了高低限流閾值區間，在這個區間中，基於餘弦變換實現請求數和內存資源之間的平滑限流。當內存資源足夠的時候，請求經過率 100%，當內存到達限流區間逐步上升的時候，請求經過率隨之逐步降低。而當內存使用量降低的時候，請求經過率也會逐步上升，不會一把放開。經過實際測試，平滑的區間限流能在高壓力下保持穩定的寫入性能。

咱們基於內存資源的區間平滑限流策略是對原生版本基於請求數漏桶策略的有效補充，而且做用範圍更廣，覆蓋協調節點、數據節點的接入層和傳輸層，並不會替代原生的限流方案。

4. 易用性

用戶數暴增，留給系統驗證切換的時間很是短，這要求咱們必須使用一種簡單快速的解決方案。須要在一週以內輸出適用方案，並進行線上數據的切換。如原架構使用kafka隊列作數據的投遞，由自研的消息接入服務進行消息的接入、清洗並最終寫入自研的服務質量數據存儲分析服務。因爲時間緊迫，新的方案須要儘可能保留原有架構的大部分基礎設施，並作儘可能少的代碼開發改動。

在這方面，ES的社區生態作得很是完備。從採集端、收集端到存儲都有一整套解決方案。經過logstash的易用性和強大的生態插件，能夠快速替代原有的自研數據接入組件，進行數據的清洗轉換等ETL過程。如原有架構中使用的kafka，在logstash中就已經包含了相應的input插件。而且有大量數據格式的解析插件支持，對於數據的一些解析、過濾、清洗等操做能夠直接在logstash的pipeline中進行簡單的配置便可，基本上是0開發量。

豐富的各語言SDK，方便快速的對服務質量分析平臺先後臺進行快速切換，實際從代碼修改到上線完成只用了一天的時間。同時，ES社區也比較活躍，國內有10萬+的開發者參與其中，問題均可以比較快地獲得回覆和解決。在此，也特別感謝ES的研發團隊及一線運維團隊，在疫情期間，對騰訊會議進行了7*24小時的支持，並對於使用ES的一些疑難問題給出了大量的解決方案。