簡介：?首屆云原生編程挑戰(zhàn)賽正在報名中，初賽共有三個賽道，本文主要針對賽道三題目做出剖析，幫助選手更高效的解題。

首屆云原生編程挑戰(zhàn)賽正在報名中，初賽共有三個賽道，題目如下：

賽道一：實現(xiàn)一個分布式統(tǒng)計和過濾的鏈路追蹤
賽道二：實現(xiàn)規(guī)模化容器靜態(tài)布局和動態(tài)遷移
賽道三：服務(wù)網(wǎng)格控制面分治體系構(gòu)建

立即報名（報名時間即日起至07/01）：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition

本文主要針對賽道一題目做出剖析，幫助選手更高效的解題。

背景

為了應(yīng)對各種復(fù)雜的業(yè)務(wù)，系統(tǒng)架構(gòu)也從單機(jī)大型軟件演化成微服務(wù)架構(gòu)。微服務(wù)構(gòu)建在不同的軟件集上，這些軟件模塊可能是由不同團(tuán)隊開發(fā)的，可能使用不同的編程語言來實現(xiàn)，還可能發(fā)布在多臺服務(wù)器上。因此，如果一個服務(wù)出現(xiàn)問題，可能導(dǎo)致幾十個服務(wù)都出現(xiàn)異常。

分布式追蹤系統(tǒng)用來記錄請求范圍內(nèi)的信息，用戶在頁面的一次點擊發(fā)送請求，這個請求的所有處理過程，比如經(jīng)過多少個服務(wù)，在哪些機(jī)器上執(zhí)行，每個服務(wù)的耗時和異常情況。可參考 鏈路追蹤的概念

采集鏈路數(shù)據(jù)過程中，采集的數(shù)據(jù)越多，消耗的成本就越多。為了降低成本，目前普遍的做法是對數(shù)據(jù)進(jìn)行采樣。請求是否采樣都是從的頭節(jié)點決定并通過跟蹤上下文透傳到所有節(jié)點(head-based sampling)。目前業(yè)界普遍的采樣都是按照這個方式，比如固定比例采樣(Probabilistic Sampling)，蓄水池采樣(Rate Limiting Sampling)，混合采樣(Adaptive Sample)。這樣的采樣可以保證整個調(diào)用鏈的完整性。但是這樣采樣也帶來兩個問題，一 有些異常和慢請求因為采樣的原因沒有被采集到，而這些鏈路數(shù)據(jù)對業(yè)務(wù)很重要。二 99%的請求都是正常的，而這些數(shù)據(jù)對問題排查并不重要，也就是說大量的成本花在并不重要的數(shù)據(jù)上。

本題目是另外一種采樣方式(tail-based Sampling)，只要請求的鏈路追蹤數(shù)據(jù)中任何節(jié)點出現(xiàn)重要數(shù)據(jù)特征（錯慢請求），這個請求的所有鏈路數(shù)據(jù)都采集（由分布式微服務(wù)的各個節(jié)點上產(chǎn)生），這種采樣方式在一些場景特別有效，比如錯慢全采，大客戶全采。目前開源的鏈路追蹤產(chǎn)品都沒有實現(xiàn)完整的tail-based Sampling，主要的挑戰(zhàn)是：任何節(jié)點出現(xiàn)符合采樣條件的鏈路數(shù)據(jù)，那就需要把這個請求的所有鏈路數(shù)據(jù)采集。即使這些鏈路數(shù)據(jù)在這個鏈路節(jié)點之前或者之后產(chǎn)生，即使這些鏈路數(shù)據(jù)在分布式系統(tǒng)的成百上千臺機(jī)器上。

一 賽題

首屆云原生編程挑戰(zhàn)賽1：實現(xiàn)一個分布式統(tǒng)計和過濾的鏈路追蹤鏈接

用戶需要實現(xiàn)兩個程序，一個是數(shù)量流（橙色標(biāo)記）的處理程序，該程序拉取數(shù)據(jù)后進(jìn)行處理，一個是后端程序（藍(lán)色標(biāo)記），和客戶端數(shù)據(jù)流處理程序（橙色標(biāo)記）通信，將最終數(shù)據(jù)結(jié)果在后端引擎上聚合。

