事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法

李鵬，趙卓峰，李寒

事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法

李鵬1，2*，趙卓峰1，2，李寒1，2

（1.北方工業(yè)大學(xué) 信息學(xué)院，北京 100144； 2.大規(guī)模流數(shù)據(jù)集成與分析技術(shù)北京市重點實驗室（北方工業(yè)大學(xué)），北京 100144）（?通信作者電子郵箱lipeng_2@126.com）

微服務(wù)調(diào)用鏈路數(shù)據(jù)是微服務(wù)應(yīng)用系統(tǒng)日常運(yùn)行中產(chǎn)生的一類重要數(shù)據(jù)，它以鏈路形式記錄了微服務(wù)應(yīng)用中一次用戶請求對應(yīng)的一系列服務(wù)調(diào)用信息。由于系統(tǒng)的分布性，微服務(wù)調(diào)用鏈路數(shù)據(jù)產(chǎn)生在不同的微服務(wù)部署節(jié)點，當(dāng)前對這些分布數(shù)據(jù)的采集一般采用全量采集和采樣采集兩種方法。全量采集會產(chǎn)生較大數(shù)據(jù)傳輸和數(shù)據(jù)存儲等成本，而采樣采集則可能會漏掉關(guān)鍵的鏈路數(shù)據(jù)。因此，提出一種基于事件驅(qū)動和流水線采樣的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法，并基于開源軟件Zipkin設(shè)計實現(xiàn)了一個微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集系統(tǒng)。該系統(tǒng)首先對不同節(jié)點符合預(yù)定義事件特征的鏈路數(shù)據(jù)進(jìn)行流水線采樣，即數(shù)據(jù)采集服務(wù)端只在某節(jié)點產(chǎn)生事件定義的數(shù)據(jù)時對所有節(jié)點采集同一鏈路數(shù)據(jù)；同時，針對不同節(jié)點的數(shù)據(jù)產(chǎn)生速率不一致問題，采用基于時間窗口的多線程流式數(shù)據(jù)處理和數(shù)據(jù)同步技術(shù)實現(xiàn)不同節(jié)點的數(shù)據(jù)采集和傳遞；最后，針對各節(jié)點鏈路數(shù)據(jù)到達(dá)服務(wù)端先后順序不一的問題，通過時序?qū)R方式進(jìn)行全鏈路數(shù)據(jù)的同步和匯總。在公開的微服務(wù)調(diào)用鏈路數(shù)據(jù)集上的實驗結(jié)果表明，相較于全量采集和采樣采集方法，所提方法對于包含異常、慢響應(yīng)等特定事件的鏈路數(shù)據(jù)具有采集準(zhǔn)確性高、效率好的效果。

微服務(wù)；調(diào)用鏈路數(shù)據(jù)；動態(tài)采樣；事件匹配；緩存機(jī)制；服務(wù)鏈路追蹤

0 引言

微服務(wù)架構(gòu)正逐步成為當(dāng)前的一種主流軟件體系結(jié)構(gòu)，具有易擴(kuò)展、易維護(hù)、高可靠、高可用等特點［1］。相較于傳統(tǒng)單體式軟件架構(gòu)，它在軟件的開發(fā)、部署、維護(hù)和運(yùn)行環(huán)境容器化等方面也具有較大優(yōu)勢。微服務(wù)架構(gòu)的主要思想是：將傳統(tǒng)單體應(yīng)用根據(jù)業(yè)務(wù)邏輯和其功能拆分成一系列可以被獨(dú)立設(shè)計、開發(fā)、部署、運(yùn)維的軟件服務(wù)單元，并且在遵守服務(wù)邊界的前提下，各個微服務(wù)能夠彼此相互配合與協(xié)作來實現(xiàn)整個系統(tǒng)的價值［2］。但另一方面，隨著微服務(wù)架構(gòu)應(yīng)用系統(tǒng)復(fù)雜度越來越高，系統(tǒng)架構(gòu)變化日益頻繁，應(yīng)用中隱含的服務(wù)調(diào)用和依賴關(guān)系也越來越復(fù)雜。當(dāng)應(yīng)用涉及的某個服務(wù)出現(xiàn)問題，可能導(dǎo)致眾多其他服務(wù)都出現(xiàn)異常，從而給微服務(wù)應(yīng)用的可靠性保障、性能優(yōu)化和運(yùn)維管理等帶來諸多新的問題。為此，迫切需要對微服務(wù)應(yīng)用使用過程中涉及的微服務(wù)調(diào)用鏈路數(shù)據(jù)進(jìn)行有效的收集、記錄、管理和分析［3］。

