Posted on 2021-06-04 15:36
為自己代言 閱讀(587)
評論(0) 編輯 收藏 所屬分類:
spring cloud 微服務
整體架構
從日志生成到抓取、存儲、分析、展現的多個系統間交互過程。
在復雜的分布式系統環境下，EagleEye是一個有廣泛用途的調用分析和問題排查工具。與一般的調用信息埋點日志相比，EagleEye埋點的一個顯著的不同點在于它的每條日志都有與每次請求關聯的上下文ID，我們稱為TraceId。通過TraceId，后期的日志處理時可以把一次前端請求在不同服務器記錄的調用日志關聯起來，重新組合成當時這個請求的調用鏈。因此，EagleEye不僅可以分析到應用之間的直接調用關系，還可以得到他們的間接調用關系、以及上下游的業務處理信息；對于調用鏈的底層系統，可以追溯到它的最上層請求來源以及中間經過的所有節點；對于調用鏈的上層入口，可以收集到它的整棵調用樹，從而定位下游系統的處理瓶頸，當下游某個應用有異常發生時，能迅速定位到問題發生的位置。
如上圖所示，應用A是接受到來自用戶瀏覽器的Web請求的前端服務器，它是一條調用鏈的開始端，在TBSession和EagleEyeFilter中都做了EagleEye上下文埋點。請求收到后它會先調用EagleEye StartTrace生成TraceId并放置在當前線程的ThreadLocal，日志埋點請求信息（如URL、SessionId、UserId等）。在請求處理完畢提交相應時，再調用EndTrace清理線程中的EagleEye信息。 在應用A調用應用B、C的HSF服務，或者發送Notify消息時，TraceId被包含在EagleEye上下文中，隨網絡請求到達應用B、C、D、E之中，并放置在線程ThreadLocal內，因此后續調用到的這些系統都會有EagleEye這次請求的上下文。這些系統再發起網絡請求時，也類似的攜帶了上下文信息的。
為了區別同一個調用鏈下多個網絡調用的順序和嵌套層次，EagleEye還需要傳輸和記錄RpcId。 RpcId用0.X1.X2.X3.....Xi來表示，Xi都是非負整數，根節點的RpcId固定從0開始，第一層網絡調用的RpcId是0.X1，第二層的則為0.X1.X2，依次類推。*例如，從根節點發出的調用的RpcId是0.1、0.2、0.3，RpcId是0.1的節點發出的RpcId則為0.1.1、0.1.2、0.1.3。如下圖所示
通過RpcId，可以準確的還原出調用鏈上每次調用的層次關系和兄弟調用之間的先后順序。 例如上圖應用 G 的兩次調用0.2.1.1和0.1.2.1，可以看出對 DB 的訪問0.2.1.1源于 C 到 G 的調用0.2.1，對 Tair 的訪問0.1.2.1源于B 到 G 的調用0.1.2。 很多調用場景會比上面說的完全同步的調用更為復雜，比如會遇到異步、單向、廣播、并發、批處理等等，這時候需要妥善處理好ThreadLocal上的調用上下文，避免調用上下文混亂和無法正確釋放。另外，采用多級序號的RpcId設計方案會比單級序號遞增更容易準確還原當時的調用情況。