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

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

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

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

(資料圖片)

作者 | 張冀

責編 | Carol

出品 | CSDN（ID：CSDNnews）

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

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

圖 1 微服務(wù)導(dǎo)致系統(tǒng)整體復(fù)雜性增加

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

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

鏈路追蹤落地數(shù)字金融

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

對接管控，體驗一致

消金公司有獨立的告警通道管理，用戶/應(yīng)用/設(shè)備的基礎(chǔ)信息存儲在NCMDB、AD域控等管理系統(tǒng)中，新工具需要融合到這個環(huán)境里。

分批接入，快速見效

消金公司內(nèi)部應(yīng)用較多，雙方根據(jù)應(yīng)用技術(shù)框架特點進行分級、分批次接入。

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

圖2 應(yīng)用監(jiān)控總體視圖

抓住痛點，優(yōu)勢突破

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

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

循序漸進，全面推廣

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

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

面向研發(fā)排障的實踐

如何精準定位故障？

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

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

圖3 應(yīng)用告警信息

圖4 應(yīng)用性能指標

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

應(yīng)用系統(tǒng)在運行過程中，經(jīng)常出現(xiàn)底層IO級別的錯誤，包括關(guān)系型數(shù)據(jù)庫、 NoSQL數(shù)據(jù)庫、緩存、Logger框架、MQ框架等，高頻出現(xiàn)的問題經(jīng)常混雜在日志文件里，容易被忽略最終導(dǎo)致生產(chǎn)事故。

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

圖5 底層IO級別告警

如何分析服務(wù)耗時？

在微服務(wù)架構(gòu)體系下，調(diào)用耗時分布實現(xiàn)監(jiān)測是一個難點，除了服務(wù)本身的開銷外，網(wǎng)絡(luò)開銷、跨機房延時、網(wǎng)絡(luò)丟包、服務(wù)端線程池阻塞、服務(wù)鏈路的熔斷、限流等措施的影響、服務(wù)端GC影響、客戶端GC的影響，都構(gòu)成整個分布式調(diào)用的開銷。

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

圖6 服務(wù)耗時分析

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

面向應(yīng)用運維的實踐

如何做到有效告警？

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

如何做好業(yè)務(wù)容量評估？

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

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

圖7 應(yīng)用容量評估

面向業(yè)務(wù)運營的實踐

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

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

如何將監(jiān)控數(shù)據(jù)轉(zhuǎn)化為業(yè)務(wù)語言？

監(jiān)控早期階段，某消金公司技術(shù)團隊嘗試基于開源Pinpoint采集監(jiān)控數(shù)據(jù)，缺少豐富的圖表定制和可視化展示模塊，導(dǎo)致監(jiān)控數(shù)據(jù)沒有發(fā)揮應(yīng)有的作用。隨著業(yè)務(wù)快速發(fā)展，面向C端的用戶流量持續(xù)攀升，技術(shù)團隊面臨較大的壓力。如圖8所示，通過豐富的圖表，包括調(diào)用量、性能TP、AVG、MAX指標監(jiān)控圖表、失敗率、可用率、監(jiān)控雷達圖、應(yīng)用大盤等模塊，應(yīng)用系統(tǒng)可以快速上手構(gòu)建基礎(chǔ)的監(jiān)控態(tài)勢感知環(huán)境。

圖8 應(yīng)用監(jiān)控圖表

總結(jié)和展望

展望分布式鏈路追蹤技術(shù)在金融科技領(lǐng)域的發(fā)展，我們認為有三個主要方向：

打通移動端和服務(wù)端，從用戶體驗角度實現(xiàn)端到端的全鏈路監(jiān)控。用戶體驗如手機銀行、網(wǎng)貸、移動支付等代表了業(yè)務(wù)收入KPI，對齊科技部門和業(yè)務(wù)部門的目標，是企業(yè)數(shù)字化的關(guān)鍵，本質(zhì)是從科技輔助業(yè)務(wù)，到科技和業(yè)務(wù)的知行合一。

金融機構(gòu)大量使用ESB企業(yè)服務(wù)總線，而ESB一直是監(jiān)控的難點。京東科技已經(jīng)基于Service Mesh研發(fā)下一代分布式ESB系統(tǒng)，與鏈路追蹤形成完善的解決方案，將非微服務(wù)應(yīng)用和多語言應(yīng)用納入統(tǒng)一治理及監(jiān)控框架，助力金融機構(gòu)實現(xiàn)敏態(tài)和穩(wěn)態(tài)的平滑過渡。

本文作者

張冀

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

責任編輯：Rex_25