分佈式調用鏈監控組件的實踐與比較（一）實踐

引言：最近在調研與選型分佈式調用鏈監控組件。選了主要的三種APM組件進行了實踐與比較。本來打算一篇文章寫完的，篇幅太長，打算分兩篇。本文主要講下鏈路traceing的基本概念和幾種APM組件的實踐，實踐部分也沒給出特別詳細的步驟，因爲本文重點不在具體的步驟。第二篇將會講下幾種APM選型的比較與性能測試。

1. 問題背景

微服務架構下，服務按照不同的維度進行拆分，一次請求請求往往需要涉及到多個服務。互聯網應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。

分佈式調用鏈監控組件在這樣的環境下產生了。最出名的是谷歌公開的論文提到的Dapper。開發Dapper是爲了收集更多的複雜分佈式系統的行爲信息，然後呈現給Google的開發者們。這樣的分佈式系統有一個特殊的好處，因爲那些大規模的低端服務器，作爲互聯網服務的載體，是一個特殊的經濟划算的平臺。想要在這個上下文中理解分佈式系統的行爲，就需要監控那些橫跨了不同的應用、不同的服務器之間的關聯動作。

市面上的APM（Application Performance Management）理論模型大多都是借鑑（borrow）Google Dapper論文，本文重點關注以下幾種APM組件：

Zipkin 由Twitter公司開源，開放源代碼分佈式的跟蹤系統，用於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。
Pinpoint Pinpoint是一款對Java編寫的大規模分佈式系統的APM工具，由韓國人開源的分佈式跟蹤組件。
Skywalking 國產的優秀APM組件，是一個對JAVA分佈式應用程序集羣的業務運行情況進行追蹤、告警和分析的系統。

其他類似的組件還有美團點評的CAT，淘寶的鷹眼EgleEye。

如上所述，那麼我們選擇鏈路監控組件有哪些要求呢？Dapper中也提到了，筆者總結如下：

探針的性能消耗。 APM組件服務的影響應該做到足夠小。在一些高度優化過的服務，即使一點點損耗也會很容易察覺到，而且有可能迫使在線服務的部署團隊不得不將跟蹤系統關停。
代碼的侵入性對於應用的程序員來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那麼這個跟蹤系統也太脆弱了，往往由於跟蹤系統在應用中植入代碼的bug或疏忽導致應用出問題，這樣纔是無法滿足對跟蹤系統“無所不在的部署”這個需求。
可擴展性能夠支持的組件越多當然越好。或者提供便捷的插件開發API，對於一些沒有監控到的組件，應用開發者也可以自行擴展。
數據的分析數據的分析要快，分析的維度儘可能多。跟蹤系統能提供足夠快的信息反饋，就可以對生產環境下的異常狀況做出快速反應。分析的全面，能夠避免二次開發。

2. 基礎概念

上面列出的幾種組件，其中Zipkin是嚴格按照Google Dapper論文實現的，下面介紹下其中涉及的基本概念。

Span 基本工作單元，一次鏈路調用(可以是RPC，DB等沒有特定的限制)創建一個span，通過一個64位ID標識它，uuid較爲方便，span中還有其他的數據，例如描述信息，時間戳，key-value對的(Annotation)tag信息，parent-id等,其中parent-id可以表示span調用鏈路來源。
Trace:類似於樹結構的Span集合，表示一條調用鏈路，存在唯一標識。比如你運行的分佈式大數據存儲一次Trace就由你的一次請求組成。
Annotation: 註解,用來記錄請求特定事件相關信息(例如時間)，通常包含四個註解信息： (1) cs：Client Start,表示客戶端發起請求 (2) sr：Server Receive,表示服務端收到請求 (3) ss：Server Send,表示服務端完成處理，並將結果發送給客戶端 (4) cr：Client Received,表示客戶端獲取到服務端返回信息

2.1

Trace

下面看一下，在系統中Trace是什麼樣子。

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

2.2

Span

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

2.3

Annotation

自動的探針，不需要修改應用程序源代碼，對應用開發者近乎零浸入的成本對分佈式控制路徑進行跟蹤，幾乎完全依賴於基於少量通用組件庫的改造。Dapper還允許應用程序開發人員在Dapper跟蹤的過程中添加額外的信息，以監控更高級別的系統行爲，或幫助調試問題。

下面章節將會介紹下上述三種APM組件的使用與實踐。

zipkin

