from: http://wapapp.baidu.com/tianhuimin/item/6e144c362eced2ff96f88d42

1 概述1.1 研發背景

支撐互聯網應用的各種服務通常都是用復雜大規模分布式集群來實現的。而這些互聯網應用又構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開 發、可能使用不同的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行為、用于分析性能問題的工 具。

hydra分布式跟蹤系統就為了解決以上這些問題而設計的。

1.2 理論依據

Google的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我們設計開發的指導思想(原文和譯文地址 https://github.com/bigbully/Dapper-translation)。Google針對自己的分布式跟蹤系統Dapper 在生產環境下運行兩年多時間積累的經驗，在論文中重點提到了分布式跟蹤系統對業務系統的零侵入這個先天優勢，并總結了大量的應用場景，還提及它的不足之 處。我們通過對這篇論文的深入研究，并參考了Twitter同樣依據這篇論文的scala實現Zipkin，結合我們自身的現有架構，我們認為分布式跟蹤 系統在我們內部是非常適合的，而且也是急需的。

1.3 功能概述

hydra目前的功能并不復雜，他可以接入一些基礎組件，然后實現在基礎組件上收集在組建上產生的行為的時間消耗，并且提供跟蹤查詢頁面，對跟蹤到的數據進行查詢和展示。

我們會在之后的功能介紹中對hydra現有功能進行說明。

2 領域模型

分布式跟蹤的領域模型其實已經很成熟，早在1997年IBM就把ARM2.0(Application Response Measurement)作為一個公開的標準提供給了Open Group，無奈當時SOA的架構還未成熟，對業務的跟蹤還需要直接嵌入到業務代碼中，致使跟蹤系統無法順利推廣。

如今互聯網領域大多數后臺服務都已經完成了SOA化，所以對業務的跟蹤可以直接簡化為對服務調用框架的跟蹤，所以越來越多的跟蹤系統也涌現出來。 在hydra系統中，我們使用的領域模型參考了Google的Dapper和Twitter的Zipkin(http://twitter.github.io/zipkin/)。

2.1 hydra中的跟蹤數據模型

參考Dapper和Zipkin的設計，hydra也提煉出了自己的領域模型，如圖所示:

• Trace:一次服務調用追蹤鏈路。

• Span:追蹤服務調基本結構，多span形成樹形結構組合成一次Trace追蹤記錄。

• Annotation:在span中的標注點，記錄整個span時間段內發生的事件。

• BinaryAnnotation:屬于Annotation一種類型和普通Annotation區別，這鍵值對形式標注在span中發生的事件，和一些其他相關的信息。

Annotation在整個跟蹤數據模型中最靈活的，靈活運用annotation基本能表達你所想到的跟蹤場景。在hydra中(參考了zipkin)定義4種不同value的annotation用來表達記錄span 4個最基本的事件。通過這4個annotation能計算出鏈路中業務消耗和網絡消耗時間。

2.2 dubbo服務調用框架的模型

公司內部，尤其是我們部門有很多業務系統使用dubbo作為服務調用框，所以我們的分布式跟蹤系統第一個接入組件就是dubbo。 另一個原因也是因為我們團隊對dubbo有著非常深入的理解，加之dubbo本身的架構本身十分適合擴展，作為服務調用框架而言，跟蹤的效果會非常明顯， 比如Twitter的Zipkin也是植入到內部的Finagle服務調用框架上來進行跟蹤的。

由于現階段hydra主要接入了dubbo服務調用框架,所以在這必須了解dubbo的幾個模型，如下圖所示:

• Application:一類業務類型的服務，下面可能包含多個接口服務，可能出現多種類型業務跟蹤鏈路。

• InterfaceService:接口服務，一個服務接口提供多種業務處理方法。

• Method:接口服務中具體處理業務的方法。

2.3 Hydra中跟蹤模型和dubbo模型之間關系

如圖所示的應用場景對A服務的調用。A服務在被調用的過程中會繼續調用服務B和服務C,而服務C被調用之后又會繼續調用服務D和服 務E。在我們的領域模型中，服務A被調用到調用完成的過程，就是一次trace。而每一個服務被調用并返回的過程（一去一回的箭頭）為一個span。可以 看到這個示例中包含5個span，client-A，A-B，A-C，C-D，C-E。span本身以樹形結構展開，A-C是C-D和C-E的父 span，而client-A是整個樹形結構的root span。之后要提到的一個概念就是annotation，annotation代表在服務調用過程中發生的一些我們感興趣的事情，如圖所示C-E上標出 來的那四個點，就是四個annotation，來記錄事件時間戳，分別是C服務的cs（client send），E服務的ss（server receive）,E服務的ss（server send）, C服務的cr（client receive）。如果有一些自定義的annotation我們會把它作為BinaryAnnotation，其實就是一個k-v對，記錄任何跟蹤系統想 記錄的信息，比如服務調用中的異常信息，重要的業務信息等等。

3 功能介紹

當前hydra1.0版的功能主要分為兩個部分，跟蹤查詢和跟蹤展示。

如圖所示為查詢頁面：

在hydra針對業務提出兩個相關的概念：應用和服務。不同的業務的所屬不同的應用(相當于dubbo中的Application)，服務（相當于dubbo中的interface）掛在應用之下。

在hydra的查詢界面中首先要選擇想要關注的應用名，然后通過自動完成的方式輸入應用下的服務。選擇服務的開始時間和需要查看的跟蹤次數。另外hydra需要確定返回數據的總量，防止查詢出大數據量導致頁面失去響應。

另外我們提供對額外的篩選條件：調用響應時間、是否發生異常。調用響應時間指的是這一次服務調用從調用開始到調用結束的時間，是否發生異常則包括一次服務調用中所有歷經的服務拋出的異常都會捕獲到。

對于查詢之后的數據，hydra提供在前臺進行排序的功能。

對于每一次跟蹤，我們可以進一步展示他的服務調用層級與響應時間的時序圖。如下圖所示：

我們參考Dapper中論述的場景，在時序圖中用綠色代表服務調用時間，淺藍色代表網絡耗時，另外如果服務調用拋出異常被 hydra捕捉到的話，會用紅色表示。鼠標移動到時序圖中的每一個對象上，會Tip展現詳細信息，包括服務名、方法名、調用時長、Endpoint、異常 信息等。

左側的樹形結構圖可以收起和展開，同時右側的時序圖產生聯動，利于調整關注點在不同的服務上。

4 整體架構4.1 完整版

對于分布式跟蹤系統而言，必須對接入的基礎組件進行改造，我們對dubbo的改造很簡單，只是在過濾器鏈上增加一個過濾器，我們將其封裝成一個hydra-dubbo的jar包，由dubbo直接依賴。

所有跟蹤所需的通用性的API我們封裝在hydra-client中，遍于接入各種組件。 hydra-manager用來完成每個服務的注冊、采樣率的調成、發送seed生成全局唯一的traceId等通用性的功能。所有hydra-manager數據統一用mysql進行存儲。

我們使用hydra-collector和hydra-collector-service進行跟蹤數據的異步存儲，中間使用metaQ進行緩沖。

hydra-manager和hydra-collector使用dobbo提供服務。

4.2 精簡版

考慮到數據量不大的情況，以及部署的復雜度。我們提供了兩種更簡便的架構

• 如果考慮到數據量沒有那么大，可以不使用hbase，用mysql代替，即精簡版1。因為畢竟hadoop集群和hbase集群的部署和維護工作量很大。

• 如果并發量也不是很大的話，可以不使用消息中間件，也就是精簡版2，如圖所示。在hydra-collector端直接進行數據落地，當然仍然是異步的。

在使用mysql進行存儲的時候我們并未進行分庫分表，因為考慮到存儲的是監控數據，時效性較高，而長期的監控數據的保留意義并不大。所以我們在主表上有明確的時間戳字段，使用者可以自行決定何時對保存的歷史數據進行遷移。

5 Quick Start5.1 部署簡介

Hydra分布式跟蹤系統可以跟蹤環境的數據量大小選擇上文所述的三種部署方式

• 高并發，大數據量：hydra-client | Queue | hbase

• 高并發，小數據量：hydra-client | Queue | mysql

• 低并發，小數據量：hydra-client | mysql

因為是quick start，這里只介紹低并發和小數據量的情況。不過這里會詳細介紹如何通過配置文件的修改來切換這三種部署方式。

5.2 硬件要求

• 1或多臺業務系統集群機

• 1套zookeeper單點或集群機

• 1臺機器部署Hydra-manager

• 1或多臺機器部署Hydra-Collector

• 1臺機器部署Hydra-web

• 1臺數據庫服務器

5.3 軟件要求

• Dubbo:Hydra是基于alibaba的dubbo框架基準上做的服務跟蹤系統，理論上原有的Dubbo框架服務群中所有應用不需要額外的配置，皆可以平滑的接入Hydra系統。

• Zookeeper:各個服務點依賴于zookeeper來讀取Hydra-manager和Hydra-collector獲取數據交互路由點，來完成跟蹤數據的推送和跟蹤的控制。

• Mysql:跟蹤數據的持久化存儲。

• Tomcat:前端web應用容器

5.4 源碼獲取

可以暫時使用master，后續版本會歸并到dubbo管理端

5.5 項目構建打包

maven項目不用多說。mvn clean install。不過不得不說的是，hydra項目中包含一些涉及數據庫讀寫的單元測試(mysql，hbase），配置文件分別在:

• modules/hydra-manager-db/src/test/resources/mysql.properties

• modules/hydra-store/hydra-mysql/src/test/resources/mysql.properties

• modules/hydra-store/hydra-hbase/src/test/resources/hbase-site.xml

• modules/hydra-store/hydra-hbase/src/test/resources/hydra-hbase-test.xml

mysql需要創建測試用數據庫和測試用表，hbase需要創建測試用表

• docs/table-hbase/initTable
  (hbase建表時可以根據hbase集群的具體情況調整域分區，涉及到table-mysql中對TB_PARA_SERVICE_ID_GEN初始化數據的設計)

• docs/table-mysql

當然對于不需要使用hbase的同學也可以自行移除modules/hydar-store/hydra-hbase。

當然用maven構建跳過測試也是可以的。使用mvn clean install -Dmaven.test.skip=true

需要打包的子項目會通過maven:assemblly插件打成tar.gz包在各自的target目錄下。

5.6 安裝部署5.6.1 Hydra-client

hydra-client中包含hydra與dubbo的集成，以及hydra跟蹤收集的相關功能。如果需要進行dubbo服務的跟蹤，只需要把這個jar包放在dubbo服務的classpath下，就會自動開啟跟蹤功能！

5.6.2 Hydra-manager

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 啟動：cd basedir/bin
   sh manager.sh start

4. 停止：cd basedir/bin
   sh manager.sh stop

5. 輸入：cd basedir/log
   tail -f manager.log

5.6.3 Hydra-collector

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 啟動：cd basedir/bin
   sh collector-mysql.sh start 
   (這里注意一下，如果在hydra-collector中需要發送到Queue中，則需要啟動collector.sh,jar包會加載不同的配置文件。)

4. 停止：cd basedir/bin
   sh collector-mysql.sh stop

5. 輸入：cd basedir/log
   tail -f *.log

5.6.4 Hydra-web

1. 需要在web.xml中修改引入的配置文件為hydra-mysql.xml，注掉hydra-hbase.xml

2. 部署：scp -r target/*.war username@ip:$TOMCAT_WEBAPPS

6 模擬場景6.1 場景描述

我們模擬了兩個測試場景，均是基于dubbo服務調用

場景exp1:

A --> B --> C         

即服務A調用服務B,服務B調用服務C。測試用例在modules/hydra-example/hydra-exmple-exp1/。熟悉dubbo的同學一定不會陌生。

場景exp2:

A --> B --> C1 --> E                     --> C2 --> D1 --> C1 --> E                            --> D2         

場景2很復雜，基本涵蓋了對同步調用跟蹤的大多數可能遇到的場景。測試用例在modules/hydra-example/hydra-exmple-exp2/。

6.2 模擬場景dubbo服務的部署

Hydra默認使用了hydra-exmple中的兩個應用場景來做，你可以在hydra-test/hydra-test-integration打包中獲得應用場景。

獲得tar.gz包或者zip包后，將服務分布式部署到不同的機器上，以模擬應用場景,一下介紹場景一的部署方法，場景二的部署方法類似。

hydra-test-intergration 分為windows版和linux版(默認)，見如下打包方法。

• 打包：linux: mvn package -Pruntime-env-linux
  window: mvn package -Pruntime-env-windows

• 部署: scp -r target/*.tar.gz username@ip:dirname

• 配置: cd basedir/conf
  修改 *exp1.properties

• 啟動： cd basedir/bin
  cd exp1
  sh startA.sh
  cd ..
  sh startTrigger-exp1.sh start

• 停止: cd basedir/bin
  sh startTrigger-exp1.sh stop
  All.sh stop

• 輸出: cd basedir/log
  tail -f *.log

6.3 部署舉例

以下演示安裝樣例：

1. 部署zookeeper單點或集群環境，以保證獲得最佳SOA，zookeeper的部署請參照官方文檔。

2. 部署實驗場景exp1，只需要部署hydra-test-integration模塊打包的tar.gz包，拷貝三份分布式部署。

3. 部署一個觸發器Trigger，以激活服務的調用。

4. 部署一個Manager，以管理各個跟蹤點的跟蹤上下文。

5. 部署一個或者多個Collector消費機集群，以搜集來自Hydra-client推送過來的跟蹤數據。

6. 部署一個web應用，已提供給前端展現應用系統服務上下文。

exp1場景說明：

有三個服務應用A、B、C和一個觸發RPC調用的應用Trigger，服務調用關系為A-B-C， 每隔500s觸發一個調用，持續時間為1天。

部署地址舉例：

角色ipportZK192.168.200.110-1122181~A192.168.200.11020990B192.168.200.11120991C192.168.200.11220992Trigger192.168.200.113-Manager192.168.228.8120890Collector192.168.228.81-8220889Web192.168.228.818080MySql-DB192.168.228.8133067 測試相關7.1 測試說明

本測試針對Hydra-Client模塊進行功能測試和壓力測試，以便在Hydra開發的過程中及時發現重要bug和幫助優化Hydra系統性能。

本測試目前只針對Hydra-client的測試，重點關注業務系統接入Hydra和不接入Hydra前后性能影響，以保證Hydra系統接入端的低侵入性和穩定性。

針對Hydra-Client的測試，在部署上，只用部署應用場景（帶Hydra_client）和Benchmark觸發點，然后在應用Benchmark和應用場景上埋點分析Hydra性能。

資料來源：http://www.open-open.com/lib/view/open1370253915148.html