如其他大中型網際網路應用一樣，微博平臺由眾多的分散式元件構成，使用者通過瀏覽器或移動客戶端的每一個HTTP請求到達應用伺服器後，會經過很多個業務系統或系統元件，並留下足跡（footprint）。但是這些分散的資料對於問題排查，或是流程優化都幫助有限。對於這樣一種典型的跨程序/跨執行緒的場景，彙總收集並分析這類日誌就顯得尤為重要。另一方面，收集每一處足跡（footprint）的效能資料，並根據策略對各子系統做流控或降級也是確保微博平臺高可用的重要因素。要能做到追蹤每個請求的完整呼叫鏈路；收集呼叫鏈路上每個服務的效能資料；通過計算效能資料和比對效能指標（SLA）再回饋到控制流程（control flow）中，基於這些目標就誕生了微博的Watchman系統。在業界，Twitter的Zipkin和淘寶的鷹眼系統也是類似的系統。

這樣的系統通常有幾個設計目標：

1. 低侵入性（non-invasivenss）：作為非業務元件，應當儘可能少侵入或者不侵入其他業務系統，保持對使用方的透明性，可以大大減少開發人員的負擔和接入門檻。
2. 靈活的應用策略（application-policy）：可以決定所收集資料的範圍和粒度。
3. 時效性（time-efficient）：從資料的收集和產生，到資料計算/處理，再到展現或反饋控制，都要求儘可能得快速。
4. 決策支援（decision-support）：這些資料資料是否能在決策支援層面發揮作用，特別是從DevOps的角度。

Watchman系統架構圖

對於這些設計目標，Watchman系統是怎麼樣做的呢？