zipkin主要涉及幾個組件：collector收集agent的數據，storage存儲，web UI圖形化界面，search查詢Storage中存儲的數據,提供簡單的JSON API獲取數據。

我們的項目基於微服務框架spring cloud構建微服務。spring cloud也提供了spring-cloud-sleuth來方便集成zipkin實現。所以筆者就在項目中試了下spring-cloud-sleuth-zipkin。

起了三個服務： zipkin-server、zipkin-client-backend、zipkin-client。其中server服務負責收集以及信息展示。client-backend調用client，產生調用鏈路信息。

3.1

zipkin-server實現

zipkin-server實現主要有兩點需要注意，其一是收集到數據的存儲，方式包括內存、數據庫、ES等；其二是通信方式，包括http通信和mq異步方式通信，http通信會對正常的訪問造成影響，所以還是推薦基於mq異步方式通信。

本文使用mysql作爲存儲，使用MQ通信，MQ通信基於Spring-cloud-Stream。本文重點不在zipkin-server的具體幾種實現方式，其他方式，讀者可以自己去官網查看。

（1）pom需要添加的引用如下：

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter</artifactId>
</dependency>

<!--zipkin依賴-->
    <dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>   

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>

<dependency>
   <groupId>io.zipkin.java</groupId>
   <artifactId>zipkin-autoconfigure-ui</artifactId>
   <scope>runtime</scope>
</dependency>

<!--保存到數據庫需要如下依賴-->
<dependency>
   <groupId>mysql</groupId>
   <artifactId>mysql-connector-java</artifactId>
</dependency>

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-jdbc</artifactId>

（2）啓動類：

// 使用Stream方式啓動ZipkinServer
@EnableZipkinStreamServer
@SpringBootApplication
public class ZipkinStreamServerApplication {
public static void main(String[] args) {
    SpringApplication.run(ZipkinStreamServerApplication.class,args);
}
}

@EnableZipkinStreamServer註解引入了@EnableZipkinServer註解，同時還創建了一個rabbit-mq的SleuthSink消息隊列監聽器。

（3）配置文件

server:
 port: 9411
spring:
 datasource:
  username: root
  password: root123
  schema[0]: classpath:/zipkin.sql
zipkin:
  storage:
    type: mysql
---
spring:
 application:
 name: microservice-zipkin-stream-server
  rabbitmq:
  host: ${RABBIT_ADDR:localhost}
  port: ${RABBIT_PORT:5672}
  username: guest
  password: guest
sleuth:
 enabled: false
 profiles: default
 datasource:
  url:  jdbc:mysql://localhost:3307/zipkin? autoReconnect=true&useSSL=false

zipkin.sql可以去官網獲取，設置了zipkin-server的端口號爲9411。

3.2

zipkin-client

兩個zipkin-client的配置一樣，所以放在一起。

（1）pom依賴

<dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
  </dependency>
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
  </dependency>
  <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-sleuth</artifactId>
  </dependency>

(2) 配置文件

spring:
rabbitmq:
  host: 127.0.0.1
  port : 5672
  username: guest
  password: guest

3.3

結果

服務之間的調用關係如下：

可以看到客戶端的請求經過gateway，調用內網中的各個服務，部分還涉及到調用notice服務。從圖中可以清楚的看出客戶端請求所經過的服務。下面看下demo2-default服務實例中的http path：

上圖中demo2-default服務的幾個http path按照時長排序，顯示了trace調用時長和span數量。點進去可以看到：

圖中列出了從父span開始，每一個span的耗時。本次trace中，涉及到兩個服務demo1和demo2。demo2調用demo1，從597ms開始調用demo1，完成最終的請求總共耗時1265ms。

pinpoint

對代碼零侵入，運用JavaAgent字節碼增強技術，只需要加啓動參數即可。 pinpoint的幾個組件部分和zipkin差不多，架構圖如下：

Pinpoint-Collector收集各種性能數據、Pinpoint-Agent和自己運行的應用關聯起來的探針、Pinpoint-Web將收集到的數據顯示成WEB網頁形式、HBase Storage收集到的數據存到HBase中。

4.1

pinpoint安裝

主要涉及以下軟件的安裝：

jdk 1.8 Java環境必須的，沒啥好解釋。
Hbase pinpoint收集來的測試數據，主要是存在Hbase數據庫的。所以它可以收集大量的數據，可以進行更加詳細的分析。Hbase安裝完成後，需要初始化Hbase的pinpoint庫，由pinpoint提供。Hbase內置了zookeeper。
pinpoint-collector collector收集agent的數據，將數據存到hbase集羣，對外暴露collector的tcp和udp的監聽端口9994，9995，9996。
pinpoint-web 頁面展示，配置文件中設置環境變量HBASE_HOST、HBASE_PORT等。
pinpoint-agent

