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

-     背景     -

隨著微服務(wù)架構(gòu)的流行，服務(wù)按照不同的維度進(jìn)行拆分，一次請求往往需要涉及到
多個服務(wù)。

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

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

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

-     目標(biāo)要求     -

1、探針的性能消耗

2、代碼的侵入性

3、可擴(kuò)展性

4、數(shù)據(jù)的分析

-     功能模塊     -

1、埋點(diǎn)與生成日志

不能造成性能負(fù)擔(dān)：一個價值未被驗(yàn)證，卻會影響性能的東西，是很難在公司推廣的！

因?yàn)橐獙?log，業(yè)務(wù) QPS 越高，性能影響越重。通過采樣和異步log解決。

2、收集和存儲日志

1. 每個機(jī)器上有一個 deamon 做日志收集，業(yè)務(wù)進(jìn)程把自己的 Trace 發(fā)到 daemon，daemon 把收集 Trace 往上一級發(fā)送；
2. 多級的 collector，類似 pub/sub 架構(gòu)，可以負(fù)載均衡；
   
3. 對聚合的數(shù)據(jù)進(jìn)行 實(shí)時分析和離線存儲；
   
4. 離線分析 需要將同一條調(diào)用鏈的日志匯總在一起；

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

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

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

-     Google Dapper     -

1、Span

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

type Span struct {    TraceID    int64 // 用于標(biāo)示一次完整的請求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)記的時間戳    Debug      bool}

2、Trace

3、Annotation

type Annotation struct {    Timestamp int64    Value     string    Host      Endpoint    Duration  int32}

（一）請求調(diào)用示例

1. 當(dāng)用戶發(fā)起一個請求時，首先到達(dá)前端A服務(wù)，然后分別對B服務(wù)和C服務(wù)進(jìn)行RPC調(diào)用；
2. B服務(wù)處理完給A做出響應(yīng)，但是C服務(wù)還需要和后端的D服務(wù)和E服務(wù)交互之后再返還給A服務(wù)，最后由A服務(wù)來響應(yīng)用戶的請求：

2、調(diào)用過程追蹤

1. 請求到來生成一個全局 TraceID，通過 TraceID 可以串聯(lián)起整個調(diào)用鏈，一個TraceID 代表一次請求。
2. 除了TraceID外，還需要SpanID用于記錄調(diào)用父子關(guān)系。每個服務(wù)會記錄下parent id和span id，通過他們可以組織一次完整調(diào)用鏈的父子關(guān)系。
3. 一個沒有parent id的span成為root span，可以看成調(diào)用鏈入口。
4. 所有這些ID可用全局唯一的64位整數(shù)表示；
   
5. 整個調(diào)用過程中每個請求都要透傳TraceID和SpanID。
   
6. 每個服務(wù)將該次請求附帶的TraceID和附帶的SpanID作為parent id記錄下，并且將自己生成的SpanID也記錄下。
   
7. 要查看某次完整的調(diào)用則 只要根據(jù)TraceID查出所有調(diào)用記錄，然后通過parent id和span id組織起整個調(diào)用父子關(guān)系。
   
   

3、調(diào)用鏈核心工作

1. 調(diào)用鏈數(shù)據(jù)生成，對整個調(diào)用過程的所有應(yīng)用進(jìn)行埋點(diǎn)并輸出日志。
2. 調(diào)用鏈數(shù)據(jù)采集，對各個應(yīng)用中的日志數(shù)據(jù)進(jìn)行采集。
3. 調(diào)用鏈數(shù)據(jù)存儲及查詢，對采集到的數(shù)據(jù)進(jìn)行存儲，由于日志數(shù)據(jù)量一般都很大，不僅要能對其存儲，還需要能提供快速查詢。
4. 指標(biāo)運(yùn)算、存儲及查詢，對采集到的日志數(shù)據(jù)進(jìn)行各種指標(biāo)運(yùn)算，將運(yùn)算結(jié)果保存起來。
5. 告警功能，提供各種閥值警告功能。

4、整體部署架構(gòu)

5、AGENT無侵入部署

1. 服務(wù)內(nèi)AGENT，這種方式是通過 Java 的agent機(jī)制，對服務(wù)內(nèi)部的方法調(diào)用層次信息進(jìn)行數(shù)據(jù)收集，如方法調(diào)用耗時、入?yún)?、出參等信息?/span>
2. 跨服務(wù)AGENT，這種情況需要對主流RPC框架以插件形式提供無縫支持。并通過提供標(biāo)準(zhǔn)數(shù)據(jù)規(guī)范以適應(yīng)自定義RPC框架：
   
   

