Zi 字媒體

作者｜朱健榮 編輯｜雨多田光 網上商場大促時，快速發現問題並精準定位根因所在是保障活動順利進行的關鍵任務。HIRO 調用鏈監控系統在 818 蘇寧發燒節期間為商城系統保駕護航，抗住了壓力，這其中的設計經驗值得借鑒。 當顧客在蘇寧易購下單出現異常時，問題究竟出在會員系統、價格系統、庫存系統、支付系統……？技術人員面對複雜的系統構成與系統交互，如果在缺乏有效的監控機制情況下，想準確高效的定位問題是很困難的。我們可以想象到一般大促保障的場景：系統負責人和技術人員在現場通過拉取業務 / 系統日誌進行問題排查，耗費大量工時后才發現根因，僅僅是一條 SQL 語句遲遲沒有返回導致。但究竟是什麼原因導致的呢？是網路問題、資料庫服務端問題、還是客戶端問題？……由於大促保障需要的是 時效性，如何能夠 快速發現問題並精準定位根因所在 成為關鍵，因此蘇寧雲跡調用鏈監控系統（以下簡稱 HIRO）應運而生。調用鏈監控系統簡介把用戶發起的每次請求生成一個全局 ID（以下統稱為 TraceId），通過它們將不同系統採集的日誌按照時序和調用邏輯串起來，組成一條條鏈路，這就是 調用鏈。調用鏈監控系統就是用這種技術來理解系統行為用於分析性能問題的一種工具。作用調用鏈監控系統是基於網路調用日誌的分散式跟蹤系統，它可以分析網路請求在各個分散式系統之間的調用情況，從而得到處理請求的調用鏈上的入口 URL、應用、服務的調用關係，從而找到請求處理瓶頸，定位錯誤異常的根源位置。同時，業務方也可以在調用鏈上添加自己的業務埋點日誌，使各個系統的網路調用與實際業務內容得到關聯。在實際應用中，每一個請求過來后，會經過多個業務系統並留下足跡，併產生對各種 Cache 或 DB 的訪問，但是這些分散的數據對於問題排查，或是流程優化都幫助有限。對於這麼一個跨進程 / 跨線程的場景，匯總收集 並 分析海量日誌 就顯得尤為重要。具體要求能夠做到：追蹤每個請求的完整調用鏈路收集調用鏈路上每個服務的性能數據計算性能數據和比對性能指標（SLA）在出現故障后能精確的給出有問題的鏈路詳情並且精確報警甚至給出解決此故障的一般性方法。使用場景應用運行時突然發現執行某一個服務耗時很長，此時希望能夠有一種方式定位運行時代碼各個部分的耗時，以確定耗時點在什麼地方應用運行時一切正常，絕大部分情況下服務運行都非常順暢，但有用戶反饋，當傳入 xxx 參數時，服務響應非常緩慢，此時希望能夠有一種方式針對特定的方法入參來觀察代碼執行情況一個業務邏輯比較複雜的程序方法，在運行時無法確定具體調用了哪些邏輯以及調用時序，此時希望能夠有一種方式詳細地展現出方法執行的具體邏輯、時序等蘇寧 HIRO 實現原理中間件研發中心從 2015 年開始著手研究調用鏈的相關技術，截至 2017 年 7 月底 HIRO 已經承載了 530 個系統，其中核心繫統超過 60 個。HIRO 能夠分析分散式系統的每一次系統調用、消息發送和資料庫訪問，從而精準發現系統的瓶頸和隱患。目前每天經過 HIRO 分析的鏈路總量超過億條，監控日誌峰值達 500 萬消息 / 秒。HIRO 有如下特性：它是基於位元組碼、日誌的分散式跟蹤系統侵入性低，安全穩定基於大數據分析安裝部署簡單，Agent 自動升級每次請求都生成全局唯一的 TraceId，通過 TraceId 將不同系統採集的日誌串在一起，組成調用鏈支持對部分 C/C++ 系統場景的調用穿透支持業界主流的 Java 應用伺服器，包括：WildFly、WebSphere Application Server、WebLogic、Tomcat 等支持多種資料庫和緩存，包括：MySQL、Oracle、DB2、Redis 等支持消息中間件 Kafka，MQ（JMS Base）支持蘇寧內部 RPC 框架（RSF）架構HIRO 整體分為四層，從底層到前端分別是：第一層：在各應用伺服器上埋點 Agent 並用 Flume 採集所有埋點的日誌第二層：用 Spark 對日誌進行分析和統計第三層：把計算結果保存在 Elasticsearch 中第四層：前端 Portal 的展示具體架構如下圖所示：與之相對應的，HIRO 內部共分為三大塊，分別是 Agent、Spark 實時計算和 Spark 離線計算。其各部組件如圖所示：埋點和輸出日誌在前端請求到達伺服器時，應用容器在執行實際業務處理之前，會先執行埋點邏輯。埋點邏輯為這個前端請求分配一個全局唯一的 TraceId，然後把它放在一個調用上下文對象中，該對象會存儲在 ThreadLocal 裡面。調用上下文里還有一個 ID 非常重要，在 HIRO 中被稱作 RpcId，它用於區分同一個調用鏈下的 多個網路調用 的發生順序和嵌套層次關係。當執行業務處理時需要發起 RPC 調用時，蘇寧 RPC 遠程服務框架 (以下簡稱 RSF) 會首先從當前線程 ThreadLocal 上面獲取之前 HIRO 設置的調用上下文。然後，把 RpcId 遞增一個序號。在 HIRO 里使用多級序號來表示 RpcId，比如前端剛接到請求之後的 RpcId 是 0，那麼它第一次調用 RPC 服務 A 時，會把 RpcId 改成 0.1。之後，調用上下文會作為附件隨這次請求一起發送到遠程的 RSF 伺服器。RSF 服務端收到這個請求之後，會從請求附件里取出調用上下文，並放到當前線程 ThreadLocal 上面。如果服務 A 在處理時，需要調用另一個服務，這個時候它會重複之前提到的操作，唯一的差別就是 RpcId 會先改成 0.1.1 再傳過去。服務 A 的邏輯全部處理完畢之後，RSF 在返迴響應對象之前，會把這次調用情況以及 TraceId、RpcId 都列印到它的訪問日誌之中，同時會從 ThreadLocal 清理掉調用上下文。下圖展示的是埋點和生成日誌的時序關係：下圖展示的是多個系統間的調用關係：輸出日誌時面臨如下挑戰：需要減少對業務線程的影響，降低資源消耗QPS 越高日誌產生越快，監控數據就越多對此，HIRO 的解決方案如下：非同步線程寫日誌無鎖循環日誌，按秒刷新對日誌大小做限制，對調用鏈做採樣，不破壞調用鏈構成日誌文件按大小滾動，自動清理收集和存儲日誌調用鏈的日誌分散在調用經過的各個伺服器上，離線分析需要將同一條鏈路上的日誌匯總在一起。HIRO 用 Flume 去採集全量的日誌，經過 Kafka 集群，最終全量存儲在 HDFS 中。匯總和重組鏈路由於實時收集的日誌上的鏈路都是分散的、斷斷續續的，這時需要通過 SparkStreaming 的計算功能，把相同的 TraceId 的鏈路分揀出來，組裝成一條完整的鏈路。下面給出了一個典型的調用鏈圖示（由於鏈路太過龐大隻能截取一小部分）：分析和統計調用鏈根據重組后鏈路中的應用、服務以及相互間關係進行數據建模，將分析出來的數據在應用層面和服務層面上統計出錯誤數、訪問量、最大耗時和平均耗時、依賴度等。同時利用 Elasticsearch 可以對 DB、Redis、RSF、ESB 做大盤分析，還可以統計出各個應用的報表和對比統計。下圖展示了一條鏈路分析后統計的數據：下圖展示了 DB 分析的結果：下圖展示了應用數據報表統計的結果HIRO 應用問題定位上圖是蘇寧生產環境的某一條實際鏈路。用戶收到告警：某個應用訪問失敗。通過 HIRO，可以清晰地看到該應用當前一條鏈路的詳情，這是因為底層的一個 HTTP 請求返回 404 導致訪問失敗。系統分析HIRO 不僅僅是用來做問題定位，還可以防範問題。如下圖所示，HIRO 管理員發現易購上的一條交易耗時較長引起警覺，通過 HIRO 的深入排查 沒有發現鏈路上有問題。但是謹慎起見把該耗時數據發給業務方，並提出是否由於配置不當或者當前系統壓力過大導致耗時過長的疑問，業務方根據此思路排查系統修改了相關參數后，耗時恢復到正常水平，避免了可能發生的系統故障。調用還原當用戶懷疑係統的業務流程有問題或者不是用戶預想的調用場景，HIRO 也可以派上用場。如下圖所示，前台銷售系統數據處理有問題，客戶懷疑是否是調用流程出錯，用 HIRO 查看拓撲后，發現調用少了一層，很快就定位到是哪段代碼的 bug 並及時修復。品質分析HIRO 可以統計出服務調用的次數，用戶能看到應用是否有大量無用調用的情況，從而反向檢查代碼，提高代碼的品質。如下圖所示，Redis 應用性能下降，經過 HIRO 的分析，發現是某個應用短期內頻繁訪問導致的，經過代碼分析，最終找到根本原因：業務邏輯出錯了，bug 修復后問題隨之解決。容量評估如果對同一個前端入口的多條調用鏈做匯總統計，也就是說，把這個入口 URL 下面的所有調用按照調用鏈的樹形結構全部疊加在一起，就可以得到一個新的樹形結構（如下圖所示）。這就是入口下面所有依賴的調用路徑的情況。這種分析能力對於複雜的分散式環境調用關係的梳理尤為重要。傳統的調用統計日誌是按固定時間窗口預先做了統計的日誌，上面缺少了鏈路細節導致沒辦法對超過兩層以上的調用情況進行分析。例如，後端資料庫就無法評估資料庫訪問是來源於最上層的哪些入口，每個前端系統也無法清楚確定當前入口由於大促活動流量翻倍，會對後端哪些系統造成多大的壓力，需要分別準備多少機器。有了 HIRO，這些問題就會迎刃而解。HIRO 未來規劃HIRO 在蘇寧才剛剛起步，但是已經向用戶展示了其強大的功能。為了進一步滿足用戶對 HIRO 的需求，未來 HIRO 將陸續完善和提供如下功能：進一步優化實時數據的處理機制，使得時延更低，達到真正的實時完善實時的錯誤發現及報警機制，進一步提高發現問題的及時性接入更多的中間件，進一步豐富調用鏈內容，使調用鏈更長更完整藉助深度學習演算法，充分運用數據挖掘技術把 HIRO 產出的數據價值化，力爭在更多維度上提供出有價值的分析數據提供各種 API 介面，將 HIRO 數據開放出來，方便用戶可以構建自己的調用鏈系統，從而達到對業務監控的效果作者介紹朱健榮，現任職於蘇寧雲商 IT 總部。主要負責中心產品推廣和技術保障工作。在蘇寧，經歷了多次 818、雙 11 等大促保障工作，深知應用系統的穩定對電商平台的重要性。現正在和研發團隊一起建設應用系統監控層整體解決方案，已經落地的產品有服務端和調用鏈監控、智能告警和決策分析平台等。 京東金融私有雲 HTTPS 性能優化實踐 混合雲融合了公有雲和私有雲，是近年來雲計算的主要模式和發展方向。混合雲的模式是通過公有雲 + 私有部署 + 專線網路方式為客戶提供行業解決方案，幫助客戶更快更簡單的使用雲計算，彌補了傳統 IT 架構在使用上的短板。這也正是中大型電商、企業服務、互聯網金融行業都選擇混合雲作為業務發展平台的原因。8 月 19 日，在北京北五環咖啡館將舉辦第二場 UCan 下午茶技術沙龍，屆時來自 UCloud、微博、蘑菇街的講師會分享混合雲自動化、混合雲網路架構設計，BaaS 服務和雲服務運維方向的內容。