作者 | Steef-Jan Wiggers

譯者 | 馬可薇

Discord 工程團(tuán)隊(duì)分享了他們是如何在支撐數(shù)百萬(wàn)并發(fā)用戶的情況下，為自家的 Elixir 基礎(chǔ)設(shè)施加入分布式追蹤的。他們做了一個(gè)自定義的 “Transport” 庫(kù)，把追蹤上下文包在 Elixir 的消息傳遞機(jī)制外面，從而解決了在 actor 架構(gòu)里做可觀測(cè)性埋點(diǎn)的一個(gè)核心難題。

和基于 HTTP 的微服務(wù)不同（trace context 通常放在 header 里傳遞），Elixir 的 actor 模型是在進(jìn)程之間直接傳任意消息，本身并沒有元數(shù)據(jù)這一層。Discord 希望在整個(gè)聊天系統(tǒng)里實(shí)現(xiàn)端到端的可觀測(cè)性，但遇到了一個(gè)問(wèn)題：OpenTelemetry 的標(biāo)準(zhǔn)追蹤 只能在單個(gè)服務(wù)內(nèi)部生效，沒法在 Elixir 進(jìn)程之間傳遞上下文。

團(tuán)隊(duì)總結(jié)了三個(gè)必須滿足的要求：一是對(duì)開發(fā)者足夠友好，方便落地；二是既支持原始消息，也支持 GenServer 抽象；三是能夠在生產(chǎn)環(huán)境實(shí)現(xiàn)無(wú)停機(jī)部署。

Discord 的方案引入了一個(gè)叫 “Envelope（信封）” 的基礎(chǔ)結(jié)構(gòu)，用來(lái)把 trace context 包進(jìn)消息里。實(shí)現(xiàn)看起來(lái)非常簡(jiǎn)單，本質(zhì)上就是一個(gè)結(jié)構(gòu)體，里面包含原始消息和序列化后的 trace carrier：

end

這個(gè)庫(kù)提供了可以直接替換的 GenServer call 和 cast 方法，會(huì)自動(dòng)把發(fā)出去的消息包一層。在接收端，通過(guò)一個(gè) handle_message 函數(shù)統(tǒng)一處理舊的裸消息和新的 Envelope 消息：如果有 trace context 就提取出來(lái)，用完之后再清理掉。

這個(gè)“統(tǒng)一處理”的設(shè)計(jì)在上線過(guò)程中非常關(guān)鍵。Discord 不可能一夜之間改掉所有消息傳遞邏輯，也沒法同時(shí)更新所有節(jié)點(diǎn)。這個(gè)庫(kù)可以同時(shí)處理已埋點(diǎn)和未埋點(diǎn)的消息，從而支持逐步遷移，而且不需要重啟服務(wù)。

Discord 的架構(gòu)在擴(kuò)展性上有一些獨(dú)特挑戰(zhàn)。比如一個(gè)用戶在一個(gè)有一百萬(wàn)在線成員的服務(wù)器里發(fā)消息，這一個(gè)帶追蹤的操作就可能生成一百萬(wàn)個(gè)子 span——每個(gè)會(huì)話一個(gè)，用來(lái)把消息轉(zhuǎn)發(fā)給客戶端。

團(tuán)隊(duì)基于 fanout（消息擴(kuò)散規(guī)模）做了動(dòng)態(tài)采樣。發(fā)給單個(gè)用戶的消息，100% 保留采樣結(jié)果。發(fā)給 100 個(gè)用戶時(shí)，采樣率降到 10%。當(dāng)接收人數(shù)超過(guò) 1 萬(wàn)時(shí)，只有 0.1% 的會(huì)話會(huì)記錄會(huì)采樣。這樣既能保留有價(jià)值的追蹤數(shù)據(jù)，又不會(huì)把可觀測(cè)性系統(tǒng)壓垮。

來(lái)源：Discord 博客

最初上線時(shí)，追蹤帶來(lái)的開銷超出了 Discord 的預(yù)期。那些最活躍、擁有數(shù)百萬(wàn)成員的服務(wù)器，一度跟不上消息流量。性能分析發(fā)現(xiàn)，即使 99% 以上的操作沒有被采樣，進(jìn)程仍然花了大量時(shí)間在解析 trace context 上。

解決方案是：只對(duì)被采樣的請(qǐng)求傳遞 trace context。未采樣的請(qǐng)求在 Envelope 里就不帶 context，從而省掉序列化和解析的開銷。這對(duì)傳統(tǒng)的 head sample 語(yǔ)義做了一點(diǎn)小改動(dòng)，但成功消除了 CPU 峰值問(wèn)題。

第二個(gè)優(yōu)化針對(duì) sessions 服務(wù)：在 fanout 過(guò)程中記錄 span 會(huì)讓 CPU 使用率提高 10 個(gè)百分點(diǎn)。Discord 選擇禁止 sessions 在接收到 fanout 消息后再開啟新的 trace。它們可以繼續(xù)已有的 trace，但不會(huì)自己決定是否采樣。這一改動(dòng)幾乎消除了所有額外開銷，把 CPU 使用率從 55% 降到 45%。

最顯著的一次優(yōu)化來(lái)自對(duì) gRPC 請(qǐng)求處理的分析。在 Elixir 服務(wù)和 Discord 的 Python API 交互時(shí)，有 75% 的請(qǐng)求處理時(shí)間都花在解析 trace context 上。團(tuán)隊(duì)為此做了一個(gè)過(guò)濾器，可以直接從編碼后的 trace context 字符串里讀取采樣標(biāo)志，而不需要完整反序列化。如果沒有被采樣，就完全不傳 context。

這套投入在最近一次故障中發(fā)揮了作用，當(dāng)時(shí)某個(gè)服務(wù)器跟不上用戶的活動(dòng)。追蹤數(shù)據(jù)顯示，用戶連接該服務(wù)器進(jìn)程時(shí)出現(xiàn)了長(zhǎng)達(dá) 16 分鐘的延遲——這是一個(gè)指標(biāo)和日志都很難直接看出來(lái)的用戶影響。追蹤還揭示了下游的連鎖反應(yīng)：故障期間用戶甚至無(wú)法點(diǎn)擊進(jìn)入這個(gè)服務(wù)器。

Discord 工程師 Nick Krichevsky 表示，這種嚴(yán)重性能下降雖然很少見，但分布式追蹤已經(jīng)成為排查問(wèn)題的關(guān)鍵手段——很多問(wèn)題“以前根本無(wú)從下手”。

Transport 這個(gè)庫(kù)代表了一種在 actor 系統(tǒng)中實(shí)現(xiàn)分布式追蹤的務(wù)實(shí)做法。它不是強(qiáng)行套用 HTTP 那種 metadata 模式，而是直接包裹 Elixir 的消息傳遞機(jī)制，讓 Discord 在保持原有架構(gòu)優(yōu)勢(shì)的同時(shí)，也獲得了可以支撐生產(chǎn)規(guī)模的可觀測(cè)性。

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。