概述

隨著微服務(wù)架構(gòu)的流行，服務(wù)按照不同的維度進(jìn)行拆分，一次請求往往需要涉及到多個服務(wù)。互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團(tuán)隊開發(fā)、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務(wù)器，橫跨多個不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障的時候，能夠快速定位和解決問題。

[[269064]]

全鏈路監(jiān)控組件就在這樣的問題背景下產(chǎn)生了。最出名的是谷歌公開的論文提到的 Google Dapper。想要在這個上下文中理解分布式系統(tǒng)的行為，就需要監(jiān)控那些橫跨了不同的應(yīng)用、不同的服務(wù)器之間的關(guān)聯(lián)動作。

分布式服務(wù)調(diào)用鏈路

在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中，幾乎每一個前端請求都會形成一個復(fù)雜的分布式服務(wù)調(diào)用鏈路。一個請求完整調(diào)用鏈可能如下圖所示：

一個請求完整調(diào)用鏈

那么在業(yè)務(wù)規(guī)模不斷增大、服務(wù)不斷增多以及頻繁變更的情況下，面對復(fù)雜的調(diào)用鏈路就帶來一系列問題：

• 如何快速發(fā)現(xiàn)問題?
• 如何判斷故障影響范圍?
• 如何梳理服務(wù)依賴以及依賴的合理性?
• 如何分析鏈路性能問題以及實時容量規(guī)劃?

同時需要關(guān)注在請求處理期間各個調(diào)用的各項性能指標(biāo)，比如：吞吐量(TPS)、響應(yīng)時間及錯誤記錄等。

• 吞吐量，根據(jù)拓?fù)淇捎嬎阆鄳?yīng)組件、平臺、物理設(shè)備的實時吞吐量。
• 響應(yīng)時間，包括整體調(diào)用的響應(yīng)時間和各個服務(wù)的響應(yīng)時間等。
• 錯誤記錄，根據(jù)服務(wù)返回統(tǒng)計單位時間異常次數(shù)。

全鏈路性能監(jiān)控 從整體維度到局部維度展示各項指標(biāo)，將跨應(yīng)用的所有調(diào)用鏈性能信息集中展現(xiàn)，可方便度量整體和局部性能，并且方便找到故障產(chǎn)生的源頭，生產(chǎn)上可極大縮短故障排除時間。

有了全鏈路監(jiān)控工具，能夠達(dá)到：

• 請求鏈路追蹤，故障快速定位：可以通過調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯誤信息。
• 可視化： 各個階段耗時，進(jìn)行性能分析。
• 依賴優(yōu)化：各個調(diào)用環(huán)節(jié)的可用性、梳理服務(wù)依賴關(guān)系以及優(yōu)化。
• 數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶的行為路徑，匯總分析應(yīng)用在很多業(yè)務(wù)場景。

1、全鏈路監(jiān)控目標(biāo)

如上所述，那么我們選擇全鏈路監(jiān)控組件有哪些目標(biāo)要求呢?Google Dapper中也提到了，總結(jié)如下：

1.探針的性能消耗

2.APM組件服務(wù)的影響應(yīng)該做到足夠小。

服務(wù)調(diào)用埋點本身會帶來性能損耗，這就需要調(diào)用跟蹤的低損耗，實際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑。在一些高度優(yōu)化過的服務(wù)，即使一點點損耗也會很容易察覺到，而且有可能迫使在線服務(wù)的部署團(tuán)隊不得不將跟蹤系統(tǒng)關(guān)停。

3.代碼的侵入性

4.即也作為業(yè)務(wù)組件，應(yīng)當(dāng)盡可能少入侵或者無入侵其他業(yè)務(wù)系統(tǒng)，對于使用方透明，減少開發(fā)人員的負(fù)擔(dān)。

5.對于應(yīng)用的程序員來說，是不需要知道有跟蹤系統(tǒng)這回事的。

如果一個跟蹤系統(tǒng)想生效，就必須需要依賴應(yīng)用的開發(fā)者主動配合，那么這個跟蹤系統(tǒng)也太脆弱了，往往由于跟蹤系統(tǒng)在應(yīng)用中植入代碼的bug或疏忽導(dǎo)致應(yīng)用出問題，這樣才是無法滿足對跟蹤系統(tǒng)“無所不在的部署”這個需求。

6.可擴(kuò)展性

7.一個優(yōu)秀的調(diào)用跟蹤系統(tǒng)必須支持分布式部署，具備良好的可擴(kuò)展性。能夠支持的組件越多當(dāng)然越好。

或者提供便捷的插件開發(fā)API，對于一些沒有監(jiān)控到的組件，應(yīng)用開發(fā)者也可以自行擴(kuò)展。

8.數(shù)據(jù)的分析

9.數(shù)據(jù)的分析要快 ，分析的維度盡可能多。

跟蹤系統(tǒng)能提供足夠快的信息反饋，就可以對生產(chǎn)環(huán)境下的異常狀況做出快速反應(yīng)。分析的全面，能夠避免二次開發(fā)。

2、全鏈路監(jiān)控功能模塊

一般的全鏈路監(jiān)控系統(tǒng)，大致可分為四大功能模塊：

1.埋點與生成日志

