閑魚目前實(shí)際生產(chǎn)部署環(huán)境越來越復(fù)雜，橫向依賴各種服務(wù)盤根錯(cuò)節(jié)，縱向依賴的運(yùn)行環(huán)境也越來越復(fù)雜。

[[274369]]

圖片來自 Pexels

當(dāng)服務(wù)出現(xiàn)問題的時(shí)候，能否及時(shí)在海量的數(shù)據(jù)中定位到問題根因，成為考驗(yàn)閑魚服務(wù)能力的一個(gè)嚴(yán)峻挑戰(zhàn)。

線上出現(xiàn)問題時(shí)常常需要十多分鐘，甚至更長(zhǎng)時(shí)間才能找到問題原因，因此一個(gè)能夠快速進(jìn)行自動(dòng)診斷的系統(tǒng)需求就應(yīng)運(yùn)而生，而快速診斷的基礎(chǔ)是一個(gè)高性能的實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)。

這個(gè)實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)需要具備如下的能力：

• 數(shù)據(jù)實(shí)時(shí)采集、實(shí)時(shí)分析、復(fù)雜計(jì)算、分析結(jié)果持久化。
• 可以處理多種多樣的數(shù)據(jù)。包含應(yīng)用日志、主機(jī)性能監(jiān)控指標(biāo)、調(diào)用鏈路圖。
• 高可靠性。系統(tǒng)不出問題且數(shù)據(jù)不能丟。
• 高性能，低延時(shí)。數(shù)據(jù)處理的延時(shí)不超過 3 秒，支持每秒千萬級(jí)的數(shù)據(jù)處理。

本文不涉及問題自動(dòng)診斷的具體分析模型，只討論整體實(shí)時(shí)數(shù)據(jù)處理鏈路的設(shè)計(jì)。

輸入輸出定義

為了便于理解系統(tǒng)的運(yùn)轉(zhuǎn)，我們定義該系統(tǒng)整體輸入和輸出。

輸入

服務(wù)請(qǐng)求日志(包含 traceid、時(shí)間戳、客戶端 IP、服務(wù)端 IP、耗時(shí)、返回碼、服務(wù)名、方法名)。

環(huán)境監(jiān)控?cái)?shù)據(jù)(指標(biāo)名稱、IP、時(shí)間戳、指標(biāo)值)。比如 CPU、 JVM GC 次數(shù)、JVM GC 耗時(shí)、數(shù)據(jù)庫(kù)指標(biāo)。

輸出

一段時(shí)間內(nèi)的某個(gè)服務(wù)出現(xiàn)錯(cuò)誤的根因，每個(gè)服務(wù)的錯(cuò)誤分析結(jié)果用一張有向無環(huán)圖表達(dá)。(根節(jié)點(diǎn)即是被分析的錯(cuò)誤節(jié)點(diǎn)，葉子節(jié)點(diǎn)即是錯(cuò)誤根因節(jié)點(diǎn)。葉子節(jié)點(diǎn)可能是一個(gè)外部依賴的服務(wù)錯(cuò)誤也可能是 JVM 異常等等)。

架構(gòu)設(shè)計(jì)

在實(shí)際的系統(tǒng)運(yùn)行過程中，隨著時(shí)間的推移，日志數(shù)據(jù)以及監(jiān)控?cái)?shù)據(jù)是源源不斷的在產(chǎn)生的。

每條產(chǎn)生的數(shù)據(jù)都有一個(gè)自己的時(shí)間戳。而實(shí)時(shí)傳輸這些帶有時(shí)間戳的數(shù)據(jù)就像水在不同的管道中流動(dòng)一樣。

如果把源源不斷的實(shí)時(shí)數(shù)據(jù)比作流水，那數(shù)據(jù)處理過程和自來水生產(chǎn)的過程也是類似的：

自然地，我們也將實(shí)時(shí)數(shù)據(jù)的處理過程分解成采集、傳輸、預(yù)處理、計(jì)算、存儲(chǔ)、計(jì)算與持久化幾個(gè)階段。

整體的系統(tǒng)架構(gòu)設(shè)計(jì)如下：

采集

采用阿里自研的 SLS 日志服務(wù)產(chǎn)品(包含 Logtail+LogHub 組件)，Logtail 是采集客戶端。

之所以選擇 Logtail 是因?yàn)槠鋬?yōu)秀的性能、高可靠性以及其靈活插件擴(kuò)展機(jī)制，閑魚可以定制自己的采集插件實(shí)現(xiàn)各種各樣數(shù)據(jù)的實(shí)時(shí)采集。

