主流微服務(wù)全鏈路監(jiān)控系統(tǒng)之戰(zhàn)

原文：https://www.jianshu.com/p/92a12de11f18

問(wèn)題背景

隨著微服務(wù)架構(gòu)的流行，服務(wù)按照不同的維度進(jìn)行拆分，一次請(qǐng)求往往需要涉及到多個(gè)服務(wù)。互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團(tuán)隊(duì)開(kāi)發(fā)、可能使用不同的編程語(yǔ)言來(lái)實(shí)現(xiàn)、有可能布在了幾千臺(tái)服務(wù)器，橫跨多個(gè)不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問(wèn)題的工具，以便發(fā)生故障的時(shí)候，能夠快速定位和解決問(wèn)題。
全鏈路監(jiān)控組件就在這樣的問(wèn)題背景下產(chǎn)生了。最出名的是谷歌公開(kāi)的論文提到的Google Dapper[1]。想要在這個(gè)上下文中理解分布式系統(tǒng)的行為，就需要監(jiān)控那些橫跨了不同的應(yīng)用、不同的服務(wù)器之間的關(guān)聯(lián)動(dòng)作。
所以，在復(fù)雜的微服務(wù)架構(gòu)系統(tǒng)中，幾乎每一個(gè)前端請(qǐng)求都會(huì)形成一個(gè)復(fù)雜的分布式服務(wù)調(diào)用鏈路。一個(gè)請(qǐng)求完整調(diào)用鏈可能如下圖所示：

一個(gè)請(qǐng)求完整調(diào)用鏈
那么在業(yè)務(wù)規(guī)模不斷增大、服務(wù)不斷增多以及頻繁變更的情況下，面對(duì)復(fù)雜的調(diào)用鏈路就帶來(lái)一系列問(wèn)題：

• 如何快速發(fā)現(xiàn)問(wèn)題？

• 如何判斷故障影響范圍？

• 如何梳理服務(wù)依賴(lài)以及依賴(lài)的合理性？

• 如何分析鏈路性能問(wèn)題以及實(shí)時(shí)容量規(guī)劃？

同時(shí)我們會(huì)關(guān)注在請(qǐng)求處理期間各個(gè)調(diào)用的各項(xiàng)性能指標(biāo)，比如：吞吐量（TPS）、響應(yīng)時(shí)間及錯(cuò)誤記錄等。

• 吞吐量，根據(jù)拓?fù)淇捎?jì)算相應(yīng)組件、平臺(tái)、物理設(shè)備的實(shí)時(shí)吞吐量。

• 響應(yīng)時(shí)間，包括整體調(diào)用的響應(yīng)時(shí)間和各個(gè)服務(wù)的響應(yīng)時(shí)間等。

• 錯(cuò)誤記錄，根據(jù)服務(wù)返回統(tǒng)計(jì)單位時(shí)間異常次數(shù)。

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

• 請(qǐng)求鏈路追蹤，故障快速定位：可以通過(guò)調(diào)用鏈結(jié)合業(yè)務(wù)日志快速定位錯(cuò)誤信息。

• 可視化：各個(gè)階段耗時(shí)，進(jìn)行性能分析。

• 依賴(lài)優(yōu)化：各個(gè)調(diào)用環(huán)節(jié)的可用性、梳理服務(wù)依賴(lài)關(guān)系以及優(yōu)化。

• 數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶(hù)的行為路徑，匯總分析應(yīng)用在很多業(yè)務(wù)場(chǎng)景。