服務(wù)鏈路追蹤系統(tǒng)［4］是為應(yīng)對上述挑戰(zhàn)而提出的一類微服務(wù)應(yīng)用支撐系統(tǒng)，它可以用來記錄微服務(wù)應(yīng)用的所有請求信息及請求背后涉及的一系列微服務(wù)調(diào)用信息，包括涉及的服務(wù)調(diào)用、對應(yīng)的機(jī)器、每個服務(wù)調(diào)用的耗時和異常情況等，并基于這些信息提供服務(wù)調(diào)用拓?fù)浞治觥⒄{(diào)用量統(tǒng)計、異常定位和風(fēng)險預(yù)測等分析功能以支持微服務(wù)應(yīng)用運(yùn)維［5］。由于這些信息可以根據(jù)對應(yīng)的請求被組織成一系列相關(guān)服務(wù)調(diào)用的數(shù)據(jù)鏈，因此被稱為服務(wù)調(diào)用鏈路。

微服務(wù)調(diào)用鏈路數(shù)據(jù)采集是服務(wù)鏈路追蹤系統(tǒng)的基礎(chǔ)功能。雖然豐富的鏈路數(shù)據(jù)會對后續(xù)的應(yīng)用分析提供有效的支持，然而在分布式環(huán)境下進(jìn)行鏈路數(shù)據(jù)采集時，由于原始監(jiān)控數(shù)據(jù)分布在一組不同的節(jié)點，所需采集的數(shù)據(jù)越多就需要消耗越多的跨節(jié)點數(shù)據(jù)傳輸和采集數(shù)據(jù)存儲等成本。因此，隨著微服務(wù)應(yīng)用規(guī)模及訪問數(shù)量的增大，對服務(wù)調(diào)用鏈路數(shù)據(jù)進(jìn)行全量采集變得愈發(fā)困難。為此，當(dāng)前研究者的一種思路是對鏈路數(shù)據(jù)通過不同的采樣方式進(jìn)行采集，即只按照一定的采樣策略對相應(yīng)的鏈路數(shù)據(jù)進(jìn)行采集，從而降低鏈路數(shù)據(jù)采集的代價。

采樣策略一般有定頻采樣［6］、固定比例采樣（Probabilistic Sampling）［7］、蓄水池采樣（Rate Limiting Sampling）［8］等不同方式。定頻采樣按照給定的采樣頻率對鏈路數(shù)據(jù)進(jìn)行收集，如圖1所示的每間隔3 s對鏈路數(shù)據(jù)進(jìn)行一次采集。固定比例采樣中的固定比例是指不考慮樣品變異性的大小，按統(tǒng)一的比例進(jìn)行采樣，并維持采集到的鏈路完整性。蓄水池采樣是對于一個不知道大小的集合（通常是流式數(shù)據(jù)），抽取的樣本值能夠保證隨機(jī)，每個樣本被選中的概率都是相等的，適用于對一個不清楚規(guī)模的數(shù)據(jù)集進(jìn)行采樣。

上述采樣方法本質(zhì)上仍是由鏈路追蹤系統(tǒng)預(yù)定義的固定采集方法，系統(tǒng)確定采樣采集的靜態(tài)策略，而采集功能的核心問題就在于保證服務(wù)調(diào)用鏈的完整性。這類采樣采集方法雖然可以減少一定的數(shù)據(jù)采集成本，但仍存在兩個方面的問題：一是一些具有特定信息（如異常、響應(yīng)慢或超時等）的鏈路數(shù)據(jù)可能由于不在采樣策略范圍內(nèi)而被遺漏，而這些鏈路數(shù)據(jù)對后續(xù)鏈路分析具有重要意義；二是此方式下采集的大量鏈路數(shù)據(jù)都是微服務(wù)正常情況下的相似信息，而這些信息在鏈路分析中意義有限，也就意味著仍然會產(chǎn)生較大的不必要采集成本。

圖1　定頻采樣示意圖

針對上述問題，本文提出了一種基于事件驅(qū)動的鏈路數(shù)據(jù)動態(tài)采集方法。在該方法下，需要對所需采集的服務(wù)調(diào)用鏈路在任意微服務(wù)節(jié)點的數(shù)據(jù)信息由節(jié)點客戶端根據(jù)事件特征進(jìn)行實時判定，如果發(fā)現(xiàn)符合預(yù)定義事件的數(shù)據(jù)特征，則該數(shù)據(jù)所對應(yīng)的服務(wù)鏈路在所有微服務(wù)節(jié)點的數(shù)據(jù)才會在系統(tǒng)服務(wù)端協(xié)調(diào)下被動態(tài)地采集。事件特征是指面向用戶關(guān)心的服務(wù)鏈路數(shù)據(jù)包含的數(shù)據(jù)內(nèi)容，如特定錯誤狀態(tài)碼、超時標(biāo)記或者符合特定規(guī)則的數(shù)據(jù)等。這些用戶指定的特定數(shù)據(jù)內(nèi)容以預(yù)定義的方式儲存在特征數(shù)據(jù)庫中并分發(fā)給各微服務(wù)節(jié)點。該方法的難點在于如何在各分布節(jié)點上利用有限的資源快速發(fā)現(xiàn)符合事件定義的鏈路數(shù)據(jù)以及獲取與該鏈路對應(yīng)的所有相關(guān)數(shù)據(jù)并發(fā)送到鏈路追蹤系統(tǒng)服務(wù)端。

圍繞上述思路，本文開展的主要工作包括：

1）微服務(wù)節(jié)點鏈路事件特征定義方法及流式識別機(jī)制。給出了基于正則表達(dá)式的鏈路事件定義方法，并采用流計算模型對各節(jié)點實時產(chǎn)生的鏈路數(shù)據(jù)不間斷地進(jìn)行預(yù)定義事件的判定，及時發(fā)現(xiàn)包含事件特征的微服務(wù)調(diào)用鏈路。

2）基于多線程的多節(jié)點鏈路數(shù)據(jù)高效獲取與緩存機(jī)制。對各微服務(wù)節(jié)點一定時間周期的鏈路數(shù)據(jù)采用Hash B樹結(jié)構(gòu)進(jìn)行緩存，并在鏈路追蹤系統(tǒng)服務(wù)端發(fā)出特定鏈路數(shù)據(jù)請求時提供一種相應(yīng)的查詢算法以快速獲取相應(yīng)的鏈路數(shù)據(jù)。

3）服務(wù)端全鏈路數(shù)據(jù)同步和匯總機(jī)制。提出一種服務(wù)端和節(jié)點端的同步機(jī)制，以支持?jǐn)?shù)據(jù)采集服務(wù)端與各微服務(wù)節(jié)點控制交互和數(shù)據(jù)收集，并在服務(wù)端實現(xiàn)根據(jù)鏈路標(biāo)識對來自不同節(jié)點的時序錯亂數(shù)據(jù)進(jìn)行對齊和匯總，以得到一個完整的服務(wù)調(diào)用鏈路數(shù)據(jù)。

1 背景知識

1.1　鏈路追蹤