• 既然要追蹤呼叫鏈路要收集資料，通常的做法就是通過程式碼埋點來記錄日誌。這樣一方面要求在所有需要收集資料的地方侵入程式碼進行修改，並且（可能）引入新的依賴。比如淘寶的鷹眼系統在跨程序的遠端呼叫兩側（stub和skeleton）通過埋點記錄資料並傳遞請求上下文（request-context）。

  watchman-runtime元件利用位元組碼增強的方式在載入期織入增強邏輯（load-time weaving），為了跨程序/執行緒傳遞請求上下文，對於跨執行緒watchman-enhance元件通過javaagent的方式在應用啟動並載入class時修改了JDK自身的幾種執行緒池（ThreadPool或幾類Executor）實現，在客戶程式碼提交（execute或submit）時對傳入的runnable/callable物件包上具有追蹤能力的實現（proxy-pattern），並且從父執行緒上去繼承或初始化請求上下文（request-context）；如下圖所示：

  

  而對於跨程序的RPC場景，則動態增強傳輸層的客戶端和服務端的邏輯。微博平臺使用的Motan RPC框架有著類似filter-chain的流程，watchman-aspect會插入自己的filter實現；實現的邏輯就是在RPC請求前獲取請求方的請求上下文，序列化後裝配近請求體中，服務方獲取請求後，再從請求體中反序列化請求上下文，同時設定到執行緒上下文中（ThreadLocal）。如下圖所示：

  

  這類增強或修改都在執行期完成，對於開發人員完全透明，對於運維人員也很友好；

  普通Java呼叫的處理方式（埋點/追蹤）則是通過AspectJ的靜態織入，相信廣大讀者對AspectJ都不陌生，它提供非常強大的AOP的能力，我們使用AspectJ來定義幾類切面，分別針對WeiboAuth、HTTP介面、資源客戶端的下行方法等。再利用AspectJ的語法定義各個切點，形如：

  @AfterReturning(value="execution(public $type $signature($param))",returning="$return"
  

  之後在目標專案的maven構建過程中依靠ajc進行編譯期的織入。之所以選擇編譯期織入方式是因為我們的業務場景是十分performance-sensitive的。每一個生效的切點也會在執行時向configserver註冊SLA資料。（這個後面會講到）

• watchman-core元件內建幾類策略，分別用來控制收集資料的範圍、收集資料的取樣率、以及幾種控制策略。

  每個請求進入Watchman系統的邊界後（在這裡是微博平臺Auth系統），通過這些策略來決定哪些足跡需要記錄，比如REST API、RPC呼叫、儲存/快取的操作等；同時也通過策略決定本次請求是否需要取樣，取樣率可以動態修改；之後建立請求上下文並向後傳遞。在每一個控制點，又會根據控制策略來確定對本次請求是否丟棄，或是對整個方法以什麼樣的方式來gracefully degrade等；

  我們先來看下請求上下問（request-context）的簡單定義：

  

  RequestContext類關聯一個閥門策略介面（ThrottleStrategy）和取樣策略介面（SampleStrategy），每個req-ctx例項被構造時會傳入兩個策略的具體實現。在記錄（trace()）時，會根據當前取樣策略來決定是否採集資料，並且策略可以動態更新，包括本地配置檔案的方式，或者同步configserver的方式。從完全關閉、百萬分之一到全量採集幾個粒度可以選擇。

  閥門策略，顧名思義，就像一個閥門，用來控制流量的大小，或是開啟/關閉。預設是全開的，因為認為業務99.999%是可用的，同時源源不斷的效能資料會被收集，在watchman-stream進行彙總計算後會產生與註冊在configserver中的SLA資料的比對結果。比如A服務的效能統計結果低於SLA水平，那麼就會通知到閥門策略，並通過隨機丟棄請求的方式來做流控，當效能結果嚴重低於SLA時就關閉，達到降級的效果。

  網際網路運維中對降級還有一個指標是，是否能優雅的降級，也就是不損害使用者體驗的情況下進行降級。這一點watchman-aspect會根據程式碼上的註解（annotation）來實現，@Degradable可以標註在方法上，可以指定returnType（required）和returnValue（optional），降級時根據returnType來生成偽造的結果並返回，如果使用方有指定returnValue就直接用後者返回，如果預設提供的returnType不滿足需要也可以進行擴充套件。

• watchman-aspect元件通過非同步日誌（async-logger）會在各個節點上輸出日誌檔案，如何將這些分散的日誌源源不斷的收集彙總並計算？

  通過watchman-prism元件（基於Scribe），將日誌推送到watchman-stream元件（基於Storm），利用這兩個業界成熟的系統以流式的方式處理資料，stream中bolt會根據需求進行聚合、統計等計算（針對性能資料），規範化、排序（針對呼叫鏈資料），之後寫入HBase中。這個過程通過benchmark反映出的結果來看，完全能達到準實時的要求（30s左右）。 對於日誌資料推送：首先應用要以一致的方式輸出日誌，理所當然就是通過Log框架的logger來輸出，每個節點產生日誌後需要再依賴scribe推送到日誌中心，所以我們實現了自己的AsyncScribeAppender，如下：

  

  由於Scribe是基於Thrift進行通訊，所以我們的Appender擴充套件於Log4j的AppenderSkeleton，以普通Logger的API形式供上層使用（非同步），同時再作為一個ThriftClient直接將資料寫到節點上的ScribeClient，之後再通過網路把日誌推到遠端。watchman-prism在這裡作為遠端接受方，它是擴充套件於Scribe的一個ThriftServer。 而Storm這一側，眾所周知，spout元件作為資料的入口，分發到各個bolt進行流式計算，spout是拉（pull）的模式，它從watchman-prism中不斷取資料，經過簡單的過濾後發射（emit）到其他bolt，不同的bolt有著不同的計算任務，之後將不同緯度的計算資料寫入HBase中。

• 服務質量保障是Watchman系統的另一特點，在面向服務的架構（SOA）中，各個服務的提供方需要給出SLA（service level agreement）資料，量化服務的各種指標（如吞吐、承載）和服務質量（如99.99% <50ms）。這裡的服務包括http形式的REST API，RPC服務，DB或Cache的介面，以及網路IO層面等； 微博平臺的各業務方的每一層服務都會在Vintage（微博的類Zookeeper系統）中註冊自己的SLA資料，執行時watchman-stream將不斷計算得出的效能資料與通過watchman-registry獲得的各服務的SLA資料進行比對。結果會反映到Dashboard上，這裡與運維的告警系統等整合，可以及時將狀況推送出去，除此之外也會更新registry中的指標，ConfigService根據指標的變化判斷是否通知各個註冊的客戶方，也就是watchman-aspect，閥門策略就會根據通知調整閾值進行干預。流程如下：

  

  比如某個服務由於瞬時訪問高峰，造成底層資源壓力變大從而服務響應時間變長，控制策略可以根據設定隨機丟棄後續的請求，如果情況加劇就會自動降級該服務，保證核心服務路徑。整個過程可以自動完成也可以人工通過Dashboard控制。

Watchman系統的下一步

之後的迭代會進一步增強watchman-stream的計算/分析能力，爭取在更多的維度上挖掘出有價值的資料；同時依靠watchman-prism來彙總更豐富的業務日誌，力圖在一個請求鏈路上展現更豐富的上下文相關資料。

總之，為構建更健壯、更可靠的微博平臺，Watchman系統會繼續演進。