目標(biāo)要求
如上所述，那么我們選擇全鏈路監(jiān)控組件有哪些目標(biāo)要求呢？Google Dapper中也提到了，總結(jié)如下：
探針的性能消耗
APM組件服務(wù)的影響應(yīng)該做到足夠小。服務(wù)調(diào)用埋點(diǎn)本身會(huì)帶來(lái)性能損耗，這就需要調(diào)用跟蹤的低損耗，實(shí)際中還會(huì)通過(guò)配置采樣率的方式，選擇一部分請(qǐng)求去分析請(qǐng)求路徑。在一些高度優(yōu)化過(guò)的服務(wù)，即使一點(diǎn)點(diǎn)損耗也會(huì)很容易察覺(jué)到，而且有可能迫使在線服務(wù)的部署團(tuán)隊(duì)不得不將跟蹤系統(tǒng)關(guān)停。
代碼的侵入性
即也作為業(yè)務(wù)組件，應(yīng)當(dāng)盡可能少入侵或者無(wú)入侵其他業(yè)務(wù)系統(tǒng)，對(duì)于使用方透明，減少開(kāi)發(fā)人員的負(fù)擔(dān)。
對(duì)于應(yīng)用的程序員來(lái)說(shuō)，是不需要知道有跟蹤系統(tǒng)這回事的。如果一個(gè)跟蹤系統(tǒng)想生效，就必須需要依賴(lài)應(yīng)用的開(kāi)發(fā)者主動(dòng)配合，那么這個(gè)跟蹤系統(tǒng)也太脆弱了，往往由于跟蹤系統(tǒng)在應(yīng)用中植入代碼的bug或疏忽導(dǎo)致應(yīng)用出問(wèn)題，這樣才是無(wú)法滿足對(duì)跟蹤系統(tǒng)“無(wú)所不在的部署”這個(gè)需求。
可擴(kuò)展性
一個(gè)優(yōu)秀的調(diào)用跟蹤系統(tǒng)必須支持分布式部署，具備良好的可擴(kuò)展性。能夠支持的組件越多當(dāng)然越好?；蛘咛峁┍憬莸牟寮_(kāi)發(fā)API，對(duì)于一些沒(méi)有監(jiān)控到的組件，應(yīng)用開(kāi)發(fā)者也可以自行擴(kuò)展。
數(shù)據(jù)的分析
數(shù)據(jù)的分析要快，分析的維度盡可能多。跟蹤系統(tǒng)能提供足夠快的信息反饋，就可以對(duì)生產(chǎn)環(huán)境下的異常狀況做出快速反應(yīng)。分析的全面，能夠避免二次開(kāi)發(fā)。
功能模塊
一般的全鏈路監(jiān)控系統(tǒng)，大致可分為四大功能模塊：
埋點(diǎn)與生成日志
埋點(diǎn)即系統(tǒng)在當(dāng)前節(jié)點(diǎn)的上下文信息，可以分為客戶(hù)端埋點(diǎn)、服務(wù)端埋點(diǎn)，以及客戶(hù)端和服務(wù)端雙向型埋點(diǎn)。埋點(diǎn)日志通常要包含以下內(nèi)容TraceId、SpanId、調(diào)用的開(kāi)始時(shí)間，協(xié)議類(lèi)型、調(diào)用方IP和端口，請(qǐng)求的服務(wù)名、調(diào)用耗時(shí)，調(diào)用結(jié)果，異常信息等，同時(shí)預(yù)留可擴(kuò)展字段，為下一步擴(kuò)展做準(zhǔn)備。
不能造成性能負(fù)擔(dān)：一個(gè)價(jià)值未被驗(yàn)證，卻會(huì)影響性能的東西，是很難在公司推廣的！
因?yàn)橐獙?xiě)log，業(yè)務(wù)QPS越高，性能影響越重。通過(guò)采樣和異步log解決。
收集和存儲(chǔ)日志
主要支持分布式日志采集的方案，同時(shí)增加MQ作為緩沖。

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

• 多級(jí)的Collector，類(lèi)似pub/sub架構(gòu)，可以負(fù)載均衡；

• 對(duì)聚合的數(shù)據(jù)進(jìn)行實(shí)時(shí)分析和離線存儲(chǔ)；

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

分析和統(tǒng)計(jì)調(diào)用鏈路數(shù)據(jù)，以及時(shí)效性
調(diào)用鏈跟蹤分析：把同一TraceID的Span收集起來(lái)，按時(shí)間排序就是timeline。把ParentID串起來(lái)就是調(diào)用棧。
拋異?；蛘叱瑫r(shí)，在日志里打印TraceID。利用TraceID查詢(xún)調(diào)用鏈情況，定位問(wèn)題。
依賴(lài)度量：

• 強(qiáng)依賴(lài)：調(diào)用失敗會(huì)直接中斷主流程

• 高度依賴(lài)：一次鏈路中調(diào)用某個(gè)依賴(lài)的幾率高

• 頻繁依賴(lài)：一次鏈路調(diào)用同一個(gè)依賴(lài)的次數(shù)多

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

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

展現(xiàn)以及決策支持
Google Dapper
Span
基本工作單元，一次鏈路調(diào)用（可以是RPC，DB等沒(méi)有特定的限制）創(chuàng)建一個(gè)Span，通過(guò)一個(gè)64位ID標(biāo)識(shí)它，uuid較為方便，Span中還有其他的數(shù)據(jù)，例如描述信息，時(shí)間戳，key-value對(duì)的（Annotation）tag信息，parent_id等，其中parent-id可以表示Span調(diào)用鏈路來(lái)源。

Span
上圖說(shuō)明了Span在一次大的跟蹤過(guò)程中是什么樣的。Dapper記錄了Span名稱(chēng)，以及每個(gè)Span的ID和父ID，以重建在一次追蹤過(guò)程中不同Span之間的關(guān)系。如果一個(gè)Span沒(méi)有父ID被稱(chēng)為root span。所有Span都掛在一個(gè)特定的跟蹤上，也共用一個(gè)跟蹤ID。
Span數(shù)據(jù)結(jié)構(gòu)：

			
			

				type Span struct {
    TraceID    int64 // 用于標(biāo)示一次完整的請(qǐng)求ID
    Name       string
    ID         int64 // 當(dāng)前這次調(diào)用span_id
    ParentID   int64 // 上層服務(wù)的調(diào)用span_id  最上層服務(wù)parent_id為null
    Annotation []Annotation // 用于標(biāo)記的時(shí)間戳
    Debug      bool
} Trace 類(lèi)似于樹(shù)結(jié)構(gòu)的Span集合，表示一次完整的跟蹤，從請(qǐng)求到服務(wù)器開(kāi)始，服務(wù)器返回response結(jié)束，跟蹤每次RPC調(diào)用的耗時(shí)，存在唯一標(biāo)識(shí)trace_id。比如：你運(yùn)行的分布式大數(shù)據(jù)存儲(chǔ)一次Trace就由你的一次請(qǐng)求組成。 
			

