京东云分布式链路追踪在金融场景的最佳实践

微服务是近几年最流行的软件架构设计理念，和容器、devops 一起构成了云原生的技术基础。微服务源于对产品快速交付的市场诉求，通过采取一系列的自动化测试、持续集成等敏捷开发实践，激活了组织效率，也增强了软件的可复用性，无形中为中台化演进铺平了道路，大量国内外互联网公司因此获得了技术红利。

但是很多企业在引入微服务架构后，并没有达到预期效果。热力学第二定律告诉我们，一个孤立系统一定会向熵增的方向，也就是越来越复杂的方向演进。服务划分过细，单个服务的复杂度降低了，整个系统的复杂度却指数级上升。理论上计算，n 个服务的复杂度是 n×(n-1)/2，微服务将系统内的复杂度转移为系统间的复杂度，因此团队陷入混沌，反倒拖慢了交付速度。

如何解决“熵增”的困境，真正享受微服务带来的红利呢？一方面需要通过一系列 devops 工具和方法使组织架构匹配软件架构，使新技术为我所用而不是成为工具的奴隶；另一方面则需要在运维领域引入上帝视角，即分布式全链路追踪技术，完全掌控微服务间的调用关系。

京东云 SGM（Service Governance And Monitoring）产品承载了京东每天万亿级别的调用链数据分析和查询，护航双十一和 618 大促流量，让每一笔交易有迹可循，每一个故障无处遁形，具有极高的稳定性和极低的资源消耗。金融业一直是引入 IT 技术的急先锋，京东云将 SGM 产品和实践输出给业界大量银行和消金公司，赋能金融业数字化转型，取得了很好的效果，但是我们也发现部分客户的使用效果不够顺畅，究其原因，一方面是受限于用户技术环境，特别是传统金融客户，其技术栈偏向单体应用，封闭的商业软件产品较多，客户自身对产品应用的掌控度比较低，反观在偏互联网技术栈的消费金融领域，应用效果则相对比较好。除技术环境的制约因素外，另外一方面因素在于组织内是否具备构建全套监控体系的基础能力和对整个监控体系的认知程度，任何监控产品解决的是监控体系的一个方面，而不是全部，所有单一监控产品都存在盲点和局限性，就比如希望 NPM（Network Performance Monitor）监控能达到 APM（Application Performance Monitor）应用级监控的灵活性一样，这是不现实的。

在技术融合的背景下，京东云和某头部消费金融公司合作，在消费金融领域开展了云原生和全链路追踪的最佳实践。某消费金融公司是一家持牌消费金融机构，其普惠金融 APP 产品注册人数过亿，后端通过风控、智能客服等重量级业务系统进行支撑。前端用户活跃度高，流量大，APP 服务端和后端各类业务系统数量众多、场景复杂，整个系统运营与技术运维团队压力很大。

在任何组织里，监控应该是一项综合立体化的、体系化的大平台，需要多种监控工具的协作。SGM 全链路监控系统在整个监控体系占据中间偏向上层业务监控的位置，发力点是应用级性能监控、服务调用关系的监控、流量监控，主要特色是面向服务接口和方法，扩展点是基于方法监控实现多维度的业务监控，底层还需要有系统级的监控，基础主机监控、网络监控、数据库监控（偏物理资源和数据库本身管理维度）、日志监控系统等组件的配合，将粗粒度监控和细粒度监控相结合，自上而下把被监控对象组织起来。很多用户不能完全应用好 SGM 产品，往往存在监控盲点，而某消金公司自建了一套 FASTX 基础监控体系，融合了基础网络、主机、设备层的监控和告警模块，同时也基于开源框架 Pinpoint 二次开发搭建一套全链路监控系统，实现了应用级的链路监控。但受制于 Pinpoint 性能损耗大、监控范围较窄、监控粒度太粗、不能灵活启停监控项、缺少丰富的监控指标和业务监控体系，pinpoint 应用监控取得的效果不是很理想。

第一步：对接管控，体验一致

消金公司有独立的告警通道管理，用户/应用/设备的基础信息平台 NCMDB、AD 域控等管理系统，新产品需要融合到这个环境里。SGM 的认证模块及告警模块具有可插拔特性，通过 OPEN API 完成对接，实现用户管理与认证体系、告警体系与 SGM 产品深度协同，磨平系统间差异，形成统一的使用环境。业务应用方的接入门槛降低了，基础用户和告警融合到现有技术体系，保障一致性的使用体验。

第二步：分批接入，快速见效

消金公司内部应用较多，双方根据应用技术框架特点进行分级、分批次接入。SGM 对业务应用代码没有任何侵入改造，接入简单，适配了常见的开源技术框架，经梳理后分三批接入。

