宝贝支付网络异常怎么解决 业务保障技术白皮书

支付宝云监控在双十二例行活动中担任非常重要的角色和平台，双十二的一些技术调试和交流，都会放在云监控上完成，包括压测，单品测试，应急预案的确认。

图11 2017年整个监控体系的架构

支付宝云监控的设计理念对我们做业务保障平台有很好的思路启发。

3 技术难点

所谓业务保障，就要依次回答这些问题：

·WHAT：第一时间感知到系统的故障或性能瓶颈，这个时间是分钟级；

·HOW：第一时间明确故障或瓶颈的范围，哪个机房，哪个业务，哪个集群，影响范围多大等等；

·WHY：最好能第一时间快速判定责任方和根本原因，这个时间必须很短，如1分钟以内；

·：不管能不能判定根本原因，都需要按事先拟定的预案快速恢复服务，这个时间必须很短，如1分钟以内，不允许恋战。

·：同时，大多数故障应该自愈，不需要人工介入，不应该总是需要人来干预。

这里多说一句，我们内部有一个核心业务高级别故障的处理口诀：

遇事不乱，分头核查，群里同步，简单陈述，绝不恋战，恢复服务。

其中“绝不恋战，恢复服务”就是指如果迟迟定位不了问题（比如三分钟之内），就不可恋战，必须快速恢复业务。第一，不要把生产环境当成测试环境，不要在线调试，第二，不要一直留着现场观察来观察去，保障业务的可用性，是最基本的。

3.1.海量数据秒级下钻

感知到故障相对比较容易，无非短信告警或钉钉告警。难点在于收到了一堆告警轰炸后，如何快速明确故障的影响范围、责任方和根因。

这就需要技术保障团队拥有很多种能力。

第一种能力是：海量数据，秒级展示和下钻，从宏观到微观，一路下钻。

只有这样，才有可能在业务最忙碌、负载最高峰的时候三下五除二定位问题，而不是每点击一下就得坐等 动画在那里转圈圈转个没完。一边是一个个追魂索命一样的电话，一边是转圈圈，那将是何等崩溃的场景。

何谓海量数据？假定一天一千万笔交易，判断系统是否出现异常，还需要与以下数据做对比：

这是要排除节假日、雨雪恶劣天气等意外影响。那么就要求我们保有至少最近一个月的所有数据做分析。加之一般都要做“端到端全链路”的跟踪和分析，第一个“端”指的是“终端”，比如手持 POS、双屏一体化收银设备、刷脸支付设备，而不仅仅局限于服务器端的链路分析，从而进一步放大了数据量，称之为百亿数据量规模，毫不夸张。

既然是百亿量级数据，如何做到秒级展示和下钻，是对技术保障团队的一个巨大挑战。

3.2.在线调试和远程操控

1997年7月，NASA 的 Mars (火星探路者)在降落火星表面后，当采集气象数据的时候，飞船所使用的 操作系统挂起（hung）并开始不断地重启。这被称为“火星上的第一个BUG”。

虽然飞船远在上亿公里的火星表面，但富有远见的工程师们仍能使用 shell 来变更飞船上的软件，当然为了解决本次“火星上第一个BUG”，他们利用了 自带的一个C语言解释器，它允许输入和执行 C 语言表达式来进行系统调试。工程师们决定开启这个特性，然后向飞船上传一小段 C 程序，在它解释并执行的时候就可以把优先级继承的互斥标志从 false 改为 true，从而解决了要命的 （优先级反转）问题。

我们必须能够远程追踪和调试物联网设备，捕获、识别并解决问题，这正是我们从火星探路者案例中学到的“常识”。

只有对实际系统行为（即使它在火星）能做端到端的详细追踪（现场调试和日志下载），才能捕获、识别并解决错误。一个不能追踪的黑盒子（即使它在你所在的城市），跟肉包子打狗没有区别。所以你的宝贝设备自带远程调试，甚至是远程镜像工具，是非常重要的，这应该是技术保障团队拥有的第二种能力。

如果不能即时修改系统，则万事皆休，尤其是在新冠疫情期间，你还能随随便便去一个城市、进入一栋保卫森严的办公楼吗？本文不再赘述，有兴趣的话可以阅读我们的《IoT平台技术白皮书》。

3.3.端到端全链路追踪

全链路追踪，是一个历史源远流长的技术课题。

图12 UI

从谷歌2010年发表的 论文开始，涌现了一大批分布式跟踪选手，如淘宝鹰眼、点评CAT、京东Hydra、eBay CAL、 、窝窝等等，老课题，不再赘述。既然做的是业务保障，既然现在是万物互联时代，那么智能设备就要纳入全链路追踪的范畴内。这是技术保障团队应该拥有的第三种能力。

