世界聚焦：分布式鏈路追蹤在數字化金融場景的最佳實踐

【CSDN 編者按】在以微服務和容器化為主導應用的現代化浪潮下，系統的可觀測性變得越來越重要，而鏈路追蹤技術就成為軟件系統實現“無人駕駛”的關鍵手段。本文作者認為，可觀測不僅是對軟件性能和故障的監控，更需要從業務指標出發，以業務視角評價軟件穩定性，讓IT真正成為驅動金融業務成長的數字化原動力。

原文出處：《新程序員005：開源深度指南 & 新金融背后的科技力量》

（注：紙書將于春節后快遞，小程序訂閱立即生效）

(資料圖片)

作者 | 張冀

責編 | Carol

出品 | CSDN（ID：CSDNnews）

微服務是近幾年最流行的軟件架構設計理念，和容器、DevOps一起構成了云原生的技術基礎。微服務源于對產品快速交付的市場訴求，通過采取一系列的自動化測試、持續集成等敏捷開發實踐，激活組織效率，增強軟件的可復用性，無形中為中臺化演進鋪平了道路。

然而，很多企業在引入微服務架構后，并沒有達到預期效果。熱力學第二定律告訴我們，一個孤立系統一定會向熵增的方向，也就是越來越復雜的方向演進。服務劃分過細，單個服務的復雜度降低了，整個系統的復雜度卻指數級上升。理論上計算，n個服務的復雜度是n×(n-1)/2，微服務將系統內的復雜度轉移為系統間的復雜度，如圖1所示，因此團隊陷入混沌，反倒拖慢了交付速度。

圖 1 微服務導致系統整體復雜性增加

如何解決軟件工程領域“熵增”的困境，真正享受微服務帶來的紅利？一方面需要通過一系列DevOps工具和方法使組織架構匹配軟件架構，使新技術為我所用，而不是成為工具的奴隸；另一方面，則需要在可觀測領域引入上帝視角，即分布式全鏈路追蹤技術，完全掌控微服務間的調用關系，從而發現故障和性能瓶頸所在。

全鏈路追蹤技術起源于Dapper的論文和實踐，在開源領域涌現出Zipkin、Pinpoint、SkyWalking等大量優秀產品。金融業一直是引入IT新技術的急先鋒，在數字化金融領域落地鏈路追蹤，除了要解決高可靠、自動容災等商用問題，還要降低觀測對業務的資源損耗，最重要的是將業務KPI映射到IT及軟件SLA，從而使軟件鏈路真正反映業務交易的價值鏈路。在這些方面，我們和國內某頭部消費金融公司合作，在金融數字化領域開展了云原生和全鏈路追蹤的最佳實踐。

鏈路追蹤落地數字金融

某頭部消費金融公司是一家持牌消費金融機構，其普惠金融App產品注冊人數過億，用戶活躍度高、流量大；App服務端和后端各類業務系統數量眾多、場景復雜，業務運營與技術運維團隊壓力很大；自建了FASTX基礎監控體系，融合了網絡層、主機層的監控和告警模塊，同時基于開源框架Pinpoint搭建鏈路追蹤系統。但受制于Pinpoint性能損耗大、監控粒度粗、不能靈活啟停監控項、缺少豐富的監控指標和業務監控體系等問題，應用監控效果不是很理想。引入商用鏈路追蹤技術納入統一監控體系，在落地融合過程中經歷了以下幾個階段。

對接管控，體驗一致

消金公司有獨立的告警通道管理，用戶/應用/設備的基礎信息存儲在NCMDB、AD域控等管理系統中，新工具需要融合到這個環境里。

分批接入，快速見效

消金公司內部應用較多，雙方根據應用技術框架特點進行分級、分批次接入。

依照接入策略快速取得效果：

圖2 應用監控總體視圖

抓住痛點，優勢突破