● 第一批以面向 C 端的 APP 应用为主，后端服务基本上都是 JAVA SpringCloud 技术体系的应用，监控项是 app 后端服务，对响应时间和用户体验较为敏感，优先接入。

● 第二批以基础服务类系统为主，Java 为主。

● 第三批以后端业务管理类的大型应用、大数据应用为主，Java、Python 共存，逐步伴随系统迭代节奏陆续上线。

取得效果：

● 一周内完成第一批系统的接入和生产环境的上线。

● 一个月完成了 70%的应用接入。

● 三个月完成大部分的应用接入，整体接入应用数量接近 700 个，实时监控的方法数量达到 6.6 万个，平峰监控 TPS 达到 16W，前期接入时间控制比较理想，接入成本较低，实现了管理层预期的监控管理目标。

第三步：抓住痛点，优势突破

新产品在推广初期比较艰难，业务方的排斥和现有习惯的改变都是推广的阻力，尤其在内部还存在可用的自研链路监控系统的情况下。

SGM 产品本身的功能项非常多，在初期没有必要全面铺开，所以针对某消金公司已有 pinpoint 链路监控系统的特点，推荐给业务方一个最佳功能使用路线，经过两轮专场培训辅导业务方实现应用-服务-方法-实例四层细粒度的监控体系，确定关键方法的返回码和自定义业务字段，构建可用的业务成功率观测指标，协助业务方关注重点告警项和告警策略。

SGM 产品在业务方接入后，无需过多的人工配置就快速为业务方实现应用-服务-方法-实例四层细粒度的监控体系，同时引导业务梳理关键出来需要被监控的核心方法，通过观测业务成功率指标，顺利引入到调用查询、调用链路、耗时分析、日志联动查询这条 SGM 核心功能主线上。这在 SGM 产品导入前期，起着至关重要的作用，应用的接纳和广泛的使用沉淀下来有效的数据，促使着监控系统健康运行，很顺利也很平稳地度过了 SGM 这个新事物介入期最困难的时刻，为后续深入应用奠定了坚实的基础。

第四步：循序渐进，全面推广

完成第一阶段初步推广和被业务方接纳后，如何让业务方、监控团队、系统运维团队在同一个监控平台获得更大的收益？双方团队协商了推广思路，立足于深度应用，充分挖掘体现监控数据的价值点，从开发视角、应用运维视角、应用运营分层指标监控、大屏态势感知等更深入使用的方向制定推广策略，形成可落地执行的方案全面推广 SGM 监控。

用户在深度使用过程中获得良好的收益和正向反馈，同时贴合消金公司的业务场景和技术特点，向我们 SGM 产品团队反馈了几个问题点，包括在京东内部场景未遇到的 Kafka JMXClient 冲突问题、Tomcat Request 信息经历 Recycle 后提取自定义业务字段失效的问题，促使 SGM 产品与客户共同成长，在更多金融场景中千锤百炼愈加完善。

在长期服务内部应用与外部客户的过程中，我们总结了分布式链路追踪的几个最佳实践场景，用上帝视角俯瞰全局，充分发挥微服务架构的敏捷威力：

一、面向研发排障的问题解决

1.典型问题：如何精准定位故障？

业务应用性能问题频发、流量波动频繁、突发异常排查过程困难，故障爆发时的现场环境没有快照，事后只能依赖系统日志和团队成员技能进行排查，没有一套行之有效，可重复利用的分析套路和技术支撑手段，对于追求服务 SLA 保障能力的消金公司技术团队来说，如何精准定位问题，缩短排查问题的时间，是个巨大的考验。

解决方案：得益于 SGM 全链路监控系统实时日志的采集能力和高效的处理能力，在应用被监控方法发生异常之初，会通过 SGM 内置的告警模块将告警信息及时推送到业务应用相关方，告警将提示应用的方法耗时、平均响应时间、频率频次、JVM 监控以及多维度的 TP9XX/AVG/MAX 系列性能指标，同时告警信息将相关的排查线索入口组织到一起，方便业务工程师介入排查。通过告警入口串联起 SGM 提供的一系列排查工具，调用查询、耗时详情、调用链、拓扑图谱、拓扑调用链性能分布、JVMGC 分析、网络连接、JVM 内存工具箱等，整个排查过程顺畅，操作简单又有效。

效果：通过内置到 SGM 的功能模块形成一套标准化的排查步骤和工具集，贴合主动告警模块，由 SGM 聚合一系列排查问题的小工具，快速还原问题现场，有效地辅助研发精准定位问题，快速排查问题。

2.典型问题：如何处理底层 IO 级别的问题？