通过追踪调用链，首先我们可以很方便地、一目了然地理清各个微服务之间的调用层级关系，其次调用链还可以帮助我们做到：

3.4.诊断系统性能瓶颈

链路追踪还有一个用途就是提前发现并消灭系统隐患。系统性能瓶颈和人的身体是一样的，如果不提前发现并治理，病情只会越来越严重，最终突然有一天所有服务雪崩，留下一脸懵逼的你。你以为是工程A有瓶颈，其实是ABCDE…一堆工程都有这样那样的瓶颈，当又一根稻草压上来的时候，系统就整体塌方了。

栈内耗时分析就是相当于时时刻刻在给系统做体检，技术保障团队应该定期或不定期地利用它探查系统的内部耗时并督促业务技术团队做优化，否则小洞不补，大洞受苦。

大致原理是通过服务调用之间的栈内耗时监控，比如方法M1调用方法M2，栈内耗时t=t1-t2，如果t大于一定时长，比如50毫秒，就会被探测到并记下来。

这样我们可以为每一个业务设计一个耗时选项卡，展示特定时段的耗时分布，还可以按调用耗时倒排序，找到那些内部耗时严重的请求，穿刺进去看到调用链瀑布图，这里面就能提供IP、容器、操作方法名、参数等重要信息。再结合探针日志就可以入微到代码栈级别的问题了。这是技术保障团队应该拥有的第四种能力。

3.5.诊断网络质量

显而易见，服务端的链路追踪相对比较容易，有现成的理论指导，有现成的开源工具。但是把智能设备的链路纳入进来，连带它的 DNS 解析时间、TCP/IP 传输时间、SSL 时间、服务器响应耗时、首包响应耗时等链路信息一并上报，能够清晰地与服务端链路对上，串联起来，可视化分析，又难了一层。这是技术保障团队应该拥有的第五种能力。

有了这个能力之后，当客户投诉POS机具“越用越慢”、“突然卡住了”、“时快时慢”、“付完款总是转圈”的时候，你就可以不费吹灰之力地定位是“DNS解析慢”等网络质量问题了，而不是跑到服务端到处嗅来嗅去，把日志翻了一个遍。

一言以蔽之，面向大规模物联网智能设备的端到端全链路追踪、在线调试、性能瓶颈分析、异常根因分析和网络质量诊断，是对技术保障团队的一个又一个巨大的挑战。

3.6.绝不恋战恢复服务

快速恢复服务就意味着我们一定有后备方案，比如另一根专线，另一个通道，另一个集群，另一个数据库，另一个机房。我在《异地多活技术白皮书》里阐述过：“当业务爆发到一定的规模之后，公司就需要大力重视风险控制，绝不允许出现单节点故障隐患。并不是说只有单个 Nginx 节点，单个应用节点，单个数据库节点才叫单节点风险。单机房也属于单节点风险。即使像阿里云这样的公有云也不能独善其身。”所以到了一定的业务量，就需要多 IDC 甚至是多公有云的单元格部署方式，也就是异地多活。

图13 一个三地五机房的部署方式

不言而喻，异地多活都是各个一线公司、各个技术团队根据自己的业务情况摸着石头过河，没有开源工具辅助，没有完善的理论支撑，异地双活的技术难度还则罢了，像支付宝的“三地五中心异地多活”就愈发不可想象了。本文不再赘述，有兴趣的请阅读我们的《异地多活技术白皮书》。这也是技术保障团队最好能拥有的技能，它能让你安心入睡，放心吃饭。

3.7.系统自愈

监控能力对于业务保障平台来说，最大的价值是能够完成事件的触发，从而实现从数据发现、分析、定位、再到问题解决的闭环。通过这个闭环，我们其实可以构建各种故障的自愈能力。通过及时发现异常，快速恢复，能够有效提升业务的可用性。

举个实例的例子，当系统发现一个节点的 CPU 有异常的时候，需要对 CPU 高负载进行故障干预和恢复，这种情况下应该怎么做呢？

第一步，我们可以取到告警的信息，告警里会告诉我这个节点的信息；

第二步，通过节点信息，可以从 CMDB 中查出来这个节点属于哪个业务的哪个服务，更进一步可以查询到同服务下还有哪些节点；

第三步，把其他节点的当前 CPU 值都查询出来，得出的平均值再来和告警的 CPU 值来对比；

最后判断出是否需要系统干预。如果需要修复，系统会根据节点信息到 CMDB 中获取相应的恢复策略，再进行处理。