到官網release頁面下載pinpoint-agent-x-SNAPSHOT.tar.gz，配置pinpoint.config中相關collector的信息。

安裝確實還比較麻煩，本文篇幅太長了，具體步驟後面再單獨寫文章講解。

4.2

運行pinpoint-agent

筆者使用的是spring-boot項目，所以只需要在啓動jar包的命令中加入-javaagent參數，並指定pinpoint-bootstrap包的絕對路徑。實例代碼如下：

java -javaagent:/aoho/auth_compose/pinpoint-bootstrap-1.6.0.jar -Dpinpoint.agentId=aoho-consumer -Dpinpoint.applicationName=aoho-consumer -jar id_generator/snowflake-id-generate-1.0-SNAPSHOT.jar

起的id生成器服務比較簡單，沒有用到數據庫等存儲介質。服務註冊到consul上，本地客戶端請求了id-server獲取id。其調用鏈如下：

pinpoint提供的功能比較豐富，下圖是調用/api/id接口的詳細信息。

可以看到，pinpoint記錄了客戶端的相應時間、IP地址等，調用樹在下面也有詳細列出，每個方法的耗時等。

serverMap中還展示了服務器的堆、永久代、CPU等信息，非常強大。

Skywalking

Skywalking是國內開源的APM監控組件，官網OpenSkywalking，根據官網介紹，其着力於性能和實時性兩方面。網上找到的Skywalking的架構圖。

可以看到Skywalking也是四部分組成，collector、agent、web、storage。支持集羣部署，集羣之間還引入了grpc通信。存儲支持內置的h2和elasticsearch存儲。

5.1

安裝

具體安裝可見官網。

collector安裝此處筆者使用單機版的collector，在release頁面下載好壓縮包，解壓後，單機版的collector默認使用h2數據庫，所以配置文件可以不需要修改，即可以運行bin/startup.sh。

目錄結構如上，logs文件夾中，有啓動的日誌，可以查看啓動情況。

web 解壓好skywalking-ui，設置server的config/collector_config.properties、log4j2以及監聽端口等相關信息，
agent 拷貝skywalking-agent目錄到所需位置，探針包含整個目錄，設置/config/agent.config中的collector信息。

5.2

運行agent

Spring boot的項目，啓動和上面pinpoint agent啓動方式相同。增加JVM啓動參數，-javaagent:/path/to/skywalking-agent/skywalking-agent.jar。

這次起了user服務，涉及到mysql、redis、consul等組件。可以看到其調用鏈路圖如下：

當訪問/api/external/register-code和/api/external/validate-code接口時，形成了上圖中的調用鏈。

上圖TraceId爲 2.59.15103021777910001的請求/api/external/register-code。這次trace中，每個涉及的span的耗時都有在圖中統計。

上面這張圖，是對userService中的Entry Service List接口進行了統計，包括調用數、成功率等信息。（因爲內置的h2，這邊在UI響應很久）

還有個對instance的統計，統計jvm的相關信息，API響應也很慢，可能與我用的存儲有關吧，就不截圖了。

總結

本文主要寫了鏈路監控組件的實踐。首先介紹了鏈路監控組件產生與應用的背景，以及選擇的要求；其次介紹了opentracing中涉及的基本概念；最後大篇幅介紹了三種APM組件的安裝與使用，並展示了每種APM的UI截圖。

zipkin-server-stream的源碼 github: https://github.com/keets2012/Spring-Boot-Samples/ oschina: https://gitee.com/keets/spring-boot-samples

分佈式調用鏈監控組件的實踐與比較（一）實踐

使用neovim打造go ide(支持代碼跳轉, 代碼補全, 實時語法檢查)

挑戰程序設計競賽 2.3章習題 poj 3046 Ant Counting

Shell/Python中的用戶名獲取

權威數據庫市場排名出爐，騰訊爆出王炸！

崩潰的一天，西安一碼通崩潰背後的技術問題。

Tooool-程序員一站式導航網站來了

aiXcoder3.0呼之欲出，代碼補全 AI，帶你進入「個性化智能編程時代」

阿里雲盤正式上架，速度15MB/s！（附下載鏈接+邀請碼）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結