新工具在推廣初期比較艱難，沒有必要全面鋪開，所以針對已使用Pinpoint系統的特點，推薦給業務方一個最佳功能使用路線，實現“應用-服務-方法-實例”四層細粒度的監控體系；確定關鍵方法的返回碼和自定義業務字段，構建可用的業務成功率觀測指標，協助業務方關注重點告警項和告警策略。

在業務方接入鏈路追蹤技術后，無須過多人工配置就快速實現“應用-服務-方法-實例”四層細粒度的監控體系；同時引導業務，梳理出需要被監控的核心方法，通過觀測業務成功率指標，順利引入到調用查詢、調用鏈路、耗時分析、日志聯動查詢這條核心功能主線上。隨著公司交易的黃金鏈路的接入，整體業務監控開始有序展開。

循序漸進，全面推廣

如何讓業務方、研發團隊、系統運維團隊在同一個監控平臺獲得最大收益？雙方團隊協商了推廣思路，立足于以應用為中心，充分挖掘監控數據的價值，從開發、應用運維、業務運營三個視角分層對指標分類，全面接入全公司業務，讓業務KPI成為研發、運維人員的共同KPI。消金公司反饋了大量新的使用場景，如在京東內部未遇到的Kafka JMX Client沖突問題、Tomcat Request信息經歷Recycle后提取自定義業務字段失效的問題等，使鏈路追蹤技術在金融場景中錘煉得更加完善。

在長期服務內部業務與外部銀行、證券、保險、清算中心等客戶的數字化轉型過程中，本文總結了分布式鏈路追蹤的若干最佳實踐場景，用上帝視角俯瞰全局，充分發揮微服務架構的敏捷特性。

面向研發排障的實踐

如何精準定位故障？

業務應用性能問題頻發、流量波動頻繁、突發異常排查過程困難，故障爆發時的現場環境沒有快照，事后只能依賴系統日志和團隊成員技能進行排查， 沒有一套行之有效、可重復利用的分析套路和技術支撐手段；對于追求服務SLA保障能力的消金公司技術團隊來說，如何精準定位問題，縮短排查問題的時間，是一個巨大的考驗。

如圖3、圖4所示，全鏈路實時日志采集快速還原了現場，在應用被監控方法發生異常之初，通過內置告警模塊將告警信息及時推送到業務應用相關方；告警將提示應用的方法耗時、平均響應時間、頻率頻次、JVM監控，以及多維度的TP9XX/AVG/MAX系列性能指標；同時告警信息將相關的排查線索入口組織到一起，方便業務工程師介入排查。通過告警入口串聯提供的一系列排查工具，包括調用查詢、耗時詳情、調用鏈、拓撲圖譜、拓撲調用鏈性能分布、JVMGC分析、網絡連接、JVM內存工具箱等，排查過程順暢，操作簡單又有效。

圖3 應用告警信息

圖4 應用性能指標

如何處理底層IO級別的問題？

應用系統在運行過程中，經常出現底層IO級別的錯誤，包括關系型數據庫、 NoSQL數據庫、緩存、Logger框架、MQ框架等，高頻出現的問題經常混雜在日志文件里，容易被忽略最終導致生產事故。

如圖5所示，內置一站式底層IO各類異常的探測規則和閾值，應用接入即獲得標準的探測告警能力，識別問題源頭，從容應對生產系統的異常。

圖5 底層IO級別告警

如何分析服務耗時？

在微服務架構體系下，調用耗時分布實現監測是一個難點，除了服務本身的開銷外，網絡開銷、跨機房延時、網絡丟包、服務端線程池阻塞、服務鏈路的熔斷、限流等措施的影響、服務端GC影響、客戶端GC的影響，都構成整個分布式調用的開銷。

通過協同底層主機監控和微服務上下游調用關系，形成全局視角的調用耗時監控。如圖6所示，實現了針對微服務跨主通信模式耗時的精準統計和問題定位。通過探針靜態掃描和動態埋點的方式，基于字節碼增強技術，實現被監控方法的動態埋點監控，探針內部實現了多種技術框架和底層中間件、數據操作驅動程序的埋點；統一在單線程模型、線程池模型、CallBack模型下Trace信息的采集，形成標準的Context信息，統一存儲并跨系統傳遞；從業務視角提供包括機房、分組、應用、服務、方法、實例等多種維度級別的監控視圖。

