分布式链路追踪在数字化金融场景的最佳实践

Posted 2023-01-27 CSDN资讯

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式链路追踪在数字化金融场景的最佳实践相关的知识，希望对你有一定的参考价值。

【CSDN 编者按】在以微服务和容器化为主导应用的现代化浪潮下，系统的可观测性变得越来越重要，而链路追踪技术就成为软件系统实现“无人驾驶”的关键手段。本文作者认为，可观测不仅是对软件性能和故障的监控，更需要从业务指标出发，以业务视角评价软件稳定性，让IT真正成为驱动金融业务成长的数字化原动力。

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

声明：本文为 CSDN 邀约作者原创，未经允许，禁止转载。

亲爱的 CSDN 以及《新程序员》的读者朋友们，春节将至，《新程序员005：开源深度指南 & 新金融背后的科技力量》也正式与大家见面！现在，点击下方封面，即可订阅，立享电子书，纸质书将在春节后为大家寄出，届时将会有信息及时发送快递信息。感谢这一路走来的陪伴，期待 2023 年继续深入技术世界，一起驰骋。

（注：纸书将于春节后快递，小程序订阅立即生效）

作者 | 张冀

责编 | 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指标监控图表、失败率、可用率、监控雷达图、应用大盘等模块，应用系统可以快速上手构建基础的监控态势感知环境。