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

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

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

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

(資料圖片)

作者 | 張冀

責(zé)編 | Carol

出品 | CSDN（ID：CSDNnews）

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

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

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

鏈路追蹤落地?cái)?shù)字金融

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

對接管控，體驗(yàn)一致

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

分批接入，快速見效

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

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

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

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

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

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

循序漸進(jìn)，全面推廣

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

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

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

如何精準(zhǔn)定位故障？

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

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

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

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

如何處理底層IO級(jí)別的問題？

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

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

圖5 底層IO級(jí)別告警

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

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

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

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

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

面向應(yīng)用運(yùn)維的實(shí)踐

如何做到有效告警？

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

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

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

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

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

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

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

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

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

監(jiān)控早期階段，某消金公司技術(shù)團(tuán)隊(duì)嘗試基于開源Pinpoint采集監(jiān)控?cái)?shù)據(jù)，缺少豐富的圖表定制和可視化展示模塊，導(dǎo)致監(jiān)控?cái)?shù)據(jù)沒有發(fā)揮應(yīng)有的作用。隨著業(yè)務(wù)快速發(fā)展，面向C端的用戶流量持續(xù)攀升，技術(shù)團(tuán)隊(duì)面臨較大的壓力。如圖8所示，通過豐富的圖表，包括調(diào)用量、性能TP、AVG、MAX指標(biāo)監(jiān)控圖表、失敗率、可用率、監(jiān)控雷達(dá)圖、應(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ā)展，我們認(rèn)為有三個(gè)主要方向：

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

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

本文作者

張冀

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

責(zé)任編輯：Rex_25