Trace
每種顏色的note標(biāo)注了一個(gè)Span，一條鏈路通過(guò)TraceId唯一標(biāo)識(shí)，Span標(biāo)識(shí)發(fā)起的請(qǐng)求信息。樹(shù)節(jié)點(diǎn)是整個(gè)架構(gòu)的基本單元，而每一個(gè)節(jié)點(diǎn)又是對(duì)Span的引用。節(jié)點(diǎn)之間的連線表示的Span和它的父Span直接的關(guān)系。雖然Span在日志文件中只是簡(jiǎn)單的代表Span的開(kāi)始和結(jié)束時(shí)間，他們?cè)谡麄€(gè)樹(shù)形結(jié)構(gòu)中卻是相對(duì)獨(dú)立的。
Annotation
注解，用來(lái)記錄請(qǐng)求特定事件相關(guān)信息（例如時(shí)間），一個(gè)Span中會(huì)有多個(gè)annotation注解描述。通常包含四個(gè)注解信息：

• cs：Client Start，表示客戶(hù)端發(fā)起請(qǐng)求

• sr：Server Receive，表示服務(wù)端收到請(qǐng)求

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

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

Annotation數(shù)據(jù)結(jié)構(gòu)：

   type Annotation struct {
    
    Timestamp int64
    
    Value     string
    
    Host      Endpoint
    
    Duration  int32
    
} 調(diào)用示例 請(qǐng)求調(diào)用示例： 

• 當(dāng)用戶(hù)發(fā)起一個(gè)請(qǐng)求時(shí)，首先到達(dá)前端A服務(wù)，然后分別對(duì)B服務(wù)和C服務(wù)進(jìn)行RPC調(diào)用；

• B服務(wù)處理完給A做出響應(yīng)，但是C服務(wù)還需要和后端的D服務(wù)和E服務(wù)交互之后再返還給A服務(wù)，最后由A服務(wù)來(lái)響應(yīng)用戶(hù)的請(qǐng)求。

請(qǐng)求調(diào)用示例
調(diào)用過(guò)程追蹤：

• 請(qǐng)求到來(lái)生成一個(gè)全局TraceID，通過(guò)TraceID可以串聯(lián)起整個(gè)調(diào)用鏈，一個(gè)TraceID代表一次請(qǐng)求。

• 除了TraceID外，還需要SpanID用于記錄調(diào)用父子關(guān)系。每個(gè)服務(wù)會(huì)記錄下parent id和span id，通過(guò)他們可以組織一次完整調(diào)用鏈的父子關(guān)系。

• 一個(gè)沒(méi)有parent id的span成為root span，可以看成調(diào)用鏈入口。

• 所有這些ID可用全局唯一的64位整數(shù)表示。

• 整個(gè)調(diào)用過(guò)程中每個(gè)請(qǐng)求都要透?jìng)鱐raceID和SpanID。

• 每個(gè)服務(wù)將該次請(qǐng)求附帶的TraceID和附帶的SpanID作為parent id記錄下，并且將自己生成的SpanID也記錄下。

• 要查看某次完整的調(diào)用則只要根據(jù)TraceID查出所有調(diào)用記錄，然后通過(guò)parent id和span id組織起整個(gè)調(diào)用父子關(guān)系。

整個(gè)調(diào)用過(guò)程追蹤
調(diào)用鏈核心工作：

• 調(diào)用鏈數(shù)據(jù)生成，對(duì)整個(gè)調(diào)用過(guò)程的所有應(yīng)用進(jìn)行埋點(diǎn)并輸出日志。

• 調(diào)用鏈數(shù)據(jù)采集，對(duì)各個(gè)應(yīng)用中的日志數(shù)據(jù)進(jìn)行采集。

• 調(diào)用鏈數(shù)據(jù)存儲(chǔ)及查詢(xún)，對(duì)采集到的數(shù)據(jù)進(jìn)行存儲(chǔ)，由于日志數(shù)據(jù)量一般都很大，不僅要能對(duì)其存儲(chǔ)，還需要能提供快速查詢(xún)。

• 指標(biāo)運(yùn)算、存儲(chǔ)及查詢(xún)，對(duì)采集到的日志數(shù)據(jù)進(jìn)行各種指標(biāo)運(yùn)算，將運(yùn)算結(jié)果保存起來(lái)。

• 告警功能，提供各種閥值警告功能。

整體部署架構(gòu)：

整體部署架構(gòu)

• 通過(guò)Agent生成調(diào)用鏈日志。

• 通過(guò)Logstash采集日志到Kafka。

• Kafka負(fù)責(zé)提供數(shù)據(jù)給下游消費(fèi)。