应用系统在运行过程中，经常出现底层 IO 级别的错误，包括关系型数据库，NoSQL 数据库、缓存、Logger 框架、MQ 框架等，高频出现的问题经常混杂在日志文件里，容易被忽略最终导致生产事故。

解决方案：引导用户用好 SGM 告警模块，SGM 一站式内置底层 IO 各类异常的探测规则和阈值，应用接入即享有标准的探测告警能力，从容应对生产系统的异常。

效果：对底层 IO 类型的问题进行单独处理，提升告警等级，帮助业务应用建立起分层监控的认知体系，识别问题源头，及时优化告警策略，变被动为主动，提高底层 IO 问题的预警与处理能力，结合 SGM 排查问题工具箱快速处置。

3.典型问题：如何分析服务耗时？

在微服务架构体系下，调用耗时分布如何监测是一个难点，除了服务本身的开销外，网络开销、跨机房延时、网络丢包、服务端线程池阻塞、服务链路的熔断、限流等措施的影响、服务端 GC 影响、客户端 GC 的影响，都构成整个分布式调用的开销，某消金公司技术架构以 spring cloud 微服务为主，服务调用耗时分布以及出现问题时如何快速判定异常服务的归属是技术团队最为关注的问题。

解决方案：通过协同底层主机监控和 SGM 的链路跟踪，形成了全局视角的调用耗时监控，实现了针对微服务时代跨主通信模式服务耗时的精准统计和问题定位。SGM 提供应用、服务、方法、实例等多种级别的监控，同时基于每笔调用可以反查调用来源，追踪上下游的服务状态，观测服务性能波动的曲线，及时锁定问题服务，协调服务归属方进行联合问题排查。

效果：通过 SGM 产品可以清晰获得服务间依赖关系的信息，精准掌握服务调用耗时分布情况，对于消金公司团队来说，快速理清了业务依赖，定位问题服务，快速协同上下游服务一同排查问题，简单又高效。

二、面向架构治理的问题解决

4.典型问题：如何利用运行态数据进行服务治理？

业务快速迅猛，不断有新应用出现，实际运行态的服务运行状态可能已经偏离当时的架构规划，传统方式是基于架构文档进行服务治理，在迭代节奏加快，变更频繁的现状下，如何快速发现服务依赖问题，并且依托最真实的运行态数据进行服务治理？是消金公司团队最为关心的内容。

解决方案：SGM 产品给出的答案就是基于应用系统实时采集的日志，用监控日志数据辅助服务治理，深入应用调用全链路的众多信息形成分层的全局视图，暴露服务间真实的调用关系、调用频率、调用强度、上下游流量波动状态，SGM 提供了调用全链路分析功能和分层下钻、上钻，调用来源分析、调用拓扑、拓扑性能监测、实时调用拓扑图等工具集，重点破解服务瓶颈点，拆解不合理的服务模块，组合处于分散游离的服务，不断摸索调整，并及时观测变更数据再优化的新模式。

效果：在消金公司内部服务治理场景得到不断的深入应用，且技术团队在持续摸索中形成一个有效的治理思路和方案，在 SGM 基础上二次开发 SRE 业务级指标评估系统，该系统基于 SGM 产品的各类监控数据，有效监测各个应用的服务状态和业务指标，从数据运用上满足了公司管理层对技术可视化程度提升的要求。

5.典型问题：如何评估可用率、失败率？

如何评估应用的健康状态、业务成功率和系统可用率？某消金公司内部大部分应用都是通过请求的状态码来判断业务是否正常，粒度比较粗，无法精确识别方法级别，各个应用对业务健康识别方法理解也不一致，如何统一口径，屏蔽差异成为架构治理的一个重要课题。

解决方案：构建统一可信的可用率与失败率（成功率）监测体系，SGM 产品默认提供一套常规识别码规范用来标记被监控对象的健康度，同时也提供了业务自定义规则的入口。SGM 具备全局、应用级、方法级的三层识别码机制，通过对应用运行态的调用链进行实时监测，挖掘执行过程突发异常信息，形成系统实时可用率监测结果。基于统一的结果标记，屏蔽了具体方法返回码的差异性，利用方法级返回码的动态监控结果，联合可用率指标共同构建起方法级别、服务级别、应用级别、实例级别、机房级别等五个维度的应用成功率检测体系。消金公司技术团队可以通过成功率和可用率来客观评估应用的实时健康状态，通过返回码分类监控观测业务运行是否符合预期目标。在 SGM 产品中，除了失败率、可用率指标，同时附加性能指标波动变化的数据、日志和容量的数据，构建一个多维的、面向应用的综合健康度评价指标体系。