“鏈路追蹤”一詞最早出現(xiàn)在谷歌發(fā)表的分布式鏈路追蹤系統(tǒng)Dapper［9］論文中。如圖2給出了一個微服務(wù)調(diào)用鏈路追蹤的概念示意，圖中展示了一個與用戶請求響應(yīng)過程對應(yīng)的服務(wù)調(diào)用鏈路，其中涉及五個相關(guān)的微服務(wù)，包括：前端微服務(wù)（A），兩個中間層微服務(wù)（B和C），以及兩個后端微服務(wù)（D和E）。當(dāng)用戶發(fā)起一個請求時，首先到達(dá)前端微服務(wù)A，然后發(fā)送兩個遠(yuǎn)程過程調(diào)用（Remote Procedure Call， RPC）調(diào)用到微服務(wù)B和C。B會立即作出響應(yīng)，但是C需要與后端的微服務(wù)D和E交互之后再響應(yīng)結(jié)果給A，最后再由A來響應(yīng)最初的用戶請求。像圖2的服務(wù)鏈路追蹤過程，每一次發(fā)送和接收動作的跟蹤標(biāo)識符和時間戳都會被收集到。

微服務(wù)調(diào)用鏈路的定義主要包括兩個核心概念：Trace和Span。Trace對應(yīng)一次請求涉及的所有服務(wù)調(diào)用組成的調(diào)用鏈，即一個Trace包含一組Span。Span表示每一次對微服務(wù)的調(diào)用，它是調(diào)用鏈路的基本單元。每個Span包括對應(yīng)的traceid、調(diào)用起始時間、標(biāo)注、日志、相關(guān)Span等信息。Span之間具有父子和跟隨兩種關(guān)系，分別表示父Span對應(yīng)微服務(wù)對子Span對應(yīng)微服務(wù)之間的直接調(diào)用關(guān)系（如圖2中A到B和C的調(diào)用關(guān)系）以及沒有調(diào)用依賴（不依賴被調(diào)用微服務(wù)的結(jié)果，只有先后關(guān)系）的特殊父子關(guān)系。表1給出了一個服務(wù)調(diào)用鏈路數(shù)據(jù)的示例。

圖2　服務(wù)鏈路追蹤示意圖

表1　服務(wù)調(diào)用鏈路數(shù)據(jù)示例

1.2　鏈路追蹤系統(tǒng)

Dapper系統(tǒng)開始只具有調(diào)用鏈路追蹤功能，后來逐漸演化成了監(jiān)控平臺，并且基于監(jiān)控平臺擴(kuò)展出了很多工具，如實時預(yù)警、過載保護(hù)、指標(biāo)數(shù)據(jù)查詢等。除了谷歌的Dapper，還有一些其他知名的鏈路追蹤系統(tǒng)，如阿里的鷹眼、美團(tuán)的CAT［10］、Twitter的Zipkin［11］、Apache的SkyWalking［12］等。雖然這些系統(tǒng)各有特點，但一般都包括四部分核心內(nèi)容：鏈路數(shù)據(jù)采集、鏈路數(shù)據(jù)存儲、數(shù)據(jù)查詢分析和數(shù)據(jù)展示。本文以Zipkin為例具體說明鏈路追蹤系統(tǒng)的體系架構(gòu)和網(wǎng)絡(luò)拓?fù)洹?/p>

如圖3所示，在Zipkin系統(tǒng)架構(gòu)中，分布式系統(tǒng)由一組節(jié)點組成，它一般與微服務(wù)部署的節(jié)點一一對應(yīng)，在節(jié)點上部署系統(tǒng)客戶端，負(fù)責(zé)處理和緩存該節(jié)點上的服務(wù)調(diào)用數(shù)據(jù)，并以REST API接口的形式對外提供數(shù)據(jù)獲取支持。圖中虛線框內(nèi)包含負(fù)責(zé)各節(jié)點數(shù)據(jù)收集和匯總的Collector、負(fù)責(zé)數(shù)據(jù)存儲的Storage以及數(shù)據(jù)查詢展示的RESTful API和Web UI，可以看作是Zipkin系統(tǒng)的服務(wù)端。其中與服務(wù)鏈路數(shù)據(jù)采集相關(guān)的主要是由多個節(jié)點構(gòu)成的分布式系統(tǒng)部分和服務(wù)端的Collector［11］。

產(chǎn)生微服務(wù)調(diào)用數(shù)據(jù)的各分布式節(jié)點客戶端和服務(wù)端的Collector進(jìn)行數(shù)據(jù)交互時有全量采集和抽樣采集兩種方式。由于目前采樣方式的限制，全量采集耗時多、速度慢，而抽樣采集會導(dǎo)致一些關(guān)鍵調(diào)用數(shù)據(jù)沒有被采集到，或者只是捕捉到具有關(guān)鍵信息的某條調(diào)用鏈路的部分?jǐn)?shù)據(jù)（部分Span），不能得到整體的Trace（所有Span）。這些情況在微服務(wù)應(yīng)用異常分析和Debug調(diào)試時會帶來不利的影響。

綜上所述，當(dāng)前的服務(wù)調(diào)用鏈路系統(tǒng)在實際應(yīng)用中只考慮抽樣采集數(shù)據(jù)，對于符合用戶請求特征的調(diào)用鏈路數(shù)據(jù)可能因為該采樣方式而無法捕捉到，導(dǎo)致不能準(zhǔn)確分析鏈路信息。而且完整的服務(wù)調(diào)用鏈路數(shù)據(jù)可能分布在不同節(jié)點，不同節(jié)點上的微服務(wù)調(diào)用數(shù)據(jù)在時間上可能有前有后，同時隨著每個節(jié)點產(chǎn)生大量不同請求的調(diào)用鏈路，對符合請求特征的調(diào)用鏈路數(shù)據(jù)采集就變得更加困難。因此，本文設(shè)計了一種事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法解決上述問題。

圖3　Zipkin系統(tǒng)架構(gòu)

2 事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集

2.1　方法思想和核心流程

如圖4所示，事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法的核心思想是一種由服務(wù)調(diào)用數(shù)據(jù)源節(jié)點根據(jù)事件識別結(jié)果觸發(fā)進(jìn)行鏈路數(shù)據(jù)采集的方式［13］。

