服務調用鏈的主要因素和簡要對比

調用鏈主要因素

數據收集部分

主要用於多樣化的數據收集，爲數據分析作準備。要求易用好用侵入儘可能小（開發工做量），而且在極端狀況下（如收集組件不可用）不能對業務有任何影響。能夠看到此部分的開發量是巨大的，尤爲是須要集成Nginx上下游、基礎組件多樣、技術棧多樣的狀況下。

數據分析部分

主要有實時分析與線下分析。通常，實時分析的價值更大一些，主要產出如秒級別的調用量、平均響應時間、TP值等。另外，調用鏈（Trace)須要存儲全量數據，一些高併發大埋點的請求，會有性能問題。

監控報警

此部分利用數據分析的產出，經過短信郵件等形式，通知訂閱人關注。監控報警平臺應儘可能向devops平臺靠攏，包括自主化服務平臺。

實現方式分析

根據收集方式可分爲日誌收集方式和程序實現方式

日誌收集方式

日誌收集方式與傳統的ELK鏈路差很少。主要經過日誌組件，打印出符合規範的日誌格式。Flume守護進程會讀取、過濾這些日誌，將數據Sink到kafka集羣中。會接收一份全量數據（調用鏈須要）到ES中供查詢分析；同時接收一份日誌使用Spark或Strom方式分析出須要的數據，存結果。

主要開發量集中在日誌組件和各個模塊的組合調試中。另外，因爲須要在每臺宿主機上安裝配置flume-agent，此模式依賴完善的運維體系，可以使用jenkens或者ansible集成支持。

手動埋點方式

這種方式採用業務端直推的方法，將數據直接聚集到kafka中。客戶端通常會開一個堆上的緩衝區，將有單獨的線程定時上報緩衝區數據。數據落地到kafka後，後續的處理相似。

爲了支持易用性，須要較多的開發工做和可用性設計不會由於Trace組件或者Kafka的不可用形成服務的不可用。

此種方式的主要壞處是，功能是以jar包方式提供的，若有重大bug或者改動，全部服務都必須從新發布。

監控報警

• 通常的，grafana等組件便可知足需求，夠用，並可以快速實現。但其方式，僅僅能展現數據，須要肉眼盯盤，若是有更靈活的監控需求，不支持。
• 監控曲線，應該可以發現系統性能瓶頸，爲擴容、縮容提供決策依據。

• 同比、環比、斜率，包括報警，須要進行開發（報警和歷史走勢），功能不復雜，但須要考慮如下問題：

  • 報警接收人變動，是否能及時支持
  • 報警閾值調整，是否須要走工單等複雜流程
  • 是否能查看歷史報警和處理的報警，並依此評價響應速度

對比

咱們大致對比了不一樣封裝層次的三個表明，以便對調用鏈產品有個大致理解

總結

cat

優勢：功能強大，監控全面，並且數據展現全面，更便於之後問題分析。
缺點：須要在代碼中埋點，對代碼侵入性很大。對於美團內部框架依賴嚴重。

sleuth + zipkin

優勢：是spring cloud的組件，基於spring boot框架，接入簡單，不須要埋點，分析的方式是經過日誌分析，並且能夠對接多種第三方存儲進行存儲和分析。
缺點：功能單一，只經過進行http調用的跟蹤。頁面數據展現比較簡單，只有調用鏈路的相關信息， 沒有總體數據的對比。sleuth只對restTemplate，zuul轉發，spring cloud stream的消息中間件這三種調用方式進行添加監控信息，其餘方式不支持，因此更適用於spring cloud環境。

pinpoint

優勢：採用javaagent字節碼加強技術，對業務代碼入侵極少，業務只須要在啓動時增長javaagent參數便可
缺點：
1.功能限於鏈路跟蹤，對於其餘業務監控指標支持不足
2.維護技術難度較高，內部是字節碼加強技術，問題排查須要較高的技術水平
3.同第二點，自定義擴展開發難度也較高。

來源：http://sayhiai.com/index.php/archives/23/