架構(gòu)示例圖

賽題可以理解為很多組數(shù)據(jù)（trace）分布在兩臺機(jī)器上，任何一條數(shù)據(jù)（span）符合采集條件（ http.status_code 不為 200，或者 error 等于1），需要將這組數(shù)據(jù)（trace）從兩臺機(jī)器上采集下來，在后端程序上聚合匯總。

數(shù)據(jù)聚合過程如下圖

數(shù)據(jù)處理示例圖

二 賽題分析

賽題數(shù)據(jù)處理很簡單，就是一個map-reduce處理。 在實際場景中，無法將所有數(shù)據(jù)都上報進(jìn)行實時計算（全量上報的數(shù)據(jù)量非常大），需要在客戶端完成篩選，在服務(wù)端進(jìn)行聚合。

最大程度利用三臺分布式機(jī)器的資源
最簡單的解決方案是，在一臺機(jī)器上讀取多個數(shù)據(jù)流數(shù)據(jù)存放到一個文件中。跳過數(shù)據(jù)同步的過程，直接對這個文件做數(shù)據(jù)聚合。 這樣處理會帶來兩個問題，1，只利用單臺機(jī)器的資源，無法充分利用另外兩臺機(jī)器的資源。 2. 存放到文件中，涉及到讀寫硬盤，相比內(nèi)存處理會慢一些。
為了最大限度的利用三臺機(jī)器的資源，需要三者之間良好的協(xié)同。我們可以分析鏈路追蹤的場景，需要采集的數(shù)據(jù)占總數(shù)據(jù)的比例比較低。 那可以在數(shù)據(jù)處理層做第一次過濾，過濾后三臺機(jī)器只需要基于需要采集的數(shù)據(jù)進(jìn)行通信。
數(shù)據(jù)處理端的數(shù)據(jù)緩存，同步
每個節(jié)點都只有部分?jǐn)?shù)據(jù)，需要將數(shù)據(jù)進(jìn)行緩存，再將符合條件的數(shù)據(jù)在服務(wù)端聚合。
數(shù)據(jù)處理示例圖中，數(shù)據(jù)流1緩存了traceId:1,traceId:2,traceId:3. 檢測發(fā)現(xiàn)traceId：2符合采集條件。 數(shù)據(jù)流2也緩存了traceId:1,traceId:2,traceId:3，檢測發(fā)現(xiàn)traceId：3符合采集條件. 那最終只需要聚合traceId:2,traceId:3的數(shù)據(jù)。 traceId：1的數(shù)據(jù)不做任何處理。
在評測環(huán)境，數(shù)據(jù)流1和數(shù)據(jù)流2都大于4G的數(shù)據(jù)， 而處理數(shù)據(jù)流的機(jī)器內(nèi)存都只有4G，無法在內(nèi)存中做全量緩存。 那選手需要思考做流式緩存處理。在鏈路追蹤的真實場景中，會有時間窗口方式來處理，一般請求不會超過3分鐘，各個數(shù)據(jù)流節(jié)點同步時間窗口內(nèi)的數(shù)據(jù)。同步數(shù)據(jù)，那就需要保持各個接口數(shù)據(jù)的同步。而各個節(jié)點的數(shù)據(jù)處理有快有慢，同步的話，可能會block數(shù)據(jù)處理，對性能有影響。通用的解決方式是多個線程來處理，數(shù)據(jù)處理和數(shù)據(jù)同步分別兩個線程。，數(shù)據(jù)處理和線程拉取數(shù)據(jù)并處理，數(shù)據(jù)同步是對歷史數(shù)據(jù)做同步，例如數(shù)據(jù)處理示例圖中，在數(shù)據(jù)處理線程處理traceId：3時， 數(shù)據(jù)同步線程可以上報traceId：2的數(shù)據(jù)。
服務(wù)端的數(shù)據(jù)緩存，同步和聚合
服務(wù)端收集到這個節(jié)點的數(shù)據(jù)后，需要檢查各個節(jié)點數(shù)據(jù)是否齊全，如果齊全的話，那需要收集各個節(jié)點的數(shù)據(jù)，如果不齊全的話，那就需要繼續(xù)等待，甚至阻塞數(shù)據(jù)上報，直到數(shù)據(jù)齊全或者超時。比如說，采集某一段數(shù)據(jù)或者某一個時間窗口的數(shù)據(jù)時， 節(jié)點1的數(shù)據(jù)上報了，節(jié)點2數(shù)據(jù)未上報，那需要繼續(xù)等待節(jié)點2的數(shù)據(jù)。由于并發(fā)執(zhí)行的緣故，節(jié)點1的數(shù)據(jù)在持續(xù)上報，而節(jié)點2數(shù)據(jù)遲遲未上報，那就需要考慮超時，緩存清除，數(shù)據(jù)同步。
數(shù)據(jù)聚合時，題目對真實場景做了簡化。在真實場景中，需要同一個請求的所有數(shù)據(jù)（同一個traceId下的所有span）構(gòu)建調(diào)用關(guān)系的一顆樹。