• storm計(jì)算匯聚指標(biāo)結(jié)果并落到ES。

• storm抽取trace數(shù)據(jù)并落到ES，這是為了提供比較復(fù)雜的查詢(xún)。比如通過(guò)時(shí)間維度查詢(xún)調(diào)用鏈，可以很快查詢(xún)出所有符合的traceID，根據(jù)這些traceID再去Hbase查數(shù)據(jù)就快了。

• Logstash將Kafka原始數(shù)據(jù)拉取到HBase中。HBase的rowkey為traceID，根據(jù)traceID查詢(xún)是很快的。

Agent無(wú)侵入部署：
通過(guò)Agent代理無(wú)侵入式部署，將性能測(cè)量與業(yè)務(wù)邏輯完全分離，可以測(cè)量任意類(lèi)的任意方法的執(zhí)行時(shí)間，這種方式大大提高了采集效率，并且減少運(yùn)維成本。根據(jù)服務(wù)跨度主要分為兩大類(lèi)AGENT：

• 服務(wù)內(nèi)Agent，這種方式是通過(guò)Java的Agent機(jī)制，對(duì)服務(wù)內(nèi)部的方法調(diào)用層次信息進(jìn)行數(shù)據(jù)收集，如方法調(diào)用耗時(shí)、入?yún)?、出參等信息?/span>

• 跨服務(wù)Agent，這種情況需要對(duì)主流RPC框架以插件形式提供無(wú)縫支持。并通過(guò)提供標(biāo)準(zhǔn)數(shù)據(jù)規(guī)范以適應(yīng)自定義RPC框架：

• Dubbo支持；

• Rest支持；

• 自定義RPC支持。

調(diào)用鏈監(jiān)控好處：

• 準(zhǔn)確掌握生產(chǎn)一線應(yīng)用部署情況；

• 從調(diào)用鏈全流程性能角度，識(shí)別對(duì)關(guān)鍵調(diào)用鏈，并進(jìn)行優(yōu)化；

• 提供可追溯的性能數(shù)據(jù)，量化IT運(yùn)維部門(mén)業(yè)務(wù)價(jià)值；

• 快速定位代碼性能問(wèn)題，協(xié)助開(kāi)發(fā)人員持續(xù)性的優(yōu)化代碼；

• 協(xié)助開(kāi)發(fā)人員進(jìn)行白盒測(cè)試，縮短系統(tǒng)上線穩(wěn)定期。

方案比較
市面上的全鏈路監(jiān)控理論模型大多都是借鑒Google Dapper論文，本文重點(diǎn)關(guān)注以下三種APM組件：

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

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

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

以上三種全鏈路監(jiān)控方案需要對(duì)比的項(xiàng)提煉出來(lái)：

• 探針的性能，主要是Agent對(duì)服務(wù)的吞吐量、CPU和內(nèi)存的影響。微服務(wù)的規(guī)模和動(dòng)態(tài)性使得數(shù)據(jù)收集的成本大幅度提高。

• Collector的可擴(kuò)展性，能夠水平擴(kuò)展以便支持大規(guī)模服務(wù)器集群。

• 全面的調(diào)用鏈路數(shù)據(jù)分析，提供代碼級(jí)別的可見(jiàn)性以便輕松定位失敗點(diǎn)和瓶頸。

• 對(duì)于開(kāi)發(fā)透明，容易開(kāi)關(guān)，添加新功能而無(wú)需修改代碼，容易啟用或者禁用。

• 完整的調(diào)用鏈應(yīng)用拓?fù)洌詣?dòng)檢測(cè)應(yīng)用拓?fù)?，幫助你搞清楚?yīng)用的架構(gòu)。

探針的性能
比較關(guān)注探針的性能，畢竟APM定位還是工具，如果啟用了鏈路監(jiān)控組建后，直接導(dǎo)致吞吐量降低過(guò)半，那也是不能接受的。對(duì)Skywalking、Zipkin、Pinpoint進(jìn)行了壓測(cè)，并與基線（未使用探針）的情況進(jìn)行了對(duì)比。
選用了一個(gè)常見(jiàn)的基于Spring的應(yīng)用程序，他包含Spring Boot，Spring MVC，Redis客戶(hù)端，MySQL。監(jiān)控這個(gè)應(yīng)用程序，每個(gè)Trace，探針會(huì)抓取5個(gè)Span（1 Tomcat，1 Spring MVC，2 Jedis，1 MySQL）。這邊基本和SkywalkingTest的測(cè)試應(yīng)用差不多。
模擬了三種并發(fā)用戶(hù)：500，750，1000。使用JMeter測(cè)試，每個(gè)線程發(fā)送30個(gè)請(qǐng)求，設(shè)置思考時(shí)間為10ms。使用的采樣率為1，即100%，這邊與生產(chǎn)可能有差別。Pinpoint默認(rèn)的采樣率為20，即5%，通過(guò)設(shè)置agent的配置文件改為100%。zipkin默認(rèn)也是1。組合起來(lái)，一共有12種。下面看下匯總表：