圖6 服務耗時分析

（注：紙書將于春節后快遞，小程序訂閱立即生效）

面向應用運維的實踐

如何做到有效告警？

告警中出現大量重復信息，有效信息和重復信息混雜在一起，經常干擾運維人員。基于基線告警是一個方式，包括全局告警、應用告警、方法告警三個維度；基于業務架構，結合數據流關系，通過時間相關性、權重算法進行根源告警分析；通過邏輯回歸、協同過濾等機器學習算法等構建模型進行數據挖掘，找出各個系統之間的關聯，過濾長期未影響業務使用的告警，快速定位根源告警，并通過拓撲圖/列表的方式向用戶展示根源告警的調用關系。

如何做好業務容量評估？

消金公司各個業務的調用量波動較大，業務間量能變化差異也較大，業務容量評估一直沒有找到靠譜的抓手和數據支撐點。如何平衡資源利用率和保障服務可用率與用戶體驗的矛盾經常困擾著技術團隊。

現有技術評估容量都局限于人為壓測評估或者靜態評估，取代壓測評估方式，通過程序智能計算應用容量，將靜態的容量評估變成動態的容量評估，使實時的容量評估和彈性伸縮成為可能。如圖7所示，展示了應用容量的評估方法，通過獲取到的方法耗時明細，結合連接數、線程池等指標，得出應用的單機容量，在此基礎上綜合分析CPU、磁盤、網絡帶寬等指標的瓶頸，取最小值作為系統的最終單機容量，所有單機實例疊加得到應用總體的當前容量。

圖7 應用容量評估

面向業務運營的實踐

如何評估可用率、失敗率？

消金公司技術團隊可以通過成功率和可用率來客觀評估應用的實時健康狀態，通過返回碼分類監控觀測業務運行是否符合預期目標。除了失敗率、可用率指標，附加性能指標波動變化的數據、日志和容量的數據，構建一個多維的、面向應用的綜合健康度評價指標體系。

如何將監控數據轉化為業務語言？

監控早期階段，某消金公司技術團隊嘗試基于開源Pinpoint采集監控數據，缺少豐富的圖表定制和可視化展示模塊，導致監控數據沒有發揮應有的作用。隨著業務快速發展，面向C端的用戶流量持續攀升，技術團隊面臨較大的壓力。如圖8所示，通過豐富的圖表，包括調用量、性能TP、AVG、MAX指標監控圖表、失敗率、可用率、監控雷達圖、應用大盤等模塊，應用系統可以快速上手構建基礎的監控態勢感知環境。

圖8 應用監控圖表

總結和展望

展望分布式鏈路追蹤技術在金融科技領域的發展，我們認為有三個主要方向：

打通移動端和服務端，從用戶體驗角度實現端到端的全鏈路監控。用戶體驗如手機銀行、網貸、移動支付等代表了業務收入KPI，對齊科技部門和業務部門的目標，是企業數字化的關鍵，本質是從科技輔助業務，到科技和業務的知行合一。

金融機構大量使用ESB企業服務總線，而ESB一直是監控的難點。京東科技已經基于Service Mesh研發下一代分布式ESB系統，與鏈路追蹤形成完善的解決方案，將非微服務應用和多語言應用納入統一治理及監控框架，助力金融機構實現敏態和穩態的平滑過渡。

本文作者

張冀

京東科技集團云原生資深架構師，北京理工大學碩士，曾就職于愛立信、中國移動等國際知名企業，金融信創講師，專注于云計算和云原生領域，擅長IaaS/PaaS/SaaS全棧架構設計。加入京東科技集團以來，主導多個頭部金融機構大型云平臺和數字化轉型項目，致力于金融科技領域的創新研發和落地實踐。

責任編輯：Rex_25