通过这种灵活和完整的验证处理闭环，就可以设计出大多数场景下的可靠的故障自愈策略。

如前所述，我们讲解了高并发、高频交易、万物互联场景下的业务保障所需面对的技术难点，技术管理者对此要有心理预期，它并不像你想象的堆几个 、、集群那样简单，当然也不是太难。技术管理者要秉持两个心态：

第一，平凡人可为非凡事，活儿都是人干出来的，只要下定决心，秒级展示和下钻就能做到，RTO（容许服务中断后恢复的时间长度）就能做到1分钟，SLA四个九也不是问题。

第二，一定要预先投入，未雨绸缪，先做好各种工具、预案和后备方案，不要等到灾难来临才百爪挠心。举个例子，你不能指望平常都没做过异地多活切机房演练，真的单机房挂掉的时候所有人能步调一致、有条不紊地切换流量，想想阿里巴巴为什么要搞断网断电演练和生产突袭，你又该做些什么。

4 业界综述

讲过了支付宝的业务保障示范，以及高频海量交易场景下的业务保障技术难点，在和盘托出我们如何一一解决之前，先来看看别人家是怎么做业务系统的技术保障。

4.1.美团外卖的业务大盘和服务保护

美团外卖业务会对非常多的业务指标进行监控，业务指标和系统指标、服务指标不同，需要业务方根据不同的业务自行上报监控数据。

略……

4.2.唯品会的全链路应用监控系统

电商大促开始的几分钟，大家会非常熟悉一个场景：为了抢货，用户会不断刷新网页。对大体量的电商公司来说，一瞬间涌进来的流量是每秒百万级别的，各系统也肩负着承担高并发流量的压力。在这种情况下，设计良好的监控系统就好比唯品会的眼睛，火眼金睛地发现系统的故障，并第一时间定位故障根源，保证系统正常运转。

略……

4.3.京东云的监控体系

监控目标就是降低损失，通过发现、定位、解决问题，期望缩短异常出现的 MTTR（平均修复时间）。

要达到这个目标，监控对象必须具备可观测性，即通过数据描述是否出现异常，这些数据包括指标监控 、日志 log 和Trace 数据。

为了实现缩短 MTTR 的目标，监控系统应该具有这些能力：

1）数据采集能力，获取可观测的数据；

2）数据能够方便加工，比如把相关的数据汇聚起来，得到运维人员关注的数据；

3）对这些关注的数据，做异常检测，及时产生告警；

4）收到告警后，通过 查图定位，最好有专家推荐，加速定位；

5）定位问题后，通过预案平台进行快速止损；

6）整个监控系统需要做到高可用，监控就是为了发现异常，如果由于异常导致自身不可用，肯定是减分的。

略……

4.4.AIOps在携程的探索与实践

2018年被业内称为 AIOps 的元年，从行业分享的最佳实践内容看，AIOps 主要围绕质量、效率和成本这三个方面展开，实践包括异常检测到诊断自愈，以及容量到成本的优化。

略……

4.5.腾讯的海量监控和保障体系

腾讯又做了哪些不一样的“新”事情呢？说到创新，腾讯内部有这么多的监控系统（将近 20 套监控系统，指标有将近 300 多个，监控的实例超过 900 万，最可怕的是每天有近 5 万条短信告警，人均 500 条），存在必有它的合理性，腾讯去建设新的创新并不是要否定过去监控系统的存在，主要还是希望通过解决历史中一些不合理的架构演进，用一些创新的方法，让腾讯的监控能够朝真正的快、准、全这个方向去发展，而不是局部优化或者推翻重做。所以下面的一些创新的方法，可能大家会发现运用的技术并不是特别牛逼，可能不是特别了不起的算法，但确实有效。

略……

5 我们的实现5.1.业务特性

看完好学生的功课后，看看我们自己怎么落地生根的。

从收单业务一开始起步，我便提出应该建设这样一个业务保障系统，它能够做到：

预见性：

在客户的投诉一层一层传递过来之前，就能提前发现业务的问题或即将出现问题。

切片性：

不能只是满足于观测宏观的交易笔数实时趋势，我们需要穿刺到多维度：

业务维度

支付通道维度

终端网络接入维度

渠道维度

设备型号维度

……

一站式：

不需要东奔西走，游走于各个系统界面之间，所有商户、门店、进件、机具、订单、交易、用户等等的当下和历史的信息，就在此处，一站式展示和下钻完毕。解决问题的时候，时间非常宝贵，争分夺秒，来不及四处拼凑碎片。