傳輸

Loghub 可以理解為一個(gè)數(shù)據(jù)發(fā)布訂閱組件，和 Kafka 的功能類似，作為一個(gè)數(shù)據(jù)傳輸通道其更穩(wěn)定、更安全。

詳細(xì)對(duì)比文章參考：

https://yq.aliyun.com/articles/35979?spm=5176.10695662.1996646101.searchclickresult.6f2c7fbe6g3xgP 

預(yù)處理

實(shí)時(shí)數(shù)據(jù)預(yù)處理部分采用 Blink 流計(jì)算處理組件(開源版本叫做 Flink，Blink 是阿里在 Flink 基礎(chǔ)上的內(nèi)部增強(qiáng)版本)。

目前常用的實(shí)時(shí)流計(jì)算開源產(chǎn)品有 Jstorm、Spark Stream、Flink：

• Jstorm 由于沒有中間計(jì)算狀態(tài)的，其計(jì)算過程中需要的中間結(jié)果必然依賴于外部存儲(chǔ)，這樣會(huì)導(dǎo)致頻繁的 IO 影響其性能。
• Spark Stream 本質(zhì)上是用微小的批處理來模擬實(shí)時(shí)計(jì)算，實(shí)際上還是有一定延時(shí)。
• Flink 由于其出色的狀態(tài)管理機(jī)制保證其計(jì)算的性能以及實(shí)時(shí)性，同時(shí)提供了完備 SQL 表達(dá)，使得流計(jì)算更容易。

計(jì)算與持久化

數(shù)據(jù)經(jīng)過預(yù)處理后最終生成調(diào)用鏈路聚合日志和主機(jī)監(jiān)控?cái)?shù)據(jù)，其中主機(jī)監(jiān)控?cái)?shù)據(jù)會(huì)獨(dú)立存儲(chǔ)在 TSDB 時(shí)序數(shù)據(jù)庫(kù)中，供后續(xù)統(tǒng)計(jì)分析。

TSDB 由于其針對(duì)時(shí)間指標(biāo)數(shù)據(jù)的特別存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)，非常適合做時(shí)序數(shù)據(jù)的存儲(chǔ)與查詢。

調(diào)用鏈路日志聚合數(shù)據(jù)，提供給 Cep/Graph Service 做診斷模型分析。

Cep/Graph Service 是閑魚自研的一個(gè)應(yīng)用，實(shí)現(xiàn)模型分析、復(fù)雜的數(shù)據(jù)處理以及外部服務(wù)進(jìn)行交互，同時(shí)借助 RDB 實(shí)現(xiàn)圖數(shù)據(jù)的實(shí)時(shí)聚合。

最后 Cep/Graph Service 分析的結(jié)果作為一個(gè)圖數(shù)據(jù)，實(shí)時(shí)轉(zhuǎn)儲(chǔ)在 Lindorm 中提供在線查詢。Lindorm 可以看作是增強(qiáng)版的 Hbase，在系統(tǒng)中充當(dāng)持久化存儲(chǔ)的角色。

詳細(xì)設(shè)計(jì)與性能優(yōu)化

采集

日志和指標(biāo)數(shù)據(jù)采集使用 Logtail，整個(gè)數(shù)據(jù)采集過程如圖：

其提供了非常靈活的插件機(jī)制，共有四種類型的插件：

• Inputs：輸入插件，獲取數(shù)據(jù)。
• Processors：處理插件，對(duì)得到的數(shù)據(jù)進(jìn)行處理。
• Aggregators：聚合插件，對(duì)數(shù)據(jù)進(jìn)行聚合。
• Flushers：輸出插件，將數(shù)據(jù)輸出到指定 Sink。

由于指標(biāo)數(shù)據(jù)(比如 CPU、內(nèi)存、JVM 指標(biāo))的獲取需要調(diào)用本地機(jī)器上的服務(wù)接口獲取，因此應(yīng)盡量減少請(qǐng)求次數(shù)，在 Logtail 中，一個(gè) Input 占用一個(gè) Goroutine。

閑魚通過定制 Input 插件和 Processors 插件，將多個(gè)指標(biāo)數(shù)據(jù)(比如 CPU、內(nèi)存、JVM 指標(biāo))在一個(gè) Input 插件中通過一次服務(wù)請(qǐng)求獲取(指標(biāo)獲取接口由基礎(chǔ)監(jiān)控團(tuán)隊(duì)提供)。