效果：在某消金公司的实践中，各个业务方对应用健康度的理解和对被监测的方法、返回码的定义标准化定义过程经历了从混乱、接纳治理到清晰有序的进化历程。深刻理解方法监控和返回码标识的精髓是 SGM 产品在消金公司落地广泛的良好支撑点。

6.典型问题：如何做好业务容量评估？

消金公司各个业务的调用量波动较大，业务间量能变化差异也较大，业务容量评估一直没有找到靠谱的抓手和数据支撑点。如何平衡资源利用率和保障服务可用率与用户体验的矛盾经常困扰着技术团队。

解决方案：SGM 应用实时容量评估功能和水位图是刻画应用资源和服务可用率最佳的手段，在采集应用监控日志的同时，SGM 后台也在运用特殊的计算方法评估应用的实时容量，容量评估从方法到服务再应用，层层累积，最终通过水位图实时反馈容量的变化。

效果：不仅架构团队关注应用容量变化，应用侧监控人员更是尤为关注。一方面需要关注应用运行的响应时间，保障用户体验；另外一方面又需要兼顾资源的使用率，控制成本。SGM 产品通过实时容量评估模块有力协助了消金公司团队做好这方面的工作，实现了保障用户体验和资源使用率的平衡，获得用户好评。

三、面向应用运维的问题解决

7.典型问题：如何做到有效告警？

需要告警的项目没有发出告警，或者告警中出现大量的重复信息，有效信息和重复信息混杂在一起，干扰了监控人员。

解决方案：基于 SGM 告警模块实现海量接口的主动监测和智能发布，应用的告警既要做到覆盖全面又需要精准无误，单独配置工作量较大。SGM 产品提供多种选择，基于基线告警是 SGM 告警模块的一个特色。在 SGM 中，面向应用提供全局告警、应用告警、方法告警三个维度，基于业务提供业务监控图表特有的告警能力，总体上兼顾不同群体的告警诉求。SGM 告警模块均具有根因分析的能力，对于持续波动的告警信息智能匹配关联关系，合并疑似根源，得出根源告警推送给应用相关人员。

效果：在消金公司的应用场景中，告警模块是高频使用的功能版块，很多日常生产故障和问题处理过程都是基于告警触发，通过 SGM 排查问题工具箱（调用查询、调用来源、调用链路、耗时详情、下钻调用链、上钻调用链、性能指标波动图表、关联 MDC 日志联动、提取自定义业务字段）快速定位问题，及时进行处置。

8.典型问题：如何将监控数据转化为业务语言？

监控早期阶段，某消金公司技术团队尝试基于开源 pinpoint 采集监控数据，由于受制于 pinpoint 本身的架构，缺少丰富的图表定制和可视化展示模块，也导致整个监控数据没有发挥应用的作用。源于业务的快速发展，整体面向 C 端的用户流量持续攀升，技术团队面临较大的压力，持续可用的服务保障需要全方位、多视角可观测数据的支撑和可视化的监控图表的展示。

解决方案：通过 SGM 内置的固定图表，包括调用量、性能 TP、AVG、MAX 指标监控图表、失败率、可用率、监控雷达图、应用大盘等模块，应用系统可以快速上手构建基础的监控态势感知环境，进一步根据应用自身产品的特点，定制出来了应用大屏监控、分类监控视图、流程监控、环路监控、比值监控、关键方法多维性能指标监控。

效果：用户深度使用产品的一个标志就是不断挖掘数据应用的场景，在某消金公司内部，不仅在运用告警模块处理应用各类异常场景和故障诊断，也在深入使用 SGM 生产的各类数据做可视化的数据展示，定制多种报表，而且技术团队还在通过 SGM OpenAPI 二次开发出多个隶属于 SRE 技术体系的监测与处置系统，深度利用 SGM 产品监控数据发挥出巨大的业务价值。受益于消金公司早期自建的一套基础监控体系和探索基于 Pinpoint 的二开模式的链路监控系统的历程，其团队对于服务链路监控体系有较深刻的理解，所以在推广 SGM 产品过程中，双方很多重合点被打开，再叠加 SGM 产品的优势功能，真正使业务增长受益。

作为一家纯互联网化技术背景的消费金融公司，技术栈广泛采用互联网敏态架构，本身数字化技术诉求也比较成熟，是诠释 SGM 分布式全链路追踪最佳实践的典型案例之一。SGM 是京东云分布式金融中台矩阵的重要产品，历经了内外部场景的双重磨炼，与开源和业界商业产品相比，沉淀着对金融场景的深刻理解，后续我们将进一步分享 SGM 链路追踪的实现原理和技术亮点，探索可观测性在更多云原生场景，如 servicemesh 等新技术领域的应用进展。