首先，需要在微服務(wù)調(diào)用數(shù)據(jù)生成的節(jié)點端給出一種事件特征定義方式以及服務(wù)調(diào)用數(shù)據(jù)上的實時事件識別機(jī)制。考慮到服務(wù)調(diào)用數(shù)據(jù)的實時性，采用流計算模型對各節(jié)點實時產(chǎn)生的鏈路數(shù)據(jù)進(jìn)行預(yù)定義事件的判定，及時發(fā)現(xiàn)包含事件特征的微服務(wù)調(diào)用鏈路信息。

其次，在某節(jié)點發(fā)現(xiàn)符合事件特征的調(diào)用數(shù)據(jù)后，會與服務(wù)端進(jìn)行交互并由服務(wù)端協(xié)調(diào)所有節(jié)點（廣播方式），將一定時間范圍內(nèi)的相關(guān)鏈路數(shù)據(jù)收集到服務(wù)端。為此，各節(jié)點需要對一定時間周期內(nèi)的鏈路數(shù)據(jù)進(jìn)行緩存，并設(shè)計與之匹配的查詢算法，以獲取服務(wù)端所需數(shù)據(jù)。

最后，服務(wù)端對來自不同節(jié)點的鏈路數(shù)據(jù)進(jìn)行匯總，以形成完整的服務(wù)調(diào)用全鏈路數(shù)據(jù)。匯總過程中，考慮到網(wǎng)絡(luò)通信影響，需要按照鏈路標(biāo)識對各節(jié)點數(shù)據(jù)進(jìn)行同步和基于時序的對齊。

圖4　事件驅(qū)動的調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法流程

根據(jù)上述思想，事件驅(qū)動的微服務(wù)調(diào)用鏈路數(shù)據(jù)動態(tài)采集方法如下：

當(dāng)任何節(jié)點出現(xiàn)符合采樣條件的鏈路數(shù)據(jù)時（重要特征數(shù)據(jù)），就采集該請求的所有鏈路數(shù)據(jù)，由于跨節(jié)點的調(diào)用鏈路在全局上是無序的，且同一服務(wù)調(diào)用鏈中發(fā)生也有前后時間順序，為此，動態(tài)全量采集方法利用有限的資源快速找到符合采樣條件的服務(wù)調(diào)用鏈路。

數(shù)據(jù)處理客戶端首先從每個節(jié)點拉取鏈路數(shù)據(jù)，在數(shù)據(jù)處理層做第一次過濾操作，進(jìn)行初步的數(shù)據(jù)清洗，為了盡快高效地進(jìn)行異常鏈路追蹤，利用客戶端的內(nèi)存進(jìn)行緩存，但由于內(nèi)存空間有限，無法在內(nèi)存中做全量緩存，需要做流式緩存處理，可采用基于時間窗口的方式來處理，找到異常鏈路的traceid發(fā)送到服務(wù)器端。

數(shù)據(jù)匯總服務(wù)端接收到客戶端的異常鏈路的traceid后，再去廣播發(fā)送到每個數(shù)據(jù)客戶端。由于各個節(jié)點的數(shù)據(jù)處理速度不一，且存在并發(fā)執(zhí)行的現(xiàn)象，導(dǎo)致某些節(jié)點的數(shù)據(jù)持續(xù)上報，而另外的其他節(jié)點數(shù)據(jù)遲遲未上報，這就需要考慮超時處理，清除緩存，實現(xiàn)數(shù)據(jù)同步。本文方法計劃采用多個線程來處理，可分為數(shù)據(jù)處理和數(shù)據(jù)同步線程。

為了實現(xiàn)上述思想和流程，本文方法主要包括三部分內(nèi)容：

1）微服務(wù)節(jié)點鏈路事件特征定義方法及流式識別機(jī)制；

2）基于多線程的多節(jié)點鏈路數(shù)據(jù)緩存和高效獲取機(jī)制；

3）服務(wù)端全鏈路數(shù)據(jù)同步和匯總機(jī)制。

2.2　微服務(wù)節(jié)點鏈路事件特征定義方法及流式識別機(jī)制

2.2.1特征事件的定義

特征事件是指含有重要特征的鏈路數(shù)據(jù)。預(yù)定義事件特征，以便識別特定事件，及時發(fā)現(xiàn)包含事件數(shù)據(jù)特征的微服務(wù)調(diào)用鏈路信息。

本文分為以下三類事件：

1）錯請求，指鏈路數(shù)據(jù)中包含錯誤信息或鏈路數(shù)據(jù)無具體信息。

2）慢響應(yīng)，指鏈路請求時間過長導(dǎo)致一次請求超時。

3）異常請求，指調(diào)用鏈路請求信息中有類似http異常狀態(tài)碼。

節(jié)點中的鏈路數(shù)據(jù)存儲于客戶端緩存，客戶端對其進(jìn)行處理分析，根據(jù)事件預(yù)定義的規(guī)則匹配到的特征鏈路數(shù)據(jù)，將其記錄于特定的數(shù)據(jù)結(jié)構(gòu)為下一步作準(zhǔn)備。

事件匹配采用字符串匹配和正則表達(dá)式的方法。

字符串匹配較為簡單，因大部分請求基于http協(xié)議，包含HTTP狀態(tài)碼的信息頭，所以在特征數(shù)據(jù)庫中定義與狀態(tài)碼相對應(yīng)的字符串，如Code=500、Code=503、Code=505、Code=404、Code=403等。該方式匹配簡單、快速，但規(guī)則固定，匹配范圍小。

正則表達(dá)式［14］描述了一種字符串匹配的模式，檢查鏈路數(shù)據(jù)是否包含具有某種語法規(guī)則的字符串，是對字符串匹配的加強(qiáng)和完善。

根據(jù)正則表達(dá)式的基本規(guī)則，采集到的鏈路數(shù)據(jù)URL正則表達(dá)式為：/http［s］｛0，1｝：//（［w.］+/？）S*/，最終表達(dá)式為：*^［a-z］+：//（［a-z0-9］｛1｝［a-z0-9_-］*.）*（［a-z0-9］+.）*［a-z0-9］+（/［^f v］*）*$*/。

2.2.2基于流處理的事件識別