（1）Dubbo支持；（2）Rest支持；（3）自定義RPC支持；

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

1. 準(zhǔn)確掌握生產(chǎn)一線應(yīng)用部署情況；
2. 從調(diào)用鏈全流程性能角度，識別對關(guān)鍵調(diào)用鏈，并進(jìn)行優(yōu)化；
3. 提供可追溯的性能數(shù)據(jù)，量化 IT 運(yùn)維部門業(yè)務(wù)價值；
4. 快速定位代碼性能問題，協(xié)助開發(fā)人員持續(xù)性的優(yōu)化代碼；
5. 協(xié)助開發(fā)人員進(jìn)行白盒測試，縮短系統(tǒng)上線穩(wěn)定期；

-     方案比較     -

1. Zipkin：由Twitter公司開源，開放源代碼分布式的跟蹤系統(tǒng)，用于收集服務(wù)的定時數(shù)據(jù)，以解決微服務(wù)架構(gòu)中的延遲問題，包括：數(shù)據(jù)的收集、存儲、查找和展現(xiàn)。
   
   
2. Pinpoint：一款對Java編寫的大規(guī)模分布式系統(tǒng)的APM工具，由韓國人開源的分布式跟蹤組件。
   
   
3. Skywalking：國產(chǎn)的優(yōu)秀APM組件，是一個對JAVA分布式應(yīng)用程序集群的業(yè)務(wù)運(yùn)行情況進(jìn)行追蹤、告警和分析的系統(tǒng)。

-     探針的性能     -

1、collector的可擴(kuò)展性

2、全面的調(diào)用鏈路數(shù)據(jù)分析

3、對于開發(fā)透明，容易開關(guān)

4、完整的調(diào)用鏈應(yīng)用拓?fù)?/span>

5、Pinpoint與Zipkin細(xì)化比較

Pinpoint與Zipkin差異性：

1. Pinpoint 是一個完整的性能監(jiān)控解決方案：有從探針、收集器、存儲到 Web 界面等全套體系；而 Zipkin 只側(cè)重收集器和存儲服務(wù)，雖然也有用戶界面，但其功能與 Pinpoint 不可同日而語。反而 Zipkin 提供有 Query 接口，更強(qiáng)大的用戶界面和系統(tǒng)集成能力，可以基于該接口二次開發(fā)實(shí)現(xiàn)。
2. Zipkin 官方提供有基于 Finagle 框架（Scala 語言）的接口，而其他框架的接口由社區(qū)貢獻(xiàn)，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流開發(fā)語言和框架；但是 Pinpoint 目前只有官方提供的 Java Agent 探針，其他的都在請求社區(qū)支援中（請參見 #1759 和 #1760）。
3. Pinpoint 提供有 Java Agent 探針，通過字節(jié)碼注入的方式實(shí)現(xiàn)調(diào)用攔截和數(shù)據(jù)收集，可以做到真正的代碼無侵入，只需要在啟動服務(wù)器的時候添加一些參數(shù)，就可以完成探針的部署；而 Zipkin 的 Java 接口實(shí)現(xiàn) Brave，只提供了基本的操作 API，如果需要與框架或者項(xiàng)目集成的話，就需要手動添加配置文件或增加代碼。
4. Pinpoint 的后端存儲基于 HBase，而 Zipkin 基于 Cassandra。

Pinpoint 與 Zipkin 相似性

字節(jié)碼注入 vs API 調(diào)用

難度及成本

通用性和擴(kuò)展性

社區(qū)支持

其他

總結(jié)

-     Tracing 和 Monitor 的區(qū)別     -

作者：猿碼架構(gòu)

來源：https://www.jianshu.com/p/92a12de11f18