作者介绍

为了满足不断增长的业务需求，转转逐步接入了大量的支付通道，而第三方系统的稳定性参差不齐，通道故障时有发生。当三方通道发生异常时我们的感知比较后置，比如大量的系统告警，甚至需要等业务或用户反馈才能感知到异常。作为承接全公司支付业务的核心系统，想要建立一个能给上游提供稳定服务的系统，仅依靠人工维护是远远不够的，因此建立一个完善的支付通道自动化管理系统就提上了日程。

结合转转自身业务的特点，我们整理了支付通道自动化管理系统重点需要解决的问题：

基于以上背景，再来看下技术方案的选型：

提到故障的熔断和降级，首先想到的是市面上成熟的组件是否能够满足，比如 Hystrix，结合转转当前的业务场景来看，有以下几点无法满足诉求：

熔断器无法满足目标后，我们就将目标转向了自研，首先想做一个监控系统，底层一般都是选用时序数据库来存储，以下是热门时序数据库的排名：

时序数据库排名

结合转转目前的现状，我们最终将范围锁定在了 Prometheus 和基于 Redis 自研：

准确性方面： 由于 Prometheus 在设计上就放弃了一部分数据准确性，放弃一点准确性得到的是更高的可靠性，架构简单、数据简单、运维简单、节约机器成本与人力成本。

通常对于监控系统，数据拥有少量的误差是可以接受的，而对于自动切换通道这种高敏感场景并不适用：

Prometheus 不适合的场景

接入和学习成本方面：Prometheus 对于业务研发来讲还是有一定的学习成本的，也不便于后期的维护，而 Redis 对于 Java 后端开发者来说再熟悉不过了，无论是前期的学习成本还是后期的维护成本都比较低。

结合以上几个方面考量，最终决定基于 Redis 自研 “时序数据库” 来满足当前的诉求。

架构设计

收款和付款时会先通过各自的通道路由，筛选出可用的支付通道列表，获取到通道之后调用网关下单或打款，再由网关来向三方发起请求，请求结束后将三方返回的结果通过 MQ 上报到通道监控系统。

监控系统在监听到消息后，将监控的数据存储到 Redis，再由数据计算模块拉取 Redis 的数据进行筛选过滤后，汇总计算各通道的失败率，最后根据各通道配置的告警规则触发通道异常告警。

Redis 中的数据会定期向 MySQL 备份，以便后续故障分析使用，同时会有离线任务定时清理 Redis 中的数据，避免 Redis 中存储的数据量过大。

同时为了更直观的观察各通道数据指标的变化，将收集到的数据指标上报到了 Prometheus，通过 Grafana 数据看板来观察通道健康度。

通道指标看板

通道自动上下线是比较敏感的操作，严格依赖算法的准确性，所以系统上线初期，我们只上线了手动上下线的能力，需要在收集大量样本后，不断完善算法，提高监控的准确性和灵敏度，再逐步切换至基于监控的通道自动化管理。

再来看下基于 Redis 的数据存储是如何存储的，虽然没有使用时序数据库，但是在数据结构选择上也是结合了时序数据库的存储思想来设计的，下面就以最热门的  InfluxDB 来对比看下：

最终 Redis 中存储的结构样例如下：

1.set存储已统计的维度，具体到商户号key: routeAlarm:alarmitemsvalue: 微信-打款-100000111       微信-打款-100000112       微信-打款-100000113       .......

2.zset存储指定商户号请求的时间戳（秒），同一秒的数据会覆盖存储key: routeAlarm:alarmitem:timeStore:微信-打款-100000111      score: 1657164225 value: 1657164225      score: 1657164226 value: 1657164226      score: 1657164227 value: 1657164227      .......

3.hash存储指定商户号1秒内的请求结果, 每秒汇总一份结果key: routeAlarm:alarmitem:fieldStore:微信-打款-100000111:1657164225      key: success             value: 10 (次数)      key: fail                value: 5      key: balance_not_enough  value: 3      key: thrid_error         value: 2      .......   

为了避免两次监控间的小高峰被忽略，确保不漏报，我们的算法采用的是局部 计数法 加上整体 滑动窗口 的方式来实现的，每秒一个计数的点位，记录成功和失败的数量，监控时会计算整个窗口时间范围内的成功失败数，最终得出每个通道的失败率，比如：窗口时间是1分钟，监控频率 10秒/次。

核心算法

那么监控频率是多少、时间窗口范围如何设定，这都会影响我们最终监控的准确性。如果监控频率过小，就会导致我们的取数样本太少，结果也没有参考意义。如果监控频率过大，两次窗口之间的小高峰就可能存在漏报的情况，这些都是影响告警准确性的因素，这就需要通过对各个通道单据量级如：每天、每小时单量、下单频率等指标进行分析而确定。

小流量的通道和时间段要如何处理：

比如转转接入的某一通道，每天总量只有几单，或者凌晨的单量就是很少，针对这种小流量的处理方式是，在监控时间窗口内只有 1 单且失败，则会扩大时间窗口，比如我们正常时间窗口是 1 分钟，那么扩大 1 倍后，时间窗口则变更为 2 分钟，1-10 倍逐级增加，扩大到 10 倍之后如果还是高于预警阀值则会触发告警，此时我们认为这种也是需要关注的异常。

通道异常告警

合并重复告警项

通道异常恢复

目前的支付通道自动化管理系统还需要在以下几个方面进行优化和升级：