埋點即系統(tǒng)在當(dāng)前節(jié)點的上下文信息，可以分為 客戶端埋點、服務(wù)端埋點，以及客戶端和服務(wù)端雙向型埋點。埋點日志通常要包含以下內(nèi)容traceId、spanId、調(diào)用的開始時間，協(xié)議類型、調(diào)用方ip和端口，請求的服務(wù)名、調(diào)用耗時，調(diào)用結(jié)果，異常信息等，同時預(yù)留可擴(kuò)展字段，為下一步擴(kuò)展做準(zhǔn)備;

2.收集和存儲日志

主要支持分布式日志采集的方案，同時增加MQ作為緩沖;

每個機(jī)器上有一個 deamon 做日志收集，業(yè)務(wù)進(jìn)程把自己的Trace發(fā)到daemon，daemon把收集Trace往上一級發(fā)送;

多級的collector，類似pub/sub架構(gòu)，可以負(fù)載均衡;

對聚合的數(shù)據(jù)進(jìn)行 實時分析和離線存儲;

離線分析 需要將同一條調(diào)用鏈的日志匯總在一起;

3.分析和統(tǒng)計調(diào)用鏈路數(shù)據(jù)，以及時效性

調(diào)用鏈跟蹤分析：把同一TraceID的Span收集起來，按時間排序就是timeline。把ParentID串起來就是調(diào)用棧。

拋異?；蛘叱瑫r，在日志里打印TraceID。利用TraceID查詢調(diào)用鏈情況，定位問題。

依賴度量：

• 強(qiáng)依賴：調(diào)用失敗會直接中斷主流程
• 高度依賴：一次鏈路中調(diào)用某個依賴的幾率高
• 頻繁依賴：一次鏈路調(diào)用同一個依賴的次數(shù)多

離線分析：按TraceID匯總，通過Span的ID和ParentID還原調(diào)用關(guān)系，分析鏈路形態(tài)。

實時分析：對單條日志直接分析，不做匯總，重組。得到當(dāng)前QPS，延遲。

4.展現(xiàn)以及決策支持

3、Google Dapper

3.1 Span

基本工作單元，一次鏈路調(diào)用(可以是RPC，DB等沒有特定的限制)創(chuàng)建一個span，通過一個64位ID標(biāo)識它，uuid較為方便，span中還有其他的數(shù)據(jù)，例如描述信息，時間戳，key-value對的(Annotation)tag信息，parent_id等,其中parent-id可以表示span調(diào)用鏈路來源。 

Span

上圖說明了span在一次大的跟蹤過程中是什么樣的。Dapper記錄了span名稱，以及每個span的ID和父ID，以重建在一次追蹤過程中不同span之間的關(guān)系。如果一個span沒有父ID被稱為root span。所有span都掛在一個特定的跟蹤上，也共用一個跟蹤id。

3.2 TRACE

類似于樹結(jié)構(gòu)的Span集合，表示一次完整的跟蹤，從請求到服務(wù)器開始，服務(wù)器返回response結(jié)束，跟蹤每次rpc調(diào)用的耗時，存在唯一標(biāo)識trace_id。比如：你運行的分布式大數(shù)據(jù)存儲一次Trace就由你的一次請求組成。 

Trace

每種顏色的note標(biāo)注了一個span，一條鏈路通過TraceId唯一標(biāo)識，Span標(biāo)識發(fā)起的請求信息。樹節(jié)點是整個架構(gòu)的基本單元，而每一個節(jié)點又是對span的引用。節(jié)點之間的連線表示的span和它的父span直接的關(guān)系。雖然span在日志文件中只是簡單的代表span的開始和結(jié)束時間，他們在整個樹形結(jié)構(gòu)中卻是相對獨立的。

3.3 Annotation

注解，用來記錄請求特定事件相關(guān)信息(例如時間)，一個span中會有多個annotation注解描述。通常包含四個注解信息：

(1) cs：Client Start，表示客戶端發(fā)起請求

(2) sr：Server Receive，表示服務(wù)端收到請求

(3) ss：Server Send，表示服務(wù)端完成處理，并將結(jié)果發(fā)送給客戶端

(4) cr：Client Received，表示客戶端獲取到服務(wù)端返回信息

4、 方案比較

市面上的全鏈路監(jiān)控理論模型大多都是借鑒Google Dapper論文，主要是以下三種APM組件：

Zipkin：由Twitter公司開源，開放源代碼分布式的跟蹤系統(tǒng)，用于收集服務(wù)的定時數(shù)據(jù)，以解決微服務(wù)架構(gòu)中的延遲問題，包括：數(shù)據(jù)的收集、存儲、查找和展現(xiàn)。

Pinpoint：一款對Java編寫的大規(guī)模分布式系統(tǒng)的APM工具，由韓國人開源的分布式跟蹤組件。

Skywalking：國產(chǎn)的優(yōu)秀APM組件，是一個對JAVA分布式應(yīng)用程序集群的業(yè)務(wù)運行情況進(jìn)行追蹤、告警和分析的系統(tǒng)。

相比之下，Pinpoint 具有壓倒性的優(yōu)勢：無需對項目代碼進(jìn)行任何改動就可以部署探針、追蹤數(shù)據(jù)細(xì)粒化到方法調(diào)用級別、功能強(qiáng)大的用戶界面以及幾乎比較全面的 Java 框架支持。