采用流計算模型對各節(jié)點客戶端實時產(chǎn)生的鏈路數(shù)據(jù)不間斷進(jìn)行特征事件的判定，及時發(fā)現(xiàn)包含數(shù)據(jù)特征的微服務(wù)調(diào)用鏈路信息。

利用緩存機(jī)制和預(yù)定義的事件匹配規(guī)則，快速高效地找到事件數(shù)據(jù)特征的鏈路信息。

基于流處理的事件識別如算法1所示，首先將數(shù)據(jù)與預(yù)定義的事件規(guī)則進(jìn)行匹配，若匹配到則符合含有數(shù)據(jù)特征的鏈路信息，將其保存到errorSet中，否則保存到traceMap中。

算法1 流處理的事件識別算法。

輸入 調(diào)用鏈路數(shù)據(jù)流；

輸出 存放事件匹配特征數(shù)據(jù)traceid的errorSet；緩存中鏈路數(shù)據(jù)traceMap。

1） If 數(shù)據(jù)流匹配預(yù)定義的事件規(guī)則

2） 該數(shù)據(jù)保存到緩存的errorSet中

3） Else

4） 數(shù)據(jù)保存到緩存中的traceMap中

5） End If

6） If 緩存大小超過設(shè)置的緩存大小

7） 客戶端停止拉取數(shù)據(jù)

8） End If

2.3　基于多線程的多節(jié)點鏈路數(shù)據(jù)緩存和高效獲取機(jī)制

在某客戶端節(jié)點發(fā)現(xiàn)符合事件特征的調(diào)用數(shù)據(jù)后，會與服務(wù)端進(jìn)行交互并由服務(wù)端協(xié)調(diào)所有節(jié)點（廣播方式）將一定時間范圍內(nèi)的相關(guān)鏈路數(shù)據(jù)進(jìn)行匯總。隨著調(diào)用鏈路數(shù)據(jù)增多，客戶端內(nèi)存有限，數(shù)據(jù)無法實現(xiàn)全量緩存。為此，本文設(shè)計了一種基于客戶端節(jié)點的流式緩存處理機(jī)制，采用時間窗口方式來處理緩存數(shù)據(jù)，找到異常鏈路的traceid，將其發(fā)送到服務(wù)器端，并設(shè)計了一種高效查詢算法以獲取服務(wù)端所需數(shù)據(jù)。

通過進(jìn)一步分析原始調(diào)用鏈路數(shù)據(jù)，由于調(diào)用鏈路采用OpenTracing規(guī)范［15］，每一個trace類似樹結(jié)構(gòu)，所以采用Hash B樹結(jié)構(gòu)來存儲客戶端緩存。

Hash B樹算法是結(jié)合了支持快速查詢的Hash算法和支持樹結(jié)構(gòu)全值匹配的B Tree索引算法［16-18］，可以快速高效地查詢緩存中的數(shù)據(jù)。

客戶端節(jié)點的微服務(wù)調(diào)用數(shù)據(jù)緩存結(jié)構(gòu)如圖5所示。traceid由Hash數(shù)組存儲，當(dāng)查找某traceid時，利用Hash算法快速查找到所在數(shù)組的位置，通過B Tree索引進(jìn)一步查詢具體所需要的span鏈。

圖5　微服務(wù)調(diào)用數(shù)據(jù)緩存結(jié)構(gòu)

本文采用的Hash B樹結(jié)構(gòu)，客戶端緩存大小設(shè)計為1 GB，最大容量為200萬條（每條數(shù)據(jù)最大約為500 B）。緩存采用hashMap的K?V存儲結(jié)構(gòu)，方便快速根據(jù)traceid讀取到整條trace信息。

算法2 多節(jié)點流處理算法。

輸入 調(diào)用鏈路數(shù)據(jù)流；

輸出 存放事件匹配特征數(shù)據(jù)traceid的errorSet；緩存中鏈路數(shù)據(jù)traceMap。

1） List>> Queue=new LinkedList<>（）； //環(huán)形隊列

2） Set errorSet = new Set<>（）； //errorSet保存事件特征數(shù)據(jù)的traceid

6） Map> map =ConcurrentHashMap<>（）； //保證線程安全

7） IF（map.get（key）！= null）

8） map.get（key）.add（value）；

9） Else

10） List list = New ArrayList<>（）；

11） list.add（value）；

12） map.put（key，list）；

13） END IF

14） IF value包含特征事件

15） errorSet.add（key）；

16） traceMap=map.get（key）；

17） END IF

18） END FOR

19） RETURN errorSet，traceMap

如算法2所示，在向緩存中存儲數(shù)據(jù)之前，根據(jù)預(yù)定義的事件規(guī)則，若匹配到含有重要特征的事件，則將該traceid存放到errorSet中，若緩存接近0.8 GB或超過0.8 GB，客戶端則減緩拉取數(shù)據(jù)的速度，避免緩存溢出導(dǎo)致客戶端處理崩潰。根據(jù)errorSet中的traceid，從Map中找到該traceid的所有調(diào)用鏈span，由于trace是全局無序的，可能另外的客戶端含有異常信息的某條trace在該客戶端卻是正常的，但也要完成采集，所以必須等待所有客戶端同一批次的數(shù)據(jù)流緩存處理完成后再進(jìn)行緩存清理?？蛻舳颂幚砗蟀l(fā)送完成一個信號量給服務(wù)端，然后等待服務(wù)端響應(yīng)。

2.4　服務(wù)端全鏈路數(shù)據(jù)匯總和同步機(jī)制

基于事件驅(qū)動動態(tài)采樣方法對CPU和內(nèi)存要求較低，在有限的物理資源下能充分利用內(nèi)存資源，快速準(zhǔn)確地采集重要特征數(shù)據(jù)。當(dāng)節(jié)點數(shù)量變多時，如果客戶端節(jié)點之間直接通信會使得整體客戶端處理變得復(fù)雜，不易維護(hù)。故本文采用客戶端節(jié)點與服務(wù)端節(jié)點之間通信來實現(xiàn)整體系統(tǒng)的通信。

