【CSDN 編者按】在以微服務和容器化為主導應用的現代化浪潮下，系統的可觀測性變得越來越重要，而鍊路追蹤技術就成為軟體系統實作“無人駕駛”的關鍵手段。本文作者認為，可觀測不僅是對軟體性能和故障的監控，更需要從業務名額出發，以業務視角評價軟體穩定性，讓IT真正成為驅動金融業務成長的數字化原動力。原文出處：《新程式員005：開源深度指南 & 新金融背後的科技力量》
聲明：本文為 CSDN 邀約作者原創，未經允許，禁止轉載。
（注：紙書将于春節後快遞，小程式訂閱立即生效）作者 | 張冀責編 | 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域控等管理系統中，新工具需要融合到這個環境裡。
分批接入，快速見效
消金公司内部應用較多，雙方根據應用技術架構特點進行分級、分批次接入。
- 第一批以面向C端的App應用為主，後端服務基本上都是Java Spring Cloud技術體系的應用，監控項是App後端服務，對響應時間和使用者體驗較為敏感，優先接入。
- 第二批以基礎服務類系統為主，Java為主。
- 第三批以後端業務管理類的大型應用、大資料應用為主，Java、Python共存，逐漸伴随系統疊代節奏陸續上線。
依照接入政策快速取得效果：
- 一周内完成第一批系統的接入和生産環境的上線。
- 一個月完成70%的應用接入。
- 如圖2所示，三個月完成大部分應用接入，整體接入應用數量接近700個，實時監控方法數量達6.6萬個，平峰監控TPS達到16W。由于前期接入時間控制比較理想，接入成本較低，最終實作了管理層預期的監控管理目标。
圖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，對齊科技部門和業務部門的目标，是企業數字化的關鍵，本質是從科技輔助業務，到科技和業務的知行合一。
- 從人工智能角度的根因定位一體化。
金融機構對AIOps的需求日益增強，機器學習本質是一種機率決策方法，而鍊路追蹤通過調用關系建構的根因識别機制，則是确定性決策。兩者的結合，通過應用調用鍊，穿透到下層各種基礎設施，形成立體化和智能化的AIOps新能力，國外頭部科技公司已經開始探索。
- 從敏穩過渡角度的技術演進一體化。
金融機構大量使用ESB企業服務總線，而ESB一直是監控的難點。京東科技已經基于Service Mesh研發下一代分布式ESB系統，與鍊路追蹤形成完善的解決方案，将非微服務應用和多語言應用納入統一治理及監控架構，助力金融機構實作敏态和穩态的平滑過渡。
本文作者
張冀
京東科技集團雲原生資深架構師，北京理工大學碩士，曾就職于愛立信、中國移動等國際知名企業，金融信創講師，專注于雲計算和雲原生領域，擅長IaaS/PaaS/SaaS全棧架構設計。加入京東科技集團以來，主導多個頭部金融機構大型雲平台和數字化轉型項目，緻力于金融科技領域的創新研發和落地實踐。