宏观上发现征兆之后，我们还要能立即穿刺进入微观领域，签约、进件、设备、渠道、支付通道、支付费率以及历史变化等等，所有详情都合理地一站式展示。

这已经超出了链路追踪系统或运维监控系统的范畴，是的，我们不仅仅关心全链路追踪，不仅仅关心云平台运维，我们更关心最终的业务保障效果。

简单总结一下我们希望的系统特性：

·多场景多维度实时监控大盘

·可视化数据

·业务健康度分析

·问题自动分析和定位

·按照预案设定自动恢复

·……

仅仅有业务大盘监控、部分自愈是不够的，因为我们每天可能被成千上万的报警信息淹没。我们需要削减报警数量级，并快速判定故障根因，这就是 AIOps 的根因分析。

首先，根据网络拓扑（SLB，NGINX，API网关，调用链……）绘制故障传播图（基于图数据库），确保随着应用节点的扩容缩容、新应用上下线，故障传播图能自动更新。有了这个靠谱的传播图，才有机会顺藤摸瓜，沿着路径寻找可疑的征兆。

其次，要把日常报警信息集中起来，一个一个跟不同业务线的故障传播图上的节点对上。

说白了是一个专家系统，大多数基础数据预先准备好，所谓智能指的是按预先制定的规则遍历树状结构上的报警信息，然后根据历史数据和算法，判定根因的概率。

最后要把 AIOps 的报警结果准确地推送给具体业务线的技术负责人，这样就能产生这样的效果：原本他每天1千+条报警，缩减为100+条，甚至10+条。这样，我们才有机会回答那终极三个问题：

出了什么事儿？

什么原因？

什么时候恢复？或者：“已经好了。”

5.2.秒级下钻的底层支持

一开始，团餐业务保障平台的底层数据是基于的，如下图所示。

图36 基于版的早期架构

早期架构的数据链路如下所示：

采用的技术栈如下所示：

运行了一段时间之后，的性能就有点跟不上了。查询数据量在百万级的时候，速度还是可以的，所以在寒暑假交易低谷期并未暴露出的性能问题。但是一进入9月开学季，数据延时和查询缓慢的问题立马就凸显了，中途也曾寄希望于升级版本，但依然效果不佳。

此时我司其他技术团队已经试用了Druid， 其核心是通过数据预先聚合提高查询性能，针对预先定义好的，因此适合实时分析的场景，结果返回时间在亚秒级。

在我们也将底层数据切换到Druid之后，响应速度上确实有一个数量级的提升，明显提升了从宏观下钻到微观的响应时间，基本能做到百亿级数据量秒级响应。高峰时段Kafka消息堆积也大幅降低。下钻方式也做了优化，更符合工程师探查习惯。

5.3.秒级下钻的调用链优化

如前所述，用来做全链路追踪的调用链数据流为：“-”-> Kafka ->“-”消费->入库ES。下面讲一下这块工作的优化历程。

第一阶段：Kafka消息堆积高峰期由千万级降到百万级

强调一点，合理的分区设置很重要。

刚开始我们尝试调整每次拉取的消息条数，将.由1000调整为6000，消息堆积似乎好了一点，但效果不明显。

考虑到可能是因为并发数不够，所以通过扩充Kafka的分区数去提高并发。先将分区数由5个扩到8个，消息堆积由千万级降到百万级。但继续将分区扩到10个，就几乎没有什么效果了。

第二阶段：Kafka的版本选择不可忽视

更令人莫名其妙的是-的消费非常不稳定，频繁与kafka断开重连，尝试去消费其他分区消息，导致消费速率上不去。

后来发现，当Kafka版本为v2.3时，多个-节点会反复触发kafka的消费再平衡机制，结果导致-只能单点消费。

所以我们又将Kafka版本回退到了v2.2，调整-实例个数和Kafka分区数为1:1，可横向扩容支持高并发。

第三阶段：消息堆积高峰期由百万降到万级，延时秒级已可接受

我们观察到ES的负载已经很高了，单节点高峰期CPU负载达到16。之前为了方便定位问题，给网络请求实时加上了标记，调用的是原生的trace链路计算。现在分析发现查询QPS太高，所以尝试优化查询逻辑，一方面改为自定义的逻辑直接查询ES，一方面调整好批量阈值查询（指的是1次查多少，目前是按时间10ms和数据条数100条一个批次去查ES）。

优化完成后，消息堆积又下降一个数量级，高峰期堆积非常少，已做到秒级消费。

5.4.秒级下钻的聚合查询优化

散点图 vs 柱状图

对于调用链宏观展示来说，惯常使用散点图，它可以表达出一段时间内请求的耗时分布情况，如下图所示。