服務(wù)端負(fù)責(zé)對各個客戶端節(jié)點發(fā)送的traceid進(jìn)行匯總，并將匯總的信息廣播同步到所有客戶端，并對客戶端發(fā)來的調(diào)用鏈路span歸并處理。

1）數(shù)據(jù)匯總。數(shù)據(jù)匯總分兩部分：一是對多個客戶端發(fā)來的traceid進(jìn)行匯總，及時更新traceMap（保存的是含有錯誤信息的鏈路的traceid）；二是對客戶端發(fā)送的調(diào)用鏈路span進(jìn)行歸并，按調(diào)用時間和traceid拼接成一條完整的trace。

2）廣播同步。通過廣播的方式，發(fā)送更新好的traceMap到各個客戶端，使各個客戶端同步接收到最新的搜索條件。由于可能含有錯誤信息的相同traceid鏈路分布在另外的節(jié)點上，當(dāng)前的節(jié)點客戶端也需要遍歷該traceid鏈路數(shù)據(jù)并發(fā)送給服務(wù)端，以此保持監(jiān)控到的鏈路完整準(zhǔn)確。

3）實現(xiàn)重要特征數(shù)據(jù)同步機(jī)制。圖6表示某個客戶端與服務(wù)器之間的交互，同一批次的數(shù)據(jù)流緩存處理完成后，客戶端向服務(wù)端發(fā)送信號，等待服務(wù)端響應(yīng)。當(dāng)接收到服務(wù)端響應(yīng)報文時，響應(yīng)報文中包含服務(wù)端聚合所有的客戶端節(jié)點的異常調(diào)用鏈路的traceid，數(shù)據(jù)同步線程會向服務(wù)端發(fā)送errorSet中traceid的所有調(diào)用鏈，數(shù)據(jù)處理線程再根據(jù)響應(yīng)報文中traceid搜索當(dāng)前客戶端節(jié)點數(shù)據(jù)流緩存，若找到則發(fā)送到服務(wù)端。

圖6　客戶端流處理與重要特征數(shù)據(jù)同步機(jī)制

3 系統(tǒng)實現(xiàn)

為了驗證本文動態(tài)采樣方法的準(zhǔn)確性和高效性，基于動態(tài)采樣方式設(shè)計實現(xiàn)了一個微服務(wù)調(diào)用鏈路數(shù)據(jù)采集系統(tǒng)［19-21］，如圖7所示。在該系統(tǒng)中，處理對象是由各個服務(wù)模塊之間通信產(chǎn)生的調(diào)用鏈路數(shù)據(jù)，輸出為帶有異常標(biāo)記的所有調(diào)用鏈路數(shù)據(jù)。該框架由三個主要階段構(gòu)成，自頂向下包括調(diào)用鏈路生成階段、收集和處理階段、存儲階段。各階段描述如下：

1）調(diào)用鏈路生成階段。指根據(jù)服務(wù)模塊間的通信和調(diào)用生成的請求響應(yīng)鏈路，利用Zipkin進(jìn)行埋點，生成帶有時間戳、服務(wù)名、ip等信息的調(diào)用鏈路；然后將生成的調(diào)用鏈路寫入到分布式的每個節(jié)點的日志中。

2）收集和處理階段。鏈路收集階段是從每個節(jié)點的日志數(shù)據(jù)以數(shù)據(jù)流的形式不斷輸入到服務(wù)處理集群。本文采用動態(tài)采樣的方法，捕捉所有含有異常信息的traceid鏈路，更加快捷地處理數(shù)據(jù)和減少網(wǎng)絡(luò)輸出，充分利用內(nèi)存資源。

3）儲存階段。將最終捕捉分析到的鏈路數(shù)據(jù)存到數(shù)據(jù)庫，并提供查詢接口。

圖7　微服務(wù)調(diào)用鏈路數(shù)據(jù)采集系統(tǒng)架構(gòu)

4 實驗與結(jié)果分析

4.1　實驗環(huán)境

為了驗證動態(tài)采集方法的準(zhǔn)確率和性能，本實驗準(zhǔn)備50個客戶端docker容器，1個服務(wù)端docker容器?？蛻舳薈PU采用英特爾Pentium 雙核E5400@2.6 GHz，內(nèi)存大小為1 GB；服務(wù)端CPU采用英特爾Pentium雙核E5400@2.6 GHz，內(nèi)存大小為2 GB。

4.2　數(shù)據(jù)集

數(shù)據(jù)集采用阿里開放的服務(wù)調(diào)用鏈路數(shù)據(jù)，共包含兩個大小為8 GB的調(diào)用鏈路日志數(shù)據(jù)。本文對數(shù)據(jù)格式進(jìn)行了簡化，每行數(shù)據(jù)（即一個span）包含如下屬性：

1）traceid：全局唯一的id，用作整個鏈路的唯一標(biāo)識與組裝。

2）startTime：調(diào)用的開始時間。

3）spanid：調(diào)用鏈中某條數(shù)據(jù)（span）的id。

4）parentSpanid：調(diào)用鏈中某條數(shù)據(jù)（span）的父親id，頭節(jié)點的span的parantSpanId為0。

5）duration：調(diào)用耗時。

6）serviceName：調(diào)用的服務(wù)名。

7）spanName：調(diào)用的埋點名。

8）host：機(jī)器標(biāo)識，比如ip、機(jī)器名。

9）tags：鏈路信息中tag信息，存在多個tag的key和value信息。一般的服務(wù)調(diào)用鏈路數(shù)據(jù)格式為key1=val1&key2=val2&key3=val3，比如含有類似格式的：http.status_code=200&error=1。

4.3　實驗評價

本節(jié)對異常鏈路追蹤的準(zhǔn)確率和采集時間進(jìn)行驗證，并探究了客戶端節(jié)點數(shù)量對本文方法的影響。

