from: http://wapapp.baidu.com/tianhuimin/item/6e144c362eced2ff96f88d42
1 概述1.1 研發(fā)背景
支撐互聯(lián)網(wǎng)應(yīng)用的各種服務(wù)通常都是用復(fù)雜大規(guī)模分布式集群來實現(xiàn)的。而這些互聯(lián)網(wǎng)應(yīng)用又構(gòu)建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開 發(fā)、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務(wù)器，橫跨多個不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工 具。
hydra分布式跟蹤系統(tǒng)就為了解決以上這些問題而設(shè)計的。
1.2 理論依據(jù)
Google的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我們設(shè)計開發(fā)的指導(dǎo)思想(原文和譯文地址 https://github.com/bigbully/Dapper-translation)。Google針對自己的分布式跟蹤系統(tǒng)Dapper 在生產(chǎn)環(huán)境下運行兩年多時間積累的經(jīng)驗，在論文中重點提到了分布式跟蹤系統(tǒng)對業(yè)務(wù)系統(tǒng)的零侵入這個先天優(yōu)勢，并總結(jié)了大量的應(yīng)用場景，還提及它的不足之 處。我們通過對這篇論文的深入研究，并參考了Twitter同樣依據(jù)這篇論文的scala實現(xiàn)Zipkin，結(jié)合我們自身的現(xiàn)有架構(gòu)，我們認為分布式跟蹤 系統(tǒng)在我們內(nèi)部是非常適合的，而且也是急需的。
1.3 功能概述
hydra目前的功能并不復(fù)雜，他可以接入一些基礎(chǔ)組件，然后實現(xiàn)在基礎(chǔ)組件上收集在組建上產(chǎn)生的行為的時間消耗，并且提供跟蹤查詢頁面，對跟蹤到的數(shù)據(jù)進行查詢和展示。
我們會在之后的功能介紹中對hydra現(xiàn)有功能進行說明。
2 領(lǐng)域模型
分布式跟蹤的領(lǐng)域模型其實已經(jīng)很成熟，早在1997年IBM就把ARM2.0(Application Response Measurement)作為一個公開的標準提供給了Open Group，無奈當時SOA的架構(gòu)還未成熟，對業(yè)務(wù)的跟蹤還需要直接嵌入到業(yè)務(wù)代碼中，致使跟蹤系統(tǒng)無法順利推廣。
如今互聯(lián)網(wǎng)領(lǐng)域大多數(shù)后臺服務(wù)都已經(jīng)完成了SOA化，所以對業(yè)務(wù)的跟蹤可以直接簡化為對服務(wù)調(diào)用框架的跟蹤，所以越來越多的跟蹤系統(tǒng)也涌現(xiàn)出來。 在hydra系統(tǒng)中，我們使用的領(lǐng)域模型參考了Google的Dapper和Twitter的Zipkin(http://twitter.github.io/zipkin/)。
2.1 hydra中的跟蹤數(shù)據(jù)模型
參考Dapper和Zipkin的設(shè)計，hydra也提煉出了自己的領(lǐng)域模型，如圖所示:
Trace:一次服務(wù)調(diào)用追蹤鏈路。
Span:追蹤服務(wù)調(diào)基本結(jié)構(gòu)，多span形成樹形結(jié)構(gòu)組合成一次Trace追蹤記錄。
Annotation:在span中的標注點，記錄整個span時間段內(nèi)發(fā)生的事件。
BinaryAnnotation:屬于Annotation一種類型和普通Annotation區(qū)別，這鍵值對形式標注在span中發(fā)生的事件，和一些其他相關(guān)的信息。
Annotation在整個跟蹤數(shù)據(jù)模型中最靈活的，靈活運用annotation基本能表達你所想到的跟蹤場景。在hydra中(參考了zipkin)定義4種不同value的annotation用來表達記錄span 4個最基本的事件。通過這4個annotation能計算出鏈路中業(yè)務(wù)消耗和網(wǎng)絡(luò)消耗時間。
2.2 dubbo服務(wù)調(diào)用框架的模型
公司內(nèi)部，尤其是我們部門有很多業(yè)務(wù)系統(tǒng)使用dubbo作為服務(wù)調(diào)用框，所以我們的分布式跟蹤系統(tǒng)第一個接入組件就是dubbo。 另一個原因也是因為我們團隊對dubbo有著非常深入的理解，加之dubbo本身的架構(gòu)本身十分適合擴展，作為服務(wù)調(diào)用框架而言，跟蹤的效果會非常明顯， 比如Twitter的Zipkin也是植入到內(nèi)部的Finagle服務(wù)調(diào)用框架上來進行跟蹤的。
由于現(xiàn)階段hydra主要接入了dubbo服務(wù)調(diào)用框架,所以在這必須了解dubbo的幾個模型，如下圖所示:
Application:一類業(yè)務(wù)類型的服務(wù)，下面可能包含多個接口服務(wù)，可能出現(xiàn)多種類型業(yè)務(wù)跟蹤鏈路。
InterfaceService:接口服務(wù)，一個服務(wù)接口提供多種業(yè)務(wù)處理方法。
Method:接口服務(wù)中具體處理業(yè)務(wù)的方法。
2.3 Hydra中跟蹤模型和dubbo模型之間關(guān)系
如圖所示的應(yīng)用場景對A服務(wù)的調(diào)用。A服務(wù)在被調(diào)用的過程中會繼續(xù)調(diào)用服務(wù)B和服務(wù)C,而服務(wù)C被調(diào)用之后又會繼續(xù)調(diào)用服務(wù)D和服 務(wù)E。在我們的領(lǐng)域模型中，服務(wù)A被調(diào)用到調(diào)用完成的過程，就是一次trace。而每一個服務(wù)被調(diào)用并返回的過程（一去一回的箭頭）為一個span。可以 看到這個示例中包含5個span，client-A，A-B，A-C，C-D，C-E。span本身以樹形結(jié)構(gòu)展開，A-C是C-D和C-E的父 span，而client-A是整個樹形結(jié)構(gòu)的root span。之后要提到的一個概念就是annotation，annotation代表在服務(wù)調(diào)用過程中發(fā)生的一些我們感興趣的事情，如圖所示C-E上標出 來的那四個點，就是四個annotation，來記錄事件時間戳，分別是C服務(wù)的cs（client send），E服務(wù)的ss（server receive）,E服務(wù)的ss（server send）, C服務(wù)的cr（client receive）。如果有一些自定義的annotation我們會把它作為BinaryAnnotation，其實就是一個k-v對，記錄任何跟蹤系統(tǒng)想 記錄的信息，比如服務(wù)調(diào)用中的異常信息，重要的業(yè)務(wù)信息等等。
3 功能介紹
當前hydra1.0版的功能主要分為兩個部分，跟蹤查詢和跟蹤展示。
如圖所示為查詢頁面：
在hydra針對業(yè)務(wù)提出兩個相關(guān)的概念：應(yīng)用和服務(wù)。不同的業(yè)務(wù)的所屬不同的應(yīng)用(相當于dubbo中的Application)，服務(wù)（相當于dubbo中的interface）掛在應(yīng)用之下。
在hydra的查詢界面中首先要選擇想要關(guān)注的應(yīng)用名，然后通過自動完成的方式輸入應(yīng)用下的服務(wù)。選擇服務(wù)的開始時間和需要查看的跟蹤次數(shù)。另外hydra需要確定返回數(shù)據(jù)的總量，防止查詢出大數(shù)據(jù)量導(dǎo)致頁面失去響應(yīng)。
另外我們提供對額外的篩選條件：調(diào)用響應(yīng)時間、是否發(fā)生異常。調(diào)用響應(yīng)時間指的是這一次服務(wù)調(diào)用從調(diào)用開始到調(diào)用結(jié)束的時間，是否發(fā)生異常則包括一次服務(wù)調(diào)用中所有歷經(jīng)的服務(wù)拋出的異常都會捕獲到。
對于查詢之后的數(shù)據(jù)，hydra提供在前臺進行排序的功能。
對于每一次跟蹤，我們可以進一步展示他的服務(wù)調(diào)用層級與響應(yīng)時間的時序圖。如下圖所示：
我們參考Dapper中論述的場景，在時序圖中用綠色代表服務(wù)調(diào)用時間，淺藍色代表網(wǎng)絡(luò)耗時，另外如果服務(wù)調(diào)用拋出異常被 hydra捕捉到的話，會用紅色表示。鼠標移動到時序圖中的每一個對象上，會Tip展現(xiàn)詳細信息，包括服務(wù)名、方法名、調(diào)用時長、Endpoint、異常 信息等。
左側(cè)的樹形結(jié)構(gòu)圖可以收起和展開，同時右側(cè)的時序圖產(chǎn)生聯(lián)動，利于調(diào)整關(guān)注點在不同的服務(wù)上。
4 整體架構(gòu)4.1 完整版
對于分布式跟蹤系統(tǒng)而言，必須對接入的基礎(chǔ)組件進行改造，我們對dubbo的改造很簡單，只是在過濾器鏈上增加一個過濾器，我們將其封裝成一個hydra-dubbo的jar包，由dubbo直接依賴。
所有跟蹤所需的通用性的API我們封裝在hydra-client中，遍于接入各種組件。 hydra-manager用來完成每個服務(wù)的注冊、采樣率的調(diào)成、發(fā)送seed生成全局唯一的traceId等通用性的功能。所有hydra-manager數(shù)據(jù)統(tǒng)一用mysql進行存儲。
我們使用hydra-collector和hydra-collector-service進行跟蹤數(shù)據(jù)的異步存儲，中間使用metaQ進行緩沖。
hydra-manager和hydra-collector使用dobbo提供服務(wù)。
4.2 精簡版
考慮到數(shù)據(jù)量不大的情況，以及部署的復(fù)雜度。我們提供了兩種更簡便的架構(gòu)
在使用mysql進行存儲的時候我們并未進行分庫分表，因為考慮到存儲的是監(jiān)控數(shù)據(jù)，時效性較高，而長期的監(jiān)控數(shù)據(jù)的保留意義并不大。所以我們在主表上有明確的時間戳字段，使用者可以自行決定何時對保存的歷史數(shù)據(jù)進行遷移。
5 Quick Start5.1 部署簡介
Hydra分布式跟蹤系統(tǒng)可以跟蹤環(huán)境的數(shù)據(jù)量大小選擇上文所述的三種部署方式
高并發(fā)，大數(shù)據(jù)量：hydra-client | Queue | hbase
高并發(fā)，小數(shù)據(jù)量：hydra-client | Queue | mysql
低并發(fā)，小數(shù)據(jù)量：hydra-client | mysql
因為是quick start，這里只介紹低并發(fā)和小數(shù)據(jù)量的情況。不過這里會詳細介紹如何通過配置文件的修改來切換這三種部署方式。
5.2 硬件要求
5.3 軟件要求
Dubbo:Hydra是基于alibaba的dubbo框架基準上做的服務(wù)跟蹤系統(tǒng)，理論上原有的Dubbo框架服務(wù)群中所有應(yīng)用不需要額外的配置，皆可以平滑的接入Hydra系統(tǒng)。
Zookeeper:各個服務(wù)點依賴于zookeeper來讀取Hydra-manager和Hydra-collector獲取數(shù)據(jù)交互路由點，來完成跟蹤數(shù)據(jù)的推送和跟蹤的控制。
Mysql:跟蹤數(shù)據(jù)的持久化存儲。
Tomcat:前端web應(yīng)用容器
5.4 源碼獲取
可以暫時使用master，后續(xù)版本會歸并到dubbo管理端
5.5 項目構(gòu)建打包
maven項目不用多說。mvn clean install。不過不得不說的是，hydra項目中包含一些涉及數(shù)據(jù)庫讀寫的單元測試(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需要創(chuàng)建測試用數(shù)據(jù)庫和測試用表，hbase需要創(chuàng)建測試用表
當然對于不需要使用hbase的同學也可以自行移除modules/hydar-store/hydra-hbase。
當然用maven構(gòu)建跳過測試也是可以的。使用mvn clean install -Dmaven.test.skip=true
需要打包的子項目會通過maven:assemblly插件打成tar.gz包在各自的target目錄下。
5.6 安裝部署5.6.1 Hydra-client
hydra-client中包含hydra與dubbo的集成，以及hydra跟蹤收集的相關(guān)功能。如果需要進行dubbo服務(wù)的跟蹤，只需要把這個jar包放在dubbo服務(wù)的classpath下，就會自動開啟跟蹤功能！
5.6.2 Hydra-manager
部署：scp -r target/*.tar.gz username@ip:dirname
配置：cd basedir/conf （需要修改配置）
啟動：cd basedir/bin
sh manager.sh start
停止：cd basedir/bin
sh manager.sh stop
輸入：cd basedir/log
tail -f manager.log
5.6.3 Hydra-collector
部署：scp -r target/*.tar.gz username@ip:dirname
配置：cd basedir/conf （需要修改配置）
啟動：cd basedir/bin
sh collector-mysql.sh start
(這里注意一下，如果在hydra-collector中需要發(fā)送到Queue中，則需要啟動collector.sh,jar包會加載不同的配置文件。)
停止：cd basedir/bin
sh collector-mysql.sh stop
輸入：cd basedir/log
tail -f *.log
5.6.4 Hydra-web
需要在web.xml中修改引入的配置文件為hydra-mysql.xml，注掉hydra-hbase.xml
部署：scp -r target/*.war username@ip:$TOMCAT_WEBAPPS
6 模擬場景6.1 場景描述
我們模擬了兩個測試場景，均是基于dubbo服務(wù)調(diào)用
場景exp1:
A --> B --> C
即服務(wù)A調(diào)用服務(wù)B,服務(wù)B調(diào)用服務(wù)C。測試用例在modules/hydra-example/hydra-exmple-exp1/。熟悉dubbo的同學一定不會陌生。
場景exp2:
A --> B --> C1 --> E --> C2 --> D1 --> C1 --> E --> D2
場景2很復(fù)雜，基本涵蓋了對同步調(diào)用跟蹤的大多數(shù)可能遇到的場景。測試用例在modules/hydra-example/hydra-exmple-exp2/。
6.2 模擬場景dubbo服務(wù)的部署
Hydra默認使用了hydra-exmple中的兩個應(yīng)用場景來做，你可以在hydra-test/hydra-test-integration打包中獲得應(yīng)用場景。
獲得tar.gz包或者zip包后，將服務(wù)分布式部署到不同的機器上，以模擬應(yīng)用場景,一下介紹場景一的部署方法，場景二的部署方法類似。
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 部署舉例
以下演示安裝樣例：
部署zookeeper單點或集群環(huán)境，以保證獲得最佳SOA，zookeeper的部署請參照官方文檔。
部署實驗場景exp1，只需要部署hydra-test-integration模塊打包的tar.gz包，拷貝三份分布式部署。
部署一個觸發(fā)器Trigger，以激活服務(wù)的調(diào)用。
部署一個Manager，以管理各個跟蹤點的跟蹤上下文。
部署一個或者多個Collector消費機集群，以搜集來自Hydra-client推送過來的跟蹤數(shù)據(jù)。
部署一個web應(yīng)用，已提供給前端展現(xiàn)應(yīng)用系統(tǒng)服務(wù)上下文。
exp1場景說明：
有三個服務(wù)應(yīng)用A、B、C和一個觸發(fā)RPC調(diào)用的應(yīng)用Trigger，服務(wù)調(diào)用關(guān)系為A-B-C， 每隔500s觸發(fā)一個調(diào)用，持續(xù)時間為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 測試相關(guān)7.1 測試說明
本測試針對Hydra-Client模塊進行功能測試和壓力測試，以便在Hydra開發(fā)的過程中及時發(fā)現(xiàn)重要bug和幫助優(yōu)化Hydra系統(tǒng)性能。
本測試目前只針對Hydra-client的測試，重點關(guān)注業(yè)務(wù)系統(tǒng)接入Hydra和不接入Hydra前后性能影響，以保證Hydra系統(tǒng)接入端的低侵入性和穩(wěn)定性。
針對Hydra-Client的測試，在部署上，只用部署應(yīng)用場景（帶Hydra_client）和Benchmark觸發(fā)點，然后在應(yīng)用Benchmark和應(yīng)用場景上埋點分析Hydra性能。
資料來源：http://www.open-open.com/lib/view/open1370253915148.html