探針性能對(duì)比
從上表可以看出，在三種鏈路監(jiān)控組件中，Skywalking的探針對(duì)吞吐量的影響最小，Zipkin的吞吐量居中。Pinpoint的探針對(duì)吞吐量的影響較為明顯，在500并發(fā)用戶(hù)時(shí)，測(cè)試服務(wù)的吞吐量從1385降低到774，影響很大。然后再看下CPU和memory的影響，在內(nèi)部服務(wù)器進(jìn)行的壓測(cè)，對(duì)CPU和memory的影響都差不多在10%之內(nèi)。
Collector的可擴(kuò)展性
Collector的可擴(kuò)展性，使得能夠水平擴(kuò)展以便支持大規(guī)模服務(wù)器集群。
Zipkin：
開(kāi)發(fā)zipkin-Server（其實(shí)就是提供的開(kāi)箱即用包），zipkin-agent與zipkin-Server通過(guò)http或者M(jìn)Q進(jìn)行通信，http通信會(huì)對(duì)正常的訪問(wèn)造成影響，所以還是推薦基于mq異步方式通信，zipkin-Server通過(guò)訂閱具體的topic進(jìn)行消費(fèi)。這個(gè)當(dāng)然是可以擴(kuò)展的，多個(gè)zipkin-Server實(shí)例進(jìn)行異步消費(fèi)MQ中的監(jiān)控信息。

Zipkin
Skywalking：
Skywalking的Collector支持兩種部署方式：?jiǎn)螜C(jī)和集群模式。Collector與Agent之間的通信使用了gRPC。
Pinpoint：
同樣，Pinpoint也是支持集群和單機(jī)部署的。pinpoint agent通過(guò)Thrift通信框架，發(fā)送鏈路信息到Collector。
全面的調(diào)用鏈路數(shù)據(jù)分析
全面的調(diào)用鏈路數(shù)據(jù)分析，提供代碼級(jí)別的可見(jiàn)性以便輕松定位失敗點(diǎn)和瓶頸。
Zipkin：

Zipkin鏈路調(diào)用分析
Zipkin的鏈路監(jiān)控粒度相對(duì)沒(méi)有那么細(xì)，從上圖可以看到調(diào)用鏈中具體到接口級(jí)別，再進(jìn)一步的調(diào)用信息并未涉及。
Skywalking：

Skywalking鏈路調(diào)用分析
Skywalking 還支持20+的中間件、框架、類(lèi)庫(kù)，比如：主流的Dubbo、Okhttp，還有DB和消息中間件。上圖Skywalking鏈路調(diào)用分析截取的比較簡(jiǎn)單，網(wǎng)關(guān)調(diào)用user服務(wù)，由于支持眾多的中間件，所以Skywalking鏈路調(diào)用分析比Zipkin完備些。
Pinpoint：

Pinpoint鏈路調(diào)用分析
Pinpoint應(yīng)該是這三種APM組件中，數(shù)據(jù)分析最為完備的組件。提供代碼級(jí)別的可見(jiàn)性以便輕松定位失敗點(diǎn)和瓶頸，上圖可以看到對(duì)于執(zhí)行的SQL語(yǔ)句，都進(jìn)行了記錄。還可以配置報(bào)警規(guī)則等，設(shè)置每個(gè)應(yīng)用對(duì)應(yīng)的負(fù)責(zé)人，根據(jù)配置的規(guī)則報(bào)警，支持的中間件和框架也比較完備。
對(duì)于開(kāi)發(fā)透明，容易開(kāi)關(guān)
對(duì)于開(kāi)發(fā)透明，容易開(kāi)關(guān)，添加新功能而無(wú)需修改代碼，容易啟用或者禁用。我們期望功能可以不修改代碼就工作并希望得到代碼級(jí)別的可見(jiàn)性。
對(duì)于這一點(diǎn)，Zipkin使用修改過(guò)的類(lèi)庫(kù)和它自己的容器（Finagle）來(lái)提供分布式事務(wù)跟蹤的功能。但是，它要求在需要時(shí)修改代碼。Skywalking和Pinpoint都是基于字節(jié)碼增強(qiáng)的方式，開(kāi)發(fā)人員不需要修改代碼，并且可以收集到更多精確的數(shù)據(jù)因?yàn)橛凶止?jié)碼中的更多信息。
完整的調(diào)用鏈應(yīng)用拓?fù)?/span>
自動(dòng)檢測(cè)應(yīng)用拓?fù)?，幫助你搞清楚?yīng)用的架構(gòu)。

Pinpoint鏈路拓?fù)?/span>

Skywalking鏈路拓?fù)?/span>

Zipkin鏈路拓?fù)?/span>
上面三幅圖，分別展示了APM組件各自的調(diào)用拓?fù)?，都能?shí)現(xiàn)完整的調(diào)用鏈應(yīng)用拓?fù)?。相?duì)來(lái)說(shuō)，Pinpoint界面顯示的更加豐富，具體到調(diào)用的DB名，Zipkin的拓?fù)渚窒抻诜?wù)于服務(wù)之間。
Pinpoint與Zipkin細(xì)化比較
Pinpoint與Zipkin差異性：