1）準(zhǔn)確率。指希望采集到的服務(wù)鏈路數(shù)據(jù)占所有采集到的鏈路數(shù)據(jù)的比值，是評估一個采集方法好壞的主要指標(biāo)。為驗證動態(tài)采樣方法的準(zhǔn)確率，與定頻采樣方法進(jìn)行對比，如圖8所示，定頻采樣方法每間隔0.2 s采樣一次，隨著數(shù)據(jù)量的增大，定頻采樣找到含有重要特征的異常鏈路數(shù)據(jù)準(zhǔn)確率逐漸降低，且降低幅度較大，而本文方法依舊保持較高的準(zhǔn)確率，準(zhǔn)確率接近百分之百（由于時間窗口的限制性可能導(dǎo)致少量數(shù)據(jù)會丟失）。

圖8　準(zhǔn)確率測試結(jié)果

2）采集時間。響應(yīng)速度是評價一個監(jiān)測方法的主要指標(biāo)，采集時間越短，表明該方法效率越高。如圖9所示，隨著數(shù)據(jù)量的增加，本文的動態(tài)采集方法采集異常鏈路的時間比全量采集方法所用時間更少，且數(shù)據(jù)量較大時，本文提出的動態(tài)采樣方法更高效。

圖9　兩種方法的采集時間比較

3）客戶端節(jié)點數(shù)量對本文方法影響。如圖10所示，當(dāng)客戶端節(jié)點越來越多，則處理的線程越多，采集時間耗時少，速度快。數(shù)據(jù)量越大，客戶端節(jié)點數(shù)對采集時間影響越大，節(jié)點數(shù)越多，性能越好。

圖10　多客戶端節(jié)點采集時間比較

5 結(jié)語

本文提出了一種針對調(diào)用鏈路進(jìn)行故障排查和異常鏈路信息監(jiān)控的高效動態(tài)采樣方法，并基于動態(tài)采樣方式設(shè)計實現(xiàn)了一個微服務(wù)調(diào)用鏈路采集系統(tǒng)，能夠在分布式系統(tǒng)快速追蹤到含有標(biāo)記信息的鏈路，可用于鏈路故障追蹤和錯誤分析。通過緩存技術(shù)和通信機(jī)制實現(xiàn)了在有限資源內(nèi)快速找到含有重要特征的所有鏈路數(shù)據(jù)，并保持調(diào)用鏈路的連貫性。該方法彌補(bǔ)了單節(jié)點處理數(shù)據(jù)慢、全量查詢耗時較長和無事件匹配機(jī)制的抽樣采集不準(zhǔn)確的缺點。實驗結(jié)果顯示，本文方法對于包含異常信息的鏈路數(shù)據(jù)具有采集的精準(zhǔn)性和高效性。下一步將進(jìn)一步增加鏈路數(shù)據(jù)集的數(shù)量，基于大數(shù)據(jù)平臺搭建微服務(wù)調(diào)用鏈路應(yīng)用，并與當(dāng)前其他利用大數(shù)據(jù)框架處理方法進(jìn)行比較。

[1] NEWMAN S. 微服務(wù)設(shè)計［M］. 崔力強(qiáng)，張駿，譯. 北京：人民郵電出版社， 2016：263-266.（NEWMAN S. Building Microservices［M］. CUI L Q， ZHANG J. Beijing： Posts and Telecom Press， 2016：263-266.）

[2] 辛園園，鈕俊，謝志軍，等. 微服務(wù)體系結(jié)構(gòu)實現(xiàn)框架綜述［J］. 計算機(jī)工程與應(yīng)用， 2018， 54（19）：10-17.（XIN Y Y， NIU J， XIE Z J， et al. Survey of implementation framework for microservices architecture［J］. Computer Engineering and Applications， 2018， 54（19）： 10-17.）

[3] 李春陽，劉迪，崔蔚，等. 基于微服務(wù)架構(gòu)的統(tǒng)一應(yīng)用開發(fā)平臺［J］. 計算機(jī)系統(tǒng)應(yīng)用， 2017， 26（4）：43-48.（LI C Y， LIU D， CUI W， et al. Unified application development platform based on micro?service architecture［J］. Computer Systems and Applications， 2017， 26（4）： 43-48.）

[4] 楊勇，李影，吳中海. 分布式追蹤技術(shù)綜述［J］. 軟件學(xué)報， 2020， 31（7）：2019-2039.（YANG Y， LI Y， WU Z H. Survey of state?of?the?art distributed tracing technology［J］. Journal of Software， 2020， 31（7）：2019-2039.）

[5] 陸龍龍. 分布式鏈路跟蹤系統(tǒng)的設(shè)計與實現(xiàn)［D］. 南京：南京大學(xué)， 2018：21-30.（LU L L. The design and implementation of distributed tracing system［D］. Nanjing： Nanjing University， 2018： 21-30.）

[6] 劉家嚴(yán). 定頻采樣變窗口周期信號幅值計算［J］. 計算機(jī)產(chǎn)品與流通， 2020（4）：282-282.（LIU J Y. Amplitude calculation of fixed frequency sampling variable window periodic signal［J］. Computer Products and Circulation， 2020（4）：282-282.）

[7] CAMALAN M. Simulating probabilistic sampling on particle populations to assess the threshold sample sizes for particle size distributions［J］. Particulate Science and Technology， 2021， 39（4）： 511-520.

[8] KONDAPALLI R. Packet sampling using rate?limiting mechanisms： 20070258370［P］. 2007-11-08.

[9] SIGELMAN B H， BARROSO L A， BURROWS M， et al. Dapper， a large?scale distributed systems tracing infrastructure： Google Technical Report dapper?2010?1［R/OL］. ［2021-09-21］.http：//people.csail.mit.edu/matei/courses/2015/6.S897/readings/dapper.pdf.

[10] 任天. CAT監(jiān)控系統(tǒng)服務(wù)端的設(shè)計與實現(xiàn)［D］. 南京：南京大學(xué)， 2018： 42-51.（REN T. The design and implementation of CAT monitoring server?side system［D］. Nanjing： Nanjing University， 2018： 42-51.）