图37 调用链散点图

但是存在一个问题，当时间区间选得比较大的时候，服务端查询的数据过多而响应变慢，客户端要渲染的点太多也会非常卡。所以点要抽样。抽样方式能想得到的有：

a.过滤出耗时长的数据；

b.取最近一段时间的数据；

c.只取指定数量的数据；

d.对相同耗时进行聚合展示等等。

这些调整可谓牺牲了监控者的真实需求，因为有些数据监控者看不了，或者很难看全。

我们对比了阿里云日志服务的设计，他山之石可以攻玉，借鉴了以下两点：

第一点，人们看问题的方式总是从宏观一路下钻到微观，所以我们加了柱状图做为时间段聚合，方便从宏观上看到请求量的规模分布。下图是某区域的订单趋势柱状图。

图38 订单趋势柱状图

第二点，如果数据量非常大，可继续点击柱图，展开当前时间条件下的子柱状图。系统根据数据量规模，自动展示出散点图，方便用户浏览耗时分布。这样一层层穿刺下钻，既满足了人的操作习惯，又提高了处理速度，做到了秒级响应。

图39柱状图下钻

5.5 从宏观到微观的下钻

如上所说，我们做到了从宏观到微观的监控下钻，下面讲三个案例增加大家的感性认知。

案例一，单一维度下钻

其实多数时候人们只想关注某一维度的分布情况，比如按应用、按工程、按机房、按请求URI、按商户、按门店、按设备等看分布。对于ES来说，单一条件聚合速度很快，完全可以做到秒级响应。

案例二，网络质量监察

我司的客户分布在大江南北，如何快速定位出哪些食堂网络环境糟糕呢？不能等客户告诉我们。

我们可以从请求量级筛选（系统推荐和自定义）、dns/http/ssl/tcp/mqtt耗时情况、趋势发展等诸多因子中分析出餐饮中心网络情况，哪怕是学校食堂的一次网络抖动，都可以被我们侦测到。不仅能分析出网络问题，而且还能下钻到请求链路上的任何阶段，比如是DNS、TCP、SSL、首包响应时长等，并分析出受影响的终端设备。依然是秒级响应，如下图所示。

图40 设备耗时下钻

案例三，找出掉单

当用户已支付而商户未收款时，如何从千万级订单中快速找到丢失的那一笔订单呢？内部称之为sos订单。

秒级侦测出来；

快速定位在哪个环节出了问题；

系统具备自我修复能力。

具体做法为：

第一步，将内部可能发生的业务场景圈出来，通过Flink实时计算形成闭环，当其中一个链条断了，就会立马把待排查的sos订单压入队列任务，然后不断主动查询第三方支付渠道确认支付状态。

第二步，对于一些疑难问题如短时间内系统无法解决时，比如第三方支付渠道出现了故障，就会发出告警消息给客服，客服预先跟进，减少用户投诉处理时间。

第三步，系统对sos订单也有纠错能力，比如在某些特定条件下做自动原路退返，从而减少客诉。

5.6 告警的聚类

如果想对线上异常做到先知先觉，那么就需要在发生问题的时候实时告警，同时由上而下、由内而外地输出问题原因及对策。每一次告警都应能够一竿子插到底，从Web端，到各个中心，到数据库，到Redis，每一个环节展示得清清楚楚，打眼一看便知哪个环节出了问题。所以我们还对一段时间内的报警做了聚类汇总，将同一原因引起的报警进行聚合，最终形成几条报警摘要，使得大家对一段时间的问题有一个统筹认知。这不算是AIOps，但也是个方向。

本质上还是对全链路追踪的运用。通过对全链路数据的修剪，我们可以提炼出每一次请求异常的根因。我们只需要对每次请求的RCA（即Root Cause ）进行聚类分析即可得到最终的异常报警聚合报告。

图41 告警聚类

实际聚类告警效果如下图所示，通过钉钉或短信触达。

异常聚类报告如下图所示，有邮件触达，有专门的控制台展示。

总结一下，首先所有工程引入基于标准的全链路追踪，其次对全链路采集的日志数据引入Flink做实时计算分析，再次针对链路日志的分析结果做实时告警、提取故障报告及生成系统诊断的异常聚类报告。

6 总结

不见棺材不掉泪，不撞南墙不回头？不要非等到业务高峰期撞上了大型灾难事件，才开始认真反思和建设业务保障体系。业务保障平台能为我们各条业务线的平稳运行保驾护航，早一天建立，早一天轻松。

注：本文源自《禧云业务保障技术白皮书》，为禧云信息内部编著的技术交流资料。