• Pinpoint是一個(gè)完整的性能監(jiān)控解決方案：有從探針、收集器、存儲(chǔ)到Web界面等全套體系；而Zipkin只側(cè)重收集器和存儲(chǔ)服務(wù)，雖然也有用戶(hù)界面，但其功能與Pinpoint不可同日而語(yǔ)。反而Zipkin提供有Query接口，更強(qiáng)大的用戶(hù)界面和系統(tǒng)集成能力，可以基于該接口二次開(kāi)發(fā)實(shí)現(xiàn)。

• Zipkin官方提供有基于Finagle框架（Scala語(yǔ)言）的接口，而其他框架的接口由社區(qū)貢獻(xiàn)，目前可以支持Java、Scala、Node、Go、Python、Ruby和C#等主流開(kāi)發(fā)語(yǔ)言和框架；但是Pinpoint目前只有官方提供的Java Agent探針，其他的都在請(qǐng)求社區(qū)支援中（請(qǐng)參見(jiàn)#1759[2]和#1760[3]）。

• Pinpoint提供有Java Agent探針，通過(guò)字節(jié)碼注入的方式實(shí)現(xiàn)調(diào)用攔截和數(shù)據(jù)收集，可以做到真正的代碼無(wú)侵入，只需要在啟動(dòng)服務(wù)器的時(shí)候添加一些參數(shù)，就可以完成探針的部署；而Zipkin的Java接口實(shí)現(xiàn)Brave，只提供了基本的操作API，如果需要與框架或者項(xiàng)目集成的話，就需要手動(dòng)添加配置文件或增加代碼。

• Pinpoint的后端存儲(chǔ)基于HBase，而Zipkin基于Cassandra。