[11] 楊帆. 基于zipkin協(xié)議的分布式調(diào)用跟蹤方案［J］. 福建電腦， 2018， 34（1）：124-124， 152.（YANG F. Distributed revocation tracking scheme based on zipkin protocol［J］. Fujian Computer， 2018， 34（1）：124-124， 152.）

[12] 吳晟. Apache SkyWalking，開源監(jiān)控生態(tài)［J］. 軟件和集成電路， 2021（6）：62-62.（WU S. Apache Skywalking， open source monitoring ecology［J］. Software and Integrated Circuit， 2021（6）：62-62.）

[13] 李敏，熊燦，肖揚(yáng). 基于事件驅(qū)動的動態(tài)分簇網(wǎng)絡(luò)的協(xié)作傳輸方法［J］. 電子與信息學(xué)報， 2021， 43（8）：2232-2239.（LI M， XIONG C， XIAO Y. An event?driven cooperative transmission scheme for dynamic clustering networks［J］. Journal of Electronics and Information Technology， 2021， 43（8）： 2232-2239.）

[14] WANG J， LIU H P， ZHANG Z. Constrained route planning based on the regular expression［C］// Processing of the 2017 International Conference on Collaborative Computing： Networking， Applications and Worksharing， LNICST 252. Cham： Springer， 2018：98-108.

[15] OpenTracing. Specification［EB/OL］.［2021-05-11］.https：//github.com/opentracing/specification/blob/master/specification.md.

[16] 盧晨曦. 面向大數(shù)據(jù)流的分布式B+樹索引構(gòu)建［D］. 杭州：浙江工業(yè)大學(xué)， 2019： 34-42.（LU C X. A distributed B+ tree for big data stream［D］. Hangzhou： Zhejiang University of Technology， 2019： 34-42.）

[17] 李雙，古良鈴，賀媛媛. 從編程和性能看B樹和B+樹［J］. 電腦編程技巧與維護(hù)， 2020（10）：47-49.（LI S， GU L L， HE Y Y. Seeing B tree and B+ tree from programming and performance perspectives［J］. Computer Programming Skills and Maintenance， 2020（10）： 47-49.）

[18] HU J K， CHEN Y M， LU Y Y， et al. Understanding and analysis of B+ trees on NVM towards consistency and efficiency［J］. CCF Transactions on High Performance Computing， 2020， 2（1）：36-49.

[19] 王洪潤. 微服務(wù)架構(gòu)中服務(wù)監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)［D］. 北京：北京郵電大學(xué)， 2020： 56-67.（WANG H R. Design and implementation of service monitoring system in microservice architecture［D］. Beijing： Beijing University of Posts and Telecommunications， 2020： 56-67.）

[20] 趙來. 面向微服務(wù)的運(yùn)維監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)［D］. 西安：西安電子科技大學(xué)， 2020： 42-53.（ZHAO L. Design and implementation of a microservice?oriented operation and maintenance monitoring system［D］. Xi􀆳an： Xidian University， 2020： 42-53.）

[21] 于曉虹. 微服務(wù)架構(gòu)在分布式系統(tǒng)的設(shè)計和應(yīng)用［J］.電子技術(shù)與軟件工程，2021（6）：28-29.（YU X H. Design and application of microservice architecture in distributed systems［J］. Electronic Technology and Software Engineering， 2021（6）： 28-29.）

Event?driven dynamic collection method for microservice invocation link data

LI Peng1，2*， ZHAO Zhuofeng1，2， LI Han1，2

（1，，100144，；2（），100144，）

Microservice invocation link data is a type of important data generated in the daily operation of the microservice application system， which records a series of service invocation information corresponding to a user request in the microservice application in the form of link. Microservice invocation link data are generated at different microservice deployment nodes due to the distribution characteristic of the system， and the current collection methods for these distributed data include full collection and sampling collection. Full collection may bring large data transmission and data storage costs， while sampling collection may miss critical invocation data. Therefore， an event?driven and pipeline sampling based dynamic collection method for microservice invocation link data was proposed， and a microservice invocation link system that supports dynamic collection of invocation link data was designed and implemented based on the open?source software Zipkin. Firstly， the pipeline sampling was performed on the link data of different nodes that met the predefined event features， that is the same link data of all nodes were collected by the data collection server only when the event defined data was generated by a node； meanwhile， to address the problem of inconsistent data generation rates of different nodes， multi?threaded streaming data processing technology based on time window and data synchronization technology were used to realize the data collection and transmission of different nodes. Finally， considering the problem that the link data of each node arrives at the server in different sequential order， the synchronization and summary of the full link data were realized through the timing alignment method. Experimental results on the public microservice lrevocation ink dataset prove that compared to the full collection and sampling collection methods， the proposed method has higher accuracy and more efficient collection on link data containing specific events such as anomalies and slow responces.

microservice; invocation link data; dynamic sampling; event matching; caching mechanism; service link tracing

This work is partially supported by National Key Research and Development Program of China （2019YFB1405100）， Beijing Natural Science Foundation （4202021）.

LI Peng， born in 1996， M. S. His research interests include microservices， big data.

ZHAO Zhuofeng， born in 1977， Ph. D.， research fellow. His research interests include cloud computing， massive perceptual data processing， service computing， smart city.

LI Han， born in 1981， Ph. D.， associate research fellow. Her research interests include big data analysis， data quality management.

1001-9081（2022）11-3493-07

10.11772/j.issn.1001-9081.2021101735

2021?10?09；

2021?11?08；

2021?11?17。

國家重點研發(fā)計劃項目（2019YFB1405100）；北京市自然科學(xué)基金資助項目（4202021）。

TP311.5

A

李鵬（1996—），男，山東濟(jì)南人，碩士，CCF會員，主要研究方向：微服務(wù)、大數(shù)據(jù)；趙卓峰（1977—），男，山東濟(jì)南人，研究員，博士，CCF會員，主要研究方向：云計算、海量感知數(shù)據(jù)處理、服務(wù)計算、智慧城市；李寒（1981—），女，遼寧沈陽人，副研究員，博士，CCF會員，主要研究方向：大數(shù)據(jù)分析、數(shù)據(jù)質(zhì)量管理。