導語 | 騰訊會議於2019年12月底上線，兩個月內日活突破1000萬，被廣泛應用於疫情防控會議、遠端辦公、師生遠端授課等場景，為疫情期間的復工復產提供了重要的遠端溝通工具。上線100天內，騰訊會議快速迭代20個版本，滿足不斷增長的使用者需求，多次登頂APP STROE中國區免費榜總榜No.1。
極速增長的會議需求，讓騰訊會議服務質量分析系統經受著巨大的考驗。為了向全網使用者提供高效穩定的服務，以及對重要的大型會議進行保障護航。在充分討論調研了大量方案後，騰訊會議服務質量分析團隊與騰訊雲Elasticsearch（下文簡稱“ES”）團隊展開合作，積極探索雲端服務質量資料分析引擎架構的更多可能。
一、資料極速增長，業務穩定面臨挑戰
伴隨爆發增長的使用者需求，騰訊會議的日活也在不斷地重新整理著歷史記錄。
從1月29日起，為了應對疫情下遠端辦公的需求，騰訊會議每天都在進行資源擴容，日均擴容雲主機接近1.5萬臺，8天總共擴容超過10萬臺雲主機，共涉及超百萬核的計算資源投入。
在會議中，偶爾存在會議實時音視訊卡頓、音視訊不同步等會議質量問題，造成上述問題的可能因素比較多，當前執行的網路有丟包或連線不穩定的情況就是其中一種。
為了幫助運營團隊快速精準地定位分析問題，需要大量執行時的會議質量資料支撐，如網路相關的入網型別、位元速率、丟包率、網路切換、ip切換等資料，以及客戶端相關的CPU使用率、記憶體使用率、作業系統版本、產品版本等資料資訊。
因會議是一個多使用者參與互動的過程，定位問題不僅需要涉及到單個使用者的情況，也要從房間的維度洞察各個使用者之間的聯絡。通過騰訊會議客戶端實時上報的會議質量資訊，運營團隊可以快速地對單使用者、單房間的視訊會議質量情況有直觀的瞭解，為分析問題提供了資料支撐。
除了資料的實時上報，另一方面，藉助多維分析，我們還可以在實時資料中挖掘出異常情況。如某個地區大面的卡頓，某個版本出現特定的問題等。通過dashboard或資料包表的形式，幫助運營團隊及時掌控全域性情況，快速發現潛在問題。
快速增長的使用者數以及不斷重新整理紀錄的同時線上房間數，讓騰訊會議服務質量分析系統經受高壓力，給運營團隊及時排查使用者問題帶來了巨大的挑戰。深究根本原因，是因為服務質量分析系統在如此高壓力、高吞吐的場景下，寫入效能嚴重不足導致。由於系統最關鍵的部分，是一個基於lucene自研的搜尋引擎，擴容能力比較差，依賴於研發團隊針對業務的優化。在資料量暴漲的背景下，不能進行快速擴容以滿足需求。
二、選型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的一些疑難問題給出了大量的解決方案。
三、騰訊雲ES高可用架構為業務提供高效穩定的讀寫能力
在騰訊會議服務質量資料分析系統全部切換至ELK架構之後，達成了100w+/s的資料寫入效能要求，資料從入佇列到可被搜尋到的延遲時間從小時級別縮短至了秒級，保證了業務資料同步的實時性要求以及運營分析系統的查詢延遲要求。
截止到目前，騰訊會議叢集隨著業務的增長已平滑擴充套件至數百節點，百萬核數規模，滿足了業務資料增長下的擴容需求。
並且，得益於核心穩定性方向的大量優化，騰訊雲ES的服務穩定性上達到了99.99%，保證了萬億級別資料量高壓力使用場景下的服務穩定性，為騰訊會議的運營分析及問題排查保駕護航。
騰訊會議的普及與騰訊雲ES在資料搜尋查詢、高併發、彈性擴充套件以及安全領域的技術能力密切相關。騰訊雲ES在騰訊會議質量服務上的成功實踐，也為視訊會議這個細分行業領域提供了一個優秀的範例，擴充了行業解決方案的思路。
未來，騰訊雲ES仍將不斷迭代，針對使用者需求，不推打磨技術和產品，持續輸出穩定可靠的Elasticsearch服務。
參考資料：
[1] Elasticsearch Service免費體驗館：
https://cloud.tencent.com/act/free/personal/bigdata?from=12847#pproduct