并將其格式化成一個(gè) Json 數(shù)組對(duì)象，在 Processors 插件中再拆分成多條數(shù)據(jù)，以減少系統(tǒng)的 IO 次數(shù)同時(shí)提升性能。

傳輸

數(shù)據(jù)傳輸使用 LogHub，Logtail 寫入數(shù)據(jù)后直接由 Blink 消費(fèi)其中的數(shù)據(jù)，只需設(shè)置合理的分區(qū)數(shù)量即可。

分區(qū)數(shù)要大于等于 Blink 讀取任務(wù)的并發(fā)數(shù)，避免 Blink 中的任務(wù)空轉(zhuǎn)。

預(yù)處理

預(yù)處理主要采用 Blink 實(shí)現(xiàn)，主要的設(shè)計(jì)和優(yōu)化點(diǎn)：

①編寫高效的計(jì)算流程

Blink 是一個(gè)有狀態(tài)的流計(jì)算框架，非常適合做實(shí)時(shí)聚合、Join 等操作。在我們的應(yīng)用中只需要關(guān)注出現(xiàn)錯(cuò)誤的的請(qǐng)求上相關(guān)服務(wù)鏈路的調(diào)用情況。

因此整個(gè)日志處理流分成兩個(gè)流：

• 服務(wù)的請(qǐng)求入口日志作為一個(gè)單獨(dú)的流來處理，篩選出請(qǐng)求出錯(cuò)的數(shù)據(jù)。
• 其他中間鏈路的調(diào)用日志作為另一個(gè)獨(dú)立的流來處理，通過和上面的流 Join On Traceid 實(shí)現(xiàn)出錯(cuò)服務(wù)依賴的請(qǐng)求數(shù)據(jù)篩選。

如上圖所示通過雙流 Join 后，輸出的就是所有發(fā)生請(qǐng)求錯(cuò)誤相關(guān)鏈路的完整數(shù)據(jù)。

②設(shè)置合理的 State 生命周期

Blink 在做 Join 的時(shí)候本質(zhì)上是通過 State 緩存中間數(shù)據(jù)狀態(tài)，然后做數(shù)據(jù)的匹配。

而如果 State 的生命周期太長(zhǎng)會(huì)導(dǎo)致數(shù)據(jù)膨脹影響性能，如果 State 的生命周期太短就會(huì)無法正常關(guān)聯(lián)出部分延遲到來的數(shù)據(jù)，所以需要合理的配置 State 生存周期，對(duì)于該應(yīng)用允許最大數(shù)據(jù)延遲為 1 分鐘。

使用niagara作為statebackend，以及設(shè)定state數(shù)據(jù)生命周期，單位毫秒 
state.backend.type=niagara 
state.backend.niagara.ttl.ms=60000 

③開啟 MicroBatch/MiniBatch

MicroBatch 和 MiniBatch 都是微批處理，只是微批的觸發(fā)機(jī)制上略有不同。原理上都是緩存一定的數(shù)據(jù)后再觸發(fā)處理，以減少對(duì) State 的訪問從而顯著提升吞吐，以及減少輸出數(shù)據(jù)量。

開啟join 
blink.miniBatch.join.enabled=true 
使用 microbatch 時(shí)需要保留以下兩個(gè) minibatch 配置 
blink.miniBatch.allowLatencyMs=5000 
防止OOM，每個(gè)批次最多緩存多少條數(shù)據(jù) 
blink.miniBatch.size=20000 

④Dynamic-Rebalance 替代 Rebalance

Blink 任務(wù)在運(yùn)行時(shí)最忌諱的就是存在計(jì)算熱點(diǎn)，為保證數(shù)據(jù)均勻使用 Dynamic Rebalance，它可以根據(jù)當(dāng)前各 Subpartition 中堆積的 Buffer 的數(shù)量，選擇負(fù)載較輕的 Subpartition 進(jìn)行寫入，從而實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡。

相比于靜態(tài)的 Rebalance 策略，在下游各任務(wù)計(jì)算能力不均衡時(shí)，可以使各任務(wù)相對(duì)負(fù)載更加均衡，從而提高整個(gè)作業(yè)的性能。

開啟動(dòng)態(tài)負(fù)載 
task.dynamic.rebalance.enabled=true 

⑤自定義輸出插件