Pinpoint與Zipkin相似性：
Pinpoint與Zipkin都是基于Google Dapper的那篇論文，因此理論基礎(chǔ)大致相同。兩者都是將服務(wù)調(diào)用拆分成若干有級(jí)聯(lián)關(guān)系的Span，通過(guò)SpanId和ParentSpanId來(lái)進(jìn)行調(diào)用關(guān)系的級(jí)聯(lián)；最后再將整個(gè)調(diào)用鏈流經(jīng)的所有的Span匯聚成一個(gè)Trace，報(bào)告給服務(wù)端的Collector進(jìn)行收集和存儲(chǔ)。
即便在這一點(diǎn)上，Pinpoint所采用的概念也不完全與那篇論文一致。比如他采用TransactionId來(lái)取代TraceId，而真正的TraceId是一個(gè)結(jié)構(gòu)，里面包含了TransactionId，SpanId和ParentSpanId。而且Pinpoint在Span下面又增加了一個(gè)SpanEvent結(jié)構(gòu)，用來(lái)記錄一個(gè)Span內(nèi)部的調(diào)用細(xì)節(jié)（比如具體的方法調(diào)用等等），因此Pinpoint默認(rèn)會(huì)比Zipkin記錄更多的跟蹤數(shù)據(jù)。但是理論上并沒(méi)有限定Span的粒度大小，所以一個(gè)服務(wù)調(diào)用可以是一個(gè)Span，那么每個(gè)服務(wù)中的方法調(diào)用也可以是個(gè)Span，這樣的話，其實(shí)Brave也可以跟蹤到方法調(diào)用級(jí)別，只是具體實(shí)現(xiàn)并沒(méi)有這樣做而已。
字節(jié)碼注入vs API調(diào)用：
Pinpoint實(shí)現(xiàn)了基于字節(jié)碼注入的Java Agent探針，而Zipkin的Brave框架僅僅提供了應(yīng)用層面的API，但是細(xì)想問(wèn)題遠(yuǎn)不那么簡(jiǎn)單。字節(jié)碼注入是一種簡(jiǎn)單粗暴的解決方案，理論上來(lái)說(shuō)無(wú)論任何方法調(diào)用，都可以通過(guò)注入代碼的方式實(shí)現(xiàn)攔截，也就是說(shuō)沒(méi)有實(shí)現(xiàn)不了的，只有不會(huì)實(shí)現(xiàn)的。但Brave則不同，其提供的應(yīng)用層面的API還需要框架底層驅(qū)動(dòng)的支持，才能實(shí)現(xiàn)攔截。比如，MySQL的JDBC驅(qū)動(dòng)，就提供有注入interceptor的方法，因此只需要實(shí)現(xiàn)StatementInterceptor接口，并在Connection String中進(jìn)行配置，就可以很簡(jiǎn)單的實(shí)現(xiàn)相關(guān)攔截；而與此相對(duì)的，低版本的MongoDB的驅(qū)動(dòng)或者是Spring Data MongoDB的實(shí)現(xiàn)就沒(méi)有如此接口，想要實(shí)現(xiàn)攔截查詢(xún)語(yǔ)句的功能，就比較困難。
因此在這一點(diǎn)上，Brave是硬傷，無(wú)論使用字節(jié)碼注入多么困難，但至少也是可以實(shí)現(xiàn)的，但是Brave卻有無(wú)從下手的可能，而且是否可以注入，能夠多大程度上注入，更多的取決于框架的API而不是自身的能力。
難度及成本：
經(jīng)過(guò)簡(jiǎn)單閱讀Pinpoint和Brave插件的代碼，可以發(fā)現(xiàn)兩者的實(shí)現(xiàn)難度有天壤之別。在都沒(méi)有任何開(kāi)發(fā)文檔支撐的前提下，Brave比Pinpoint更容易上手。Brave的代碼量很少，核心功能都集中在brave-core這個(gè)模塊下，一個(gè)中等水平的開(kāi)發(fā)人員，可以在一天之內(nèi)讀懂其內(nèi)容，并且能對(duì)API的結(jié)構(gòu)有非常清晰的認(rèn)識(shí)。
Pinpoint的代碼封裝也是非常好的，尤其是針對(duì)字節(jié)碼注入的上層API的封裝非常出色，但是這依然要求閱讀人員對(duì)字節(jié)碼注入多少有一些了解，雖然其用于注入代碼的核心API并不多，但要想了解透徹，恐怕還得深入Agent的相關(guān)代碼，比如很難一目了然的理解addInterceptor和addScopedInterceptor的區(qū)別，而這兩個(gè)方法就是位于Agent的有關(guān)類(lèi)型中。
因?yàn)锽rave的注入需要依賴(lài)底層框架提供相關(guān)接口，因此并不需要對(duì)框架有一個(gè)全面的了解，只需要知道能在什么地方注入，能夠在注入的時(shí)候取得什么數(shù)據(jù)就可以了。就像上面的例子，我們根本不需要知道MySQL的JDBC Driver是如何實(shí)現(xiàn)的也可以做到攔截SQL的能力。但是Pinpoint就不然，因?yàn)镻inpoint幾乎可以在任何地方注入任何代碼，這需要開(kāi)發(fā)人員對(duì)所需注入的庫(kù)的代碼實(shí)現(xiàn)有非常深入的了解，通過(guò)查看其MySQL和Http Client插件的實(shí)現(xiàn)就可以洞察這一點(diǎn)，當(dāng)然這也從另外一個(gè)層面說(shuō)明Pinpoint的能力確實(shí)可以非常強(qiáng)大，而且其默認(rèn)實(shí)現(xiàn)的很多插件已經(jīng)做到了非常細(xì)粒度的攔截。
針對(duì)底層框架沒(méi)有公開(kāi)API的時(shí)候，其實(shí)Brave也并不完全無(wú)計(jì)可施，我們可以采取AOP的方式，一樣能夠?qū)⑾嚓P(guān)攔截注入到指定的代碼中，而且顯然AOP的應(yīng)用要比字節(jié)碼注入簡(jiǎn)單很多。
以上這些直接關(guān)系到實(shí)現(xiàn)一個(gè)監(jiān)控的成本，在Pinpoint的官方技術(shù)文檔中，給出了一個(gè)參考數(shù)據(jù)。如果對(duì)一個(gè)系統(tǒng)集成的話，那么用于開(kāi)發(fā)Pinpoint插件的成本是100，將此插件集成入系統(tǒng)的成本是0；但對(duì)于Brave，插件開(kāi)發(fā)的成本只有20，而集成成本是10。從這一點(diǎn)上可以看出官方給出的成本參考數(shù)據(jù)是5:1。但是官方又強(qiáng)調(diào)了，如果有10個(gè)系統(tǒng)需要集成的話，那么總成本就是10 * 10 + 20 = 120，就超出了Pinpoint的開(kāi)發(fā)成本100，而且需要集成的服務(wù)越多，這個(gè)差距就越大。
通用性和擴(kuò)展性：
很顯然，這一點(diǎn)上Pinpoint完全處于劣勢(shì)，從社區(qū)所開(kāi)發(fā)出來(lái)的集成接口就可見(jiàn)一斑。
Pinpoint的數(shù)據(jù)接口缺乏文檔，而且也不太標(biāo)準(zhǔn)（參考論壇討論帖），需要閱讀很多代碼才可能實(shí)現(xiàn)一個(gè)自己的探針（比如Node的或者PHP的）。而且團(tuán)隊(duì)為了性能考慮使用了Thrift作為數(shù)據(jù)傳輸協(xié)議標(biāo)準(zhǔn)，比起HTTP和JSON而言難度增加了不少。
社區(qū)支持:
這一點(diǎn)也不必多說(shuō)，Zipkin由Twitter開(kāi)發(fā)，可以算得上是明星團(tuán)隊(duì)，而Naver的團(tuán)隊(duì)只是一個(gè)默默無(wú)聞的小團(tuán)隊(duì)（從#1759[2]的討論中可以看出）。雖然說(shuō)這個(gè)項(xiàng)目在短期內(nèi)不太可能消失或停止更新，但畢竟不如前者用起來(lái)更加放心。而且沒(méi)有更多社區(qū)開(kāi)發(fā)出來(lái)的插件，讓Pinpoint只依靠團(tuán)隊(duì)自身的力量完成諸多框架的集成實(shí)屬困難，而且他們目前的工作重點(diǎn)依然是在提升性能和穩(wěn)定性上。
其他：
Pinpoint在實(shí)現(xiàn)之初就考慮到了性能問(wèn)題，www.naver.com網(wǎng)站的后端某些服務(wù)每天要處理超過(guò)200億次的請(qǐng)求，因此他們會(huì)選擇Thrift的二進(jìn)制變長(zhǎng)編碼格式、而且使用UDP作為傳輸鏈路，同時(shí)在傳遞常量的時(shí)候也盡量使用數(shù)據(jù)參考字典，傳遞一個(gè)數(shù)字而不是直接傳遞字符串等等。這些優(yōu)化也增加了系統(tǒng)的復(fù)雜度：包括使用Thrift接口的難度、UDP數(shù)據(jù)傳輸?shù)膯?wèn)題、以及數(shù)據(jù)常量字典的注冊(cè)問(wèn)題等等。
相比之下，Zipkin使用熟悉的Restful接口加JSON，幾乎沒(méi)有任何學(xué)習(xí)成本和集成難度，只要知道數(shù)據(jù)傳輸結(jié)構(gòu)，就可以輕易的為一個(gè)新的框架開(kāi)發(fā)出相應(yīng)的接口。
另外Pinpoint缺乏針對(duì)請(qǐng)求的采樣能力，顯然在大流量的生產(chǎn)環(huán)境下，不太可能將所有的請(qǐng)求全部記錄，這就要求對(duì)請(qǐng)求進(jìn)行采樣，以決定什么樣的請(qǐng)求是我需要記錄的。Pinpoint和Brave都支持采樣百分比，也就是百分之多少的請(qǐng)求會(huì)被記錄下來(lái)。但是，除此之外Brave還提供了Sampler接口，可以自定義采樣策略，尤其是當(dāng)進(jìn)行A/B測(cè)試的時(shí)候，這樣的功能就非常有意義了。
總結(jié)：
從短期目標(biāo)來(lái)看，Pinpoint確實(shí)具有壓倒性的優(yōu)勢(shì)：無(wú)需對(duì)項(xiàng)目代碼進(jìn)行任何改動(dòng)就可以部署探針、追蹤數(shù)據(jù)細(xì)?；椒椒ㄕ{(diào)用級(jí)別、功能強(qiáng)大的用戶(hù)界面以及幾乎比較全面的Java框架支持。但是長(zhǎng)遠(yuǎn)來(lái)看，學(xué)習(xí)Pinpoint的開(kāi)發(fā)接口，以及未來(lái)為不同的框架實(shí)現(xiàn)接口的成本都還是個(gè)未知數(shù)。相反，掌握Brave就相對(duì)容易，而且Zipkin的社區(qū)更加強(qiáng)大，更有可能在未來(lái)開(kāi)發(fā)出更多的接口。在最壞的情況下，我們也可以自己通過(guò)AOP的方式添加適合于我們自己的監(jiān)控代碼，而并不需要引入太多的新技術(shù)和新概念。而且在未來(lái)業(yè)務(wù)發(fā)生變化的時(shí)候，Pinpoint官方提供的報(bào)表是否能滿足要求也不好說(shuō)，增加新的報(bào)表也會(huì)帶來(lái)不可以預(yù)測(cè)的工作難度和工作量。
Tracing和Monitor區(qū)別

Monitor可分為系統(tǒng)監(jiān)控和應(yīng)用監(jiān)控。系統(tǒng)監(jiān)控比如CPU，內(nèi)存，網(wǎng)絡(luò)，磁盤(pán)等等整體的系統(tǒng)負(fù)載的數(shù)據(jù)，細(xì)化可具體到各進(jìn)程的相關(guān)數(shù)據(jù)。這一類(lèi)信息是直接可以從系統(tǒng)中得到的。應(yīng)用監(jiān)控需要應(yīng)用提供支持，暴露了相應(yīng)的數(shù)據(jù)。比如應(yīng)用內(nèi)部請(qǐng)求的QPS，請(qǐng)求處理的延時(shí)，請(qǐng)求處理的error數(shù)，消息隊(duì)列的隊(duì)列長(zhǎng)度，崩潰情況，進(jìn)程垃圾回收信息等等。Monitor主要目標(biāo)是發(fā)現(xiàn)異常，及時(shí)報(bào)警。
Tracing的基礎(chǔ)和核心都是調(diào)用鏈。相關(guān)的Metric大多都是圍繞調(diào)用鏈分析得到的。Tracing主要目標(biāo)是系統(tǒng)分析。提前找到問(wèn)題比出現(xiàn)問(wèn)題后再去解決更好。Tracing和應(yīng)用級(jí)的Monitor技術(shù)棧上有很多共同點(diǎn)。都有數(shù)據(jù)的采集，分析，存儲(chǔ)和展式。只是具體收集的數(shù)據(jù)維度不同，分析過(guò)程不一樣。