導語 | 隨着業務的發展，系統日益複雜，功能愈發強大，用戶數量級不斷增多，設備cpu、io、帶寬、成本逐漸增長，當發展到某個量級時，這些因素會致使系統變得臃腫不堪，服務質量難以保障，系統穩定性變差，耗費至關的人力成本和服務器資源。這就要求咱們：要有勇氣和自信重構服務，提供更先進更優秀的系統。文章做者：劉敏，騰訊基礎架構研發工程師。ios
前言json
自今年三月份以來天機閣用戶數快速上漲，業務整體接入數達到1000+，數據進入量更是迎來了爆發式上漲，日均處理量上漲了一個數量級：Trace數據峯值處理量達到340億/日條，Log日誌數據峯值處理量級達到140億/日條。
面對海量數據，老的實時計算系統處理壓力逐漸增長，底層存儲系統不管在磁盤、IO、CPU、仍是索引上都面臨巨大的壓力，計算集羣資源利用率不高，系統的調整優化迫在眉睫。
業務接入量設計模式
同比日均處理量級 緩存
1、什麼是天機閣安全
在傳統單機系統的使用過程當中，若是某個請求響應過慢或是出錯，開發人員能夠經過查看日誌快速定位到具體服務。性能優化
而隨着業務的愈來愈複雜，架構由單體逐漸演變爲微服務架構。特別是隨着容器, Serverless等技術的普遍應用，它將龐大的單體應用拆分紅多個子系統和公共的組件單元。服務器
這一理念帶來了許多好處：複雜系統的拆分簡化與隔離、公共模塊的重用性提高與更合理的資源分配、大大提高了系統變動迭代的速度以及可擴展性。架構
但反之，業務架構也隨之變的愈來愈複雜，一個看似簡單的業務後臺可能有幾百甚至幾千個服務在支撐，當接口出現問題時，開發人員很難及時從錯綜複雜的服務調用中找到問題的根源，從而錯失了止損的黃金時機，排查問題的過程也須要耗費大量的時間和人力成本。app
爲了應對這一問題，業界誕生了許多優秀的面向Devops的診斷分析系統，包括Logging、Metric、Tracing。三者關係如圖所示：less
Tracing：一系列span組成的樹狀結構。每一個span包含一次rpc請求的全部信息。從用戶發出請求到收到回包，就是經過trace來串聯整條鏈路。
Metric：指標數據。是對可觀測性指標的一種度量，例如請求數、qps峯值、函數調用次數、成功率、異常率、接口返回碼分佈等信息，可用做統計聚合。
Logging：業務日誌。
三者互相重疊，又各自專一於本身的領域，將三者結合起來就能夠快速定位問題。而已知的業界優秀開源組件有諸如：
Metric: Zabbix、Nagios、Prometheus、InfluxDB、OpenCenus；
Logging: ELK、Splunk、Loki、Loggly；
Treace: jeager、Zipkin、SkyWalking、OpenTracing。
隨着時間的推移可能會集成更多的功能，但同時也不斷地集成其餘領域的特性到系統中來。而天機閣正是騰訊研發的集三位於一體的分佈式鏈路追蹤系統，提供了海量服務下的鏈路追蹤、故障定位、架構梳理、容量評估等能力。
最近第二代天機閣系統已經建設完成，新天機閣採用opentelemetry標準，能夠支持更多場景的數據接入，同時在系統穩定性，數據實時性方面都有很大提高。
2、系統架構
從數據流轉角度來看，天機閣總體能夠分爲數據生產鏈路與消費鏈路，其中數據生產鏈路主要包括數據接入層、數據處理層、數據存儲層。總體以下圖所示。
數據生產鏈路架構圖
1. 數據接入層
主要負責數據採集工做，天機閣支持http+json、http+proto、grpc等多種數據上報方式，業務能夠採用對應語言的SDK進行數據上報。根據業務上報環境，可選擇Kafka、蟲洞等多種數據接入方式，爲減小數據傳輸耗時，提高系統的容錯能力，天機閣提供了上海、廣州、深圳等多個不一樣區域的接入通道，數據接入時會根據Idc機器所在區域自動進行「就近接入」。
2. 數據處理層
基於Flink構建的天機閣流式計算平臺。主要處理三部分數據：第一部分是Metric模調數據的計算工做，結果同步至Druid。第二部分是日誌數據，基於DataStream模式對數據進行實時消費，同步至ES日誌集羣。第三部分是Trace數據，基於KeyedStream的分組轉換模式，根據業務Traceid進行Keyby，將一條Stream流劃分爲邏輯上不相交的分組，把相同Traceid的數據實時匯聚到同一個窗口，再對數據進行統計聚合，生成拓撲圖、調用鏈、調用樹等數據模型，結果同步至Hbase與ES。
3. 數據存儲層
ES主要用於用於創建熱門Trace的倒排索引以及存儲日誌數據，Harbo/Druid系統用於存儲模調數，Hbase用於存儲調用鏈，拓撲圖，關係鏈等數據。
3、問題回顧
在海量流量的衝擊下，日誌集羣與Metric集羣一直比較穩定，處理耗時基本在秒級。影響較大的是Trace集羣，Trace集羣主要經過滾動窗口接收一個Trace請求的全部RPC 的Span信息。
因爲業務接入量的上漲以及很多業務的放量，Trace集羣的日均處理量由3月份的40億/day爆發式上漲到340億/day，且集羣還要常常面臨業務熱點push、錯誤埋點等場景的挑戰。
這些問題直接致使數據實時性開始降低，期間常常收到用戶反饋數據延時大，數據丟失的問題。而系統層面，則頻繁出現集羣抖動、延時飆升、Checkpoint失敗等現象。同時存儲也面臨巨大的寫入壓力：Hbase與ES均出現寫入延時上漲、毛刺的現象，而這些因素最終致使計算集羣的處理性能變弱，穩定性降低。產生消費滯後，數據堆積的問題。具體有以下四個表象：
1. 集羣抖動
集羣毛刺、抖動狀況增多，系統處理性能變弱，上游Kafka通道出現大量數據堆積狀況，系統處理延時上升。
集羣抖動,延時上漲
2.資源傾斜
Flink算子反壓嚴重，部分節點出現CPU過載的狀況，且各算子的Checkpoint時間變長，頻繁失敗。
checkpoint失敗
3. 存儲抖動
Hbase寫入延時上漲，高峯期寫入延時上漲到1300ms左右，寫ES平均延時上漲到2000ms，早上8~10點出現大面積寫入ES被拒絕的現象，最終會致使上游集羣掛掉。
Hbase寫入延時
ES寫入延時
計算集羣宕機
4. 系統異常
某些時間點出現系統異常，同時集羣處理延時飆升。
本着先抗住再優化的思想，當出現上述問題時，爲保證系統的可用性，咱們會採起各類快速恢復策略，諸如計算資源擴容、數據降級、關閉數據可靠性等策略來提高集羣的處理性能，達到快速恢復的目的。
但這些策略都治標不治本，性能問題周而復始的出現。這不但浪費了大量計算集羣資源，集羣處理性能，吞吐，穩定性都沒有實質上的提高。
4、問題分析
針對上述四種現象，結合業務分別從接入層、存儲層、計算層對系統進行了全面分析，找出了目前Trace系統存在的問題以及瓶頸，並制定了對應的優化方案：
Trace系統架構圖
如上圖所示，一次RPC的請求和回包最終會合併成一個Span，而每一個Span包含Traceid、Spanid，以及本次RPC調用涉及的主被調服務信息。
在接入層進行數據採樣上報時，會將相同Traceid的Span集合路由到同一個數據通道中，而計算層會對不一樣通道的數據作隔離，不一樣通道採用不一樣的計算任務對數據進行處理。
大體流程以下：首先根據Traceid高位字節進行Reducekeby，確保同一個RPC請求的數據能路由到同一個窗口，再經過窗口函數對同一個請求的數據集合進行聚合計算，實時生成拓撲圖，調用鏈等數據模型，批量寫入ES和Hbase等列式存儲。
在業務量少，集羣相對穩定的狀況下，Trace集羣平均處理時長在20-40s左右，即從一次Trace數據的上報到可展現的過程大概要通過半分鐘。
當系統不穩定或者處理性能降低時，數據延時會上漲至小時甚至天級別，而主要致使系統不穩定的因素有兩種：
數據量的上漲給存儲系統帶來了較大的攝入壓力，底層數據的刷盤時間愈來愈長；
系統常常要面臨業務方錯誤埋點或熱點Push產生的熱key、髒數據等場景的考驗。
具體表現爲：
1. 底層存儲數據攝入能力降低
Hbase寫入耗時達到1300ms ES寫入耗時達到2000ms。
存儲抖動，集羣處理耗時上漲
2. 熱key形成集羣資源傾斜
致使集羣產生毛刺、吞吐量降低等問題 。
熱key寫入量1000萬/min
3. 髒數據、代碼bug形成服務異常，致使集羣毛刺增多
集羣毛刺增多
4. 集羣缺少容錯能力，過載保護能力 。
天機閣既是一個寫密集型系統，也是一個時延敏感型系統，對數據的實時性有比較高的要求。系統的不穩定會致使消息通道大量數據堆積，數據實時性降低，最終影響用戶體驗，這是不能被容忍的。因此針對上述問題，咱們須要對原系統進行全面的優化升級。
5、總體優化思路
優化思路拓撲圖
6、ES優化
Elasticsearch 是一個實時的、Restful 風格的分佈式搜索數據分析引擎，內部使用lucene作索引與搜索，可以解決常規和各類類型數據的存儲及檢索需求，此外ES還提供了大量的聚合功能能夠對數據進行分析，統計，生成指標數據等。典型的應用場景有：數據分析，站內搜索，ELK，電商等，主要特色爲：
靈活的檢索、排序策略；
集羣分佈式，易擴展，平行擴縮容；
數據分片主備機制，系統安全高可用；
準實時索引；
高性能的檢索，易用的接口（REST風格）；
豐富的生態kibana可視化界面 。
1. 業務背景
天機閣使用騰訊雲的ES組件，專門用於創建熱門Trace倒排索引，用戶在使用天機閣進行鏈路追蹤查詢時，首先能夠指定Tag或者染色Key查詢到任意時刻上報的Trace元數據，天機閣會根據查詢到的Trace數據繪製出完整的服務調用過程。同時在UI上能夠支持瀑布、調用樹的多種樣式的數據展現。以下圖所示：
天機閣調用鏈
2. 存在的問題
隨着進入量的上漲，ES集羣內部寫入峯值達到80w/s，日均文檔總量達到280億，索引佔用總量達到 67T，天天新增索引量達到1000+，而每日文檔新增存儲總量達到10T。
機器配置採用爲：64個4C 16g的數據節點，平均CPU使用率在45-50%之間;最大CPU使用率在80%左右;內存使用率60%左右，而磁盤平均使用率達到了53%，總體流程爲。
天機閣是基於業務Appid維度按天索引的策略，而伴隨業務量的極速上漲主要暴露出來的問題爲：
（1）集羣內部分片過多
ES分片過多
分片過多的缺點主要有如下三個方面：
ES每一個索引的分片都是一個Lucene索引，它會佔用消耗CPU、內存、文件句柄；
分片過多，可能致使一個節點彙集大量分片，產生資源競爭；
ES在計算相關度詞頻統計信息的時候也是基於分片維度的，若是分片過多，也會致使數據過少相關度計算太低。
（2）分片大小不均勻
部分索引的分片容量超過50G，側面反應了這些索引分片策略的不合理，最終會致使索引的查詢性能變慢。
ES分片過大
（3）寫入耗時過大，部分索引查詢性能慢
ES寫入耗時達到(1500ms-2000ms)，此外分片過大也直接影響到索引的查詢性能。
大索引查詢超時（4800ms）
（4）索引建立過慢（1分鐘），大量寫入被拒絕
集羣沒有設置主節點，致使建立索引時，數據節點要充當臨時主節點的角色，寫入量較小的時候，影響不大，當寫入壓力過大時，會加重數據節點的負載，影響索引的建立速度。
當出現密集型索引建立時，這個問題被無限放大，索引建立同時也會伴隨大量的元數據移動，更加重了節點負載，從而致使大量數據寫入被拒絕現象。
而寫入被拒絕最終會致使上游Flink集羣劇烈抖動(寫入失敗拋出大量異常），以至於索引建立高峯期常常出現2-3小時的集羣不可用狀態。
ES寫入被拒絕
致使上游節點宕機
（5）系統出現大量異常日誌
ES服務器異常，主要分爲兩類，一類是：數據解析異常，另外一類是：Fields_limit異常。
ES服務器大量異常
（6）索引的容量管理與維護困難
主要是解決大規模以及日益增加數據場景下，集羣的自動化容量管理與生命週期管理的問題。
3. 優化一期
優化點1：優化集羣內部分片過多、分片不合理、節點負載不均等問題。
其中主要涉及了二個問題：
如何肯定索引單個分片大小？-> 小於40G
如何肯定集羣中分片數量？-> 節點堆內存*節點數*200 = 2萬左右
上述問題能夠閱讀ES官方文檔和騰訊雲ES文檔獲得全面的答案，這裏再也不贅述，總而言之，查詢和寫入的性能與索引的大小是正相關的，要保證高性能，必定要限制索引的大小。
而索引的大小取決於分片與段的大小，分片太小，可能致使段太小，進而致使開銷增長，分片過大可能致使分片頻繁Merge，產生大量IO操做，影響寫入性能。經過閱讀相關文檔，我提煉瞭如下三條原則：
分片大小控制50G之內，最好是20-40G，以均衡查詢和寫入性能。
每一個節點能夠存儲的分片數量與可用堆內存成正比，一條很好的經驗法則：「確保每一個節點配置的每G堆內存，分片數在20個如下」。
分片數爲節點數整數倍,確保分片能在節點之間均衡分佈。
固然最好的方法是根據自身業務場景來肯定分片大小，看業務是注重讀仍是注重寫以及對數據實時性、可靠性的要求。
天機閣的索引設計模式是很是靈活的，屬於典型的時序類型用例索引，以時間爲軸，按天索引，數據只增長，不更新。
在這種場景下，搜索都不是第一要素，查詢的QPS很低。原先的分片策略針對容量太低的索引統一採用5個分片都默認配置，少數超過500G的大索引纔會從新調整分片策略。
而隨着近期接入業務的不斷增多以及索引進入量的暴漲，集羣內部出現了許多容量大小不一，且分佈範圍較廣的索引。老的配置方式顯然已經不太合理，既會致使分片數急劇增加，也影響索引的讀寫性能。
因此結合業務從新評估了集羣中各個索引的容量大小，採用分級索引模版的分片控制策略，根據接入業務天天的容量變化，實現業務定製化的自適應分片。
業務索引容量分佈圖
索引模版 |
容量範圍 |
分片策略 |
索引佔用量 |
template-01 |
0-40G |
單分片 |
55% |
template-02 |
40-100G |
4分片 |
20% |
template-03 |
100-200G |
8分片 |
15% |
template-04 |
200-400G |
12 |
8% |
template-n |
... |
... |
... |
索引調整策略表
通常而言：當用戶遇到性能問題時，緣由一般均可回溯至數據的索引方式以及集羣中的分片數量。對於涉及多租戶和用到時序型索引的用例，這一點尤其突出。
優化點2：優化寫入性能。
減小集羣副本分片數，過多副本會致使ES內部寫擴大。ES集羣主用於構建熱門Trace索引用於定位問題，業務特性是寫入量大而數據敏感度不高。因此咱們能夠採用經濟實惠的配置，去掉過多副本，維護單副本保證數據冗餘已經足夠，另外對於部分超大索引，咱們也會採用0副本的策略。
索引設計方面，id自動生成（捨棄冪等），去掉打分機制，去掉DocValues策略，嵌套對象類型調整爲Object對象類型。此處優化的目的是經過減小索引字段，下降Indexing Thread線程的IO壓力，通過屢次調整選擇了最佳參數。
根據ES官方提供的優化手段進行調整，包括Refresh，Flush時間，Index_buffer_size等。
上述優化，實際上是對ES集羣一種性能的取捨，犧牲數據可靠性以及搜索實時性來換取極致的寫入性能。但其實ES只是存儲熱門數據，天機閣有專門的Hbase集羣對全量數據進行備份，詳細記錄上報日誌流水，保證數據的可靠性。
客戶端API升級，將以前ES原生的批量API升級爲Transport API，策略爲當數據緩存到5M(靈活調整)大小時，進行批量寫入（通過性能測試）。
優化點3：優化索引建立方式。
觸發試建立索引改成預建立索引模式。
申請專用主節點用於索引建立工做。
優化點4：優化ES服務器異常。
調整字段映射模式，Dynamic-Mapping動態映射可能致使字段映射出現問題，這裏修改成手動映射。
調整Limit Feild限制，修改ES索引字段上限。
業務層加入數據清洗算子，過濾髒數據以及埋點錯誤致使Tag過多的Span，保護存儲。
4. 一期優化展現
cpu使用率：CPU使用率45% => 23%，內部寫入量從60萬/s => 40萬/s。
磁盤使用率：53% => 40%。
寫入拒絕率：索引寫入拒絕率降爲0。
集羣宕機問題被修復:
查詢耗時：大索引跨天級別查詢在500ms左右。
分片數量：7萬 => 3萬，減小了50%，同時索引存儲量優化了20%。
寫入耗時：從2000ms => 900ms左右。
5. 優化二期
通過一期的優化ES寫入性能有了明顯提高，但還存在一些痛點，包括：
寫入延時仍是過大，沒有達到預期效果。
分片數3萬+ 仍是過多，同時索引建立時間仍然過長（1分鐘）。
索引容量管理以及生命週期管理困難。
6. 優化方案
（1）升級硬件配置
4C16G升級爲16C 32G， 節點總數由64降爲48，開啓專用主節點。默認狀況下集羣中的任何一個節點都有可能被選爲主節點，爲了確保一個集羣的穩定，當節點數比較多時，最好是對生產環境中的節點進行職責劃分，分離出主節點和數據節點。
天機閣採用3（防止腦裂）臺低配置的節點做爲專用主節點，負責索引的建立、刪除、分片分配等工做，數據節點專門用來作數據的索引、查詢、更新、聚合等工做。
（2）ES集羣分通道部署
目前天機閣只有一個公共集羣，全部業務都在同一個集羣中建立索引，這種方式雖然具有了必定的可擴展性。可是隨着業務量的進一步增加，集羣規模也會逐漸變的巨大，從而容易達到系統的性能瓶頸，沒法知足擴展性須要，且當大集羣中有索引出現問題時，容易影響到其餘業務。
因此咱們從業務維度對公共集羣進行解耦，按通道作set化部署，將不一樣通道業務，就近路由到不一樣集羣，各集羣可按需靈活擴展。
（3）基於ILM + Rollover + 別名實現索引自動化生命週期管理與容量管理
天機閣是典型的日誌型時序索引，根據應用Appid按天定時生成索引，索引的生命週期默認爲7天，其中當天的數據會被頻繁寫入與查詢，第2、三天的數據偶爾被查詢，後面幾天的數據只有少數重度業務使用者纔會查詢到。
這樣的特性會衍生出來幾個問題：
ES索引分片數一旦建立便沒法更改，這種機制沒法應對業務突然放量致使的索引容量激增的問題，一般只能經過手動Reindex來解決，而Reindex過程也會影響到業務寫入性能。
根據日誌索引存儲具有的特色，不一樣時間階段能夠從新對分片數、副本數、Segment進行鍼對性調整，對冷數據進行歸檔處理，從而更好的利用機器資源。
須要建立額外的定時任務來刪除索引，特別是當集羣中索引過多時，密集型的索引刪除操做，短期內也會形成集羣的波動。
咱們但願構建一個優雅的索引自動化運維管理系統，而這個系統主要解決兩個問題：
自動化索引生命週期管理： 建立索引生命週期管理，並定義不一樣階段的索引策略，以此來實現ES索引自動化優化與生命週期管理而不須要引入第三方服務。
自動化索引容量管理：當集羣索引超過設定容量大小時，能夠自動進行滾動，生成新的索引，而上游業務不須要感知。
7. 索引自動化管理優化
ES在索引管理這一塊一直在進行迭代優化，諸如Rollover、日期索引、Curator等都是對索引管理的一種策略，可是這些方式都不夠自動化。
直到ES6.7之後，官方推出了ILM（index lifestyle management)索引生命週期管理策略，能同時控制多個索引的生命流轉，配合索引模板、別名、Rollover能實現自動化索引生命週期與容量的管理閉環。
ILM策略主要有四個階段：
Hot階段：可讀，可寫，索引會被頻繁查詢。
Warm：可讀，不可寫，此時可對數據進行歸檔，採用Shrink與Forcemerge，減小索引副本與主分片數，並強制進行Segment合併，可以減小數據內存與磁盤的使用。
Cold：不可寫入，好久沒被更新，查詢慢。可對索引進行凍結操做，此時集羣將對索引進行落盤操做，業務須要指定特定的參數才能查詢到數據。
Delete：刪除操做。將觸發索引刪除事件。
8. 天機閣索引管理實踐
天機閣使用ILM 策略配合分級索引模板能夠比較優雅的實現索引的自動化管理過程。
ILM 策略主要分爲四個階段：熱、溫、冷和刪除。對於定義好的各個階段的相應策略，ILM 會始終順序執行。咱們只須要根據索引每一個階段的數據特性定義合適的管理方式，諸如：索引滾動更新用於管理每一個索引的大小；強制合併操做可用於優化索引；凍結操做可用於減小集羣的存儲壓力。
天機閣經過Flink Stream讀取Kafka數據實時寫入ES，峯值QPS接近35w，天天新增索引超過1000+。
在這麼大數據量上進行操做是一件很麻煩的事。咱們但願ES可以自動化對分片超過100G的索引進行滾動更新，超過3天后的索引進行自動歸檔，並自動刪除7天前的索引，同時對外以提供索引別名方式進行讀寫操做。
這個場景能夠經過ILM配置來實現，具體策略是：對於一些小於40G的索引，在Warm階段執行Shrink策略壓縮成單分片，並設定寫入低峯期執行Forcemerge操做合併集羣中小的段,Cold階段能夠執行Allocate操做來減小副本數，而針對集羣內部1%的大索引，能夠執行Freeze操做來釋放部分存儲空間。具體策略以下表所示：
天機閣索引ILM策略
索引模板配置
ILM能夠高效的進行索引生命週期與容量自動化管理，使用起來也很簡單。可是仍是有很多要注意的地方。
切換策略後索引不會立刻生效，舊數據仍然寫入舊索引，只有觸發Rollover生成新索引，新策略纔會生效。
每一個階段的生效時間是以Hot階段觸發Rollover爲起始時間的基礎上再加業務配置時間。
若是不想使用Rollover，能夠直接進行關閉，也能夠實現只對索引進行生命週期的管理操做。
騰訊雲ES最好採用 白金版 + 6.8以上版本。
後續優化：ILM + 冷熱架構,ILM 可支持爲時序索引實現熱溫冷架構從而節約一些成本。
9. 最終優化效果
寫入耗時：2500萬/min寫入量 2000ms - > 320ms。
分片數量：7.2萬 -> 2萬 分片數量減小 70%。
索引存儲總量：67T -> 48T 節約存儲 30%。
建立索引速度：分鐘級 -> 秒級。
7、優化後總體架構圖
Flink實時計算系統是天機閣鏈路追蹤平臺的重要組成部分，數據通過Flink窗口進行實時計算聚合最終sink到ES與Hbase等底層存儲，而日益增加的數據量給計算集羣帶來了很大的挑戰。
面對這些問題，咱們從新梳理了整個鏈路架構，找到系統的瓶頸所在，並展開了一系列有效的優化措施。而在將來，咱們會繼續在大數據領域的探索研究工做，更進一步的打磨系統數據處理能力，提供更好的服務。
總體從計算層、存儲層、架構、服務質量等幾個維度對系統進行了優化，同時也增強了系統的容災能力
自定義計數器實現熱Key自動發現與降級。
存儲過載保護，當QPS超過壓測閾值時，觸發降級邏輯。
經過druid 預聚合方式完善對業務的多維監控。
結語
性能是用戶體驗的基石，而性能優化的最終目標是優化用戶體驗，俗話說：「天下武功，惟快不破」，這句話放到性能優化上也是適用的。
咱們優化ES, Habse存儲攝入速度，優化Flink的處理速度以及接入層的數據採集能力，都是爲了保證數據的「快」。而優化的過程則須要咱們作好打持久戰的準備，既不能過早優化，也不能過分優化。
最好的方式是深刻理解業務，瞭解系統瓶頸所在，創建精細化的的監控平臺，當系統出現問題時，咱們就能夠作到有條不紊，從應用，架構，運維等層面進行優化分析，設定一些指望的性能指標，並對每次優化措施和效果作總結思考，從而造成本身的方法論。