數(shù)據(jù)關(guān)聯(lián)后需要將統(tǒng)一請(qǐng)求鏈路上的數(shù)據(jù)作為一個(gè)數(shù)據(jù)包通知下游圖分析節(jié)點(diǎn)，傳統(tǒng)的方式是通過消息服務(wù)來投遞數(shù)據(jù)。

但是通過消息服務(wù)有兩個(gè)缺點(diǎn)：

• 其吞吐量和 RDB 這種內(nèi)存數(shù)據(jù)庫(kù)相比還是較大差距(大概差一個(gè)數(shù)量級(jí))。
• 在接受端還需要根據(jù) traceid 做數(shù)據(jù)關(guān)聯(lián)。

我們通過自定義插件的方式將數(shù)據(jù)通過異步的方式寫入 RDB，同時(shí)設(shè)定數(shù)據(jù)過期時(shí)間。

在 RDB 中以

寫入的同時(shí)只將 traceid 做為消息內(nèi)容通過 MetaQ 通知下游計(jì)算服務(wù)，極大的減少了 MetaQ 的數(shù)據(jù)傳輸壓力。

圖聚合計(jì)算

Cep/Graph 計(jì)算服務(wù)節(jié)點(diǎn)在接收到 MetaQ 的通知后，綜合根據(jù)請(qǐng)求的鏈路數(shù)據(jù)以及依賴的環(huán)境監(jiān)控?cái)?shù)據(jù)，會(huì)實(shí)時(shí)生成診斷結(jié)果。

診斷結(jié)果簡(jiǎn)化為如下形式：

說明本次請(qǐng)求是由于下游 JVM 的線程池滿導(dǎo)致的，但是一次調(diào)用并不能說明該服務(wù)是不可用的根本原因，需要分析整體的錯(cuò)誤情況，那就需要對(duì)圖數(shù)據(jù)做實(shí)時(shí)聚合。

聚合設(shè)計(jì)如下(為了說明基本思路，做了簡(jiǎn)化處理)：

• 首先利用 Redis 的 Zrank 能力為根據(jù)服務(wù)名或 IP 信息為每個(gè)節(jié)點(diǎn)分配一個(gè)全局唯一排序序號(hào)。
• 為圖中的每個(gè)節(jié)點(diǎn)生成對(duì)應(yīng)圖節(jié)點(diǎn)編碼，編碼格式。
• 對(duì)于頭節(jié)點(diǎn)：頭節(jié)點(diǎn)序號(hào)|歸整時(shí)間戳|節(jié)點(diǎn)編碼。
• 對(duì)于普通節(jié)點(diǎn)：|歸整時(shí)間戳|節(jié)點(diǎn)編碼。
• 由于每個(gè)節(jié)點(diǎn)在一個(gè)時(shí)間周期內(nèi)都有唯一的 Key，因此可以將節(jié)點(diǎn)編碼作為 Key 利用 Redis 為每個(gè)節(jié)點(diǎn)做計(jì)數(shù)。同時(shí)消除了并發(fā)讀寫的問題。
• 利用 Redis 中的 Set 集合可以很方便的疊加圖的邊。
• 記錄根節(jié)點(diǎn)，即可通過遍歷還原聚合后的圖結(jié)構(gòu)。

聚合后的結(jié)果大致如下：

這樣最終生成了服務(wù)不可用的整體原因，并且通過葉子節(jié)點(diǎn)的計(jì)數(shù)可以實(shí)現(xiàn)根因的排序。

收益

系統(tǒng)上線后，整個(gè)實(shí)時(shí)處理數(shù)據(jù)鏈路的延遲不超過 3 秒。閑魚服務(wù)端問題的定位時(shí)間從十多分鐘甚至更長(zhǎng)時(shí)間下降到 5 秒內(nèi)。大大的提升了問題定位的效率。

展望

目前的系統(tǒng)可以支持閑魚每秒千萬的數(shù)據(jù)處理能力。后續(xù)自動(dòng)定位問題的服務(wù)可能會(huì)推廣到阿里內(nèi)部更多的業(yè)務(wù)場(chǎng)景，隨之而來的是數(shù)據(jù)量的成倍增加，因此對(duì)于效率和成本提出了更好的要求。

未來我們可能做的改進(jìn)：

• 能夠自動(dòng)的減少或者壓縮處理的數(shù)據(jù)。
• 復(fù)雜的模型分析計(jì)算也可以在 Blink 中完成，減少 IO，提升性能。
• 支持多租戶的數(shù)據(jù)隔離。