實際場景中的鏈路詳情展示（阿里云鏈路追蹤產(chǎn)品）

簡化后，選手只需要根據(jù)數(shù)據(jù)的startTime做升序排序，生成checkSum（Md5）值,保證數(shù)據(jù)完整性的同時降低業(yè)務(wù)邏輯的強(qiáng)耦合。具體的Md5 計算可參考demo
其他的優(yōu)化點
rpc 建立長連接
demo程序采用的http方式，本地在服務(wù)端程序除了開放了8002端口，還開放了8003，8004端口。選手可以利用這些端口開啟長連接通信，比如dubbo，grpc，加快處理過程，提高性能。
多線程拉取
為了充分利用數(shù)據(jù)處理程序的機(jī)器資源，可以通過Rang方式多線程去拉取數(shù)據(jù)。
例如curl -H 'Range: bytes=200-2000' "http://localhost:8081/trace1.data"

三 賽題評測

評測環(huán)境由 1 臺 2 核 4G 的評測機(jī)，2 臺 2 核 4G 的數(shù)據(jù)流處理機(jī)器和 1 臺 1 核 2G 的后端服務(wù)組成。數(shù)據(jù)流處理機(jī)器和后端服務(wù)機(jī)器都會在docker內(nèi)運(yùn)行（docker 容器會限制 CPU 和內(nèi)存大小）。

用戶提交編譯好的docker image（不限定開發(fā)語言，分布式程序建議用go和java）
通過kubernetes的部署docker 容器
評測機(jī)器調(diào)用數(shù)據(jù)流處理機(jī)器和后端服務(wù)機(jī)器，檢查應(yīng)用是否啟動
評測機(jī)器發(fā)送評測數(shù)據(jù)的位置發(fā)給數(shù)據(jù)流處理機(jī)器和后端服務(wù)機(jī)器，并開始計時。
評測機(jī)器收到上報的接口，并進(jìn)行分值計算。
評測程序的跑分方式：將選手生成的結(jié)果同已知結(jié)果進(jìn)行對比，計算 F1 Score；同時記錄整個跑分從開始到輸出結(jié)果的時間 time，最后的比賽得分: F1/time。即 F1 值越大越好，耗時越小越好。

四 總結(jié)

本文結(jié)合首屆云原生挑戰(zhàn)賽的賽題背景、題目場景、題目分析和評測環(huán)境與過程的角度，介紹了分布式鏈路跟蹤系統(tǒng)的tail-based sampling的基本設(shè)計思路，希望對即將參加比賽的同學(xué)們能有所幫助，也歡迎更多的技術(shù)同學(xué)報名參加我們的挑戰(zhàn)賽，分享你在編程方面的思考和實踐。

五 更多

鏈路追蹤相關(guān)的介紹

鏈路追蹤的demo（需要開通鏈路追蹤服務(wù)，開通后不上報數(shù)據(jù)，不收取任何費用

apache 頂級項目skywalging，優(yōu)秀的開源的鏈路追蹤項目

云原生的可觀察性的開源項目opentelemetry

cncf的標(biāo)準(zhǔn)開源項目 jaeger

總結(jié)

以上是生活随笔為你收集整理的赛题解析 | 初赛赛道一：实现一个分布式统计和过滤的链路追踪的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。