Hydra架構
hydra的開發初衷
支撐互聯網應用的各種服務通常都是用複雜大規模分佈式集羣來實現的。而這些互聯網應用又構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行爲、用於分析性能問題的工具。
hydra分佈式跟蹤系統就爲了解決以上這些問題而設計的。
理論依據
Google的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我們設計開發的指導思想。Google針對自己的分佈式跟蹤系統Dapper在生產環境下運行兩年多時間積累的經驗，在論文中重點提到了分佈式跟蹤系統對業務系統的零侵入這個先天優勢，並總結了大量的應用場景，還提及它的不足之處。我們通過對這篇論文的深入研究，並參考了Twitter同樣依據這篇論文的scala實現Zipkin，結合京東自身的現有架構，我們認爲分佈式跟蹤系統在京東內部是非常適合的，而且也是急需的。
領域模型
分佈式跟蹤的領域模型其實已經很成熟，早在1997年IBM就把ARM2.0(Application Response Measurement)作爲一個公開的標準提供給了Open Group，無奈當時SOA的架構還未成熟，對業務的跟蹤還需要直接嵌入到業務代碼中，致使跟蹤系統無法順利推廣。
如今互聯網領域大多數後臺服務都已經完成了SOA化，所以對業務的跟蹤可以直接簡化爲對服務調用框架的跟蹤，所以越來越多的跟蹤系統也湧現出來。
在hydra系統中，我們使用的領域模型參考了Google的Dapper和Twitter的Zipkin。
在hydra現階段主要是對dubbo服務調用框架,所以在這必須瞭解dubbo的幾個模型:
Application:
一類業務類型的服務，下面可能包含多個接口服務，可能出現多種類型業務跟蹤鏈路.
InterfaceService:
接口服務，一個服務接口提供多種業務處理方法。
Method：
接口服務中具體處理業務的方法。
Hydra中跟蹤數據模型:
Trace:一次服務調用追蹤鏈路。
Span:追蹤服務調基本結構，多span形成樹形結構組合成一次Trace追蹤記錄。
Annotation:在span中的標註點，記錄整個span時間段內發生的事件。Annotati
BinaryAnnotation:屬於Annotation一種類型和普通Annotation區別，這鍵值對形式標註在span中發生的事件，和一些其他相關的信息。
Annotation在整個跟蹤數據模型中最靈活的，靈活運用annotation基本能表達你所想到的跟蹤場景。在hydra中(參考了zipkin)定義4種不同value的annotation用來表達記錄span 4個最基本的事件。通過這4個annotation能計算出鏈路中業務消耗和網絡消耗時間。
如圖所示的應用場景對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對，記錄任何跟蹤系統想記錄的信息，比如服務調用中的異常信息，重要的業務信息等等。
Hydra中跟蹤模型和dubbo模型之間關係:
架構
京東內部，尤其是我們部門有很多業務系統使用dubbo作爲服務調用框，所以我們的分佈式跟蹤系統第一個接入組件就是dubbo。另一個原因也是因爲我們團隊對dubbo有着非常深入的理解，加之dubbo本身的架構本身十分適合擴展，作爲服務調用框架而言，跟蹤的效果會非常明顯，比如Twitter的Zipkin也是植入到內部的Finagle服務調用框架上來進行跟蹤的。
對於分佈式跟蹤系統而言，必須對接入的基礎組件進行改造，我們對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提供服務。
考慮到數據量不大的情況，以及部署的複雜度。我們提供了兩種更簡便的架構。
- 如果考慮到數據量沒有那麼大，可以不使用hbase，因爲畢竟hadoop集羣和hbase集羣的部署和維護工作量很大。也就是hydra-collector-service使用mysql做存儲。
- 如果併發量也不是很大的話，可以不使用消息中間件，在hydra-collector端直接進行數據落地，當然仍然是異步的。如圖所示。
在使用mysql進行存儲的時候我們並未進行分庫分表，因爲考慮到存儲的是監控數據，時效性較高，而長期的監控數據的保留意義並不大。所以我們在主表上有明確的時間戳字段，使用者可以自行決定何時對保存的歷史數據進行遷移。
現有功能
當前hydra1.0版的功能並不多，主要有針對服務名、時間、服務調用響應時間、是否發生異常這幾個條件進行查詢。如下圖所示：
對於每一次跟蹤，我們可以進一步展示他的服務調用層級與響應時間的時序圖。如下圖所示：
我們參考Dapper中論述的場景，用綠色代表服務調用時間，淺藍色代表網絡耗時，另外如果服務調用拋出異常被hydra捕捉到的話，會用紅色表示。鼠標移動到時序圖中的每一個對象上，會Tip展現詳細信息，包括服務名、方法名、調用時長、Endpoint、異常信息等。
