1 布景介绍
为了满意不断增加的事务需求，转转逐渐接入了大量的付出通道，而第三方体系的安稳性良莠不齐，通道毛病时有产生。当三方通道产生反常时咱们的感知比较后置，比方大量的体系告警，乃至需求等事务或用户反应才能感知到反常。作为接受全公司付出事务的中心体系，想要树立一个能给上游供给安稳服务的体系，仅依靠人工保护是远远不够的，因此树立一个完善的付出通道主动化办理体系就提上了日程。
2 规划方针
结合转转自身事务的特点，咱们整理了付出通道主动化办理体系要点需求处理的问题：
- 多通道、多主体的通道监控才能；
- 毛病快速发现，快速定位反常原因；
- 尽量做到无误报、无漏报；
- 通道毛病主动化切换的才能；
3 技能选型
依据以上布景，再来看下技能计划的选型：
3.1 熔断器
说到毛病的熔断和降级，首先想到的是市面上成熟的组件是否能够满意，比方 Hystrix，结合转转当时的事务场景来看，有以下几点无法满意诉求：
- 熔断器的降级熔断是依据接口的，无法满意通道和商户号维度的降级；
- 流量回切时或许三方反常仍未康复，无法自定义探测流量的规模，比方回切时指定用户或事务，容易形成二次事端；
3.2 时序数据库
熔断器无法满意方针后，咱们就将方针转向了自研，首先想做一个监控体系，底层一般都是选用时序数据库来存储，以下是热门时序数据库的排名：
结合转转现在的现状，咱们终究将规模锁定在了 Prometheus 和依据 Redis 自研：
准确性方面： 因为 Prometheus 在规划上就抛弃了一部分数据准确性，放奔一点准确性得到的是更高的可靠性，架构简略、数据简略、运维简略、节约机器本钱与人力本钱。
一般关于监控体系，数据具有少数的差错是能够接受的，而关于主动切换通道这种高灵敏场景并不适用：
- 比方在两次采样的间隔 （15s) 中有一个瞬时小尖峰，那么这次小尖峰是调查不到的
- 再比方 QPS、RT、P95、P99 这些值都是估算值，无法和日志、数据库一样做到 100% 准确
接入和学习本钱方面： Prometheus 关于事务研制来讲还是有一定的学习本钱的，也不便于后期的保护，而 Redis 关于 Java 后端开发者来说再了解不过了，无论是前期的学习本钱还是后期的保护本钱都比较低。
结合以上几个方面考量，终究决定依据 Redis 自研 “时序数据库” 来满意当时的诉求。
4 架构规划
收款和付款时会先经过各自的通道路由，筛选出可用的付出通道列表，获取到通道之后调用网关下单或打款，再由网关来向三方发起恳求，恳求完毕后将三方返回的成果经过 MQ 上签到通道监控体系。
监控体系在监听到音讯后，将监控的数据存储到 Redis，再由数据计算模块拉取 Redis 的数据进行筛选过滤后，汇总计算各通道的失利率，最后依据各通道装备的告警规矩触发通道反常告警。
Redis 中的数据会定期向 MySQL 备份，以便后续毛病剖析运用，一起会有离线任务守时清理 Redis 中的数据，防止 Redis 中存储的数据量过大。
一起为了更直观的调查各通道数据目标的变化，将搜集到的数据目标上签到了 Prometheus，经过 Grafana 数据看板来调查通道健康度。
通道主动上下线是比较灵敏的操作，严格依赖算法的准确性，所以体系上线初期，咱们只上线了手动上下线的才能，需求在搜集大量样本后，不断完善算法，进步监控的准确性和灵敏度，再逐渐切换至依据监控的通道主动化办理。
5 完成细节
5.1 数据结构
再来看下依据 Redis 的数据存储是怎么存储的，尽管没有运用时序数据库，但是在数据结构挑选上也是结合了时序数据库的存储思想来规划的，下面就以最热门的 InfluxDB 来对比看下：
| InfluxDB | Redis |
|---|---|
| tags 标签 | set 记载监控维度 |
| time 时刻戳 | zset 存储时刻戳（秒） |
| fields 数据 | hash 存储详细的值 |
- tags 标签：记载监控的维度，相对应的在 Redis 中选用的是 set 来存储，使用 set 去重的特性，刚好能够记载需求监控的目标。
- tims 时刻：记载产生的时刻，相对应的在 Redis 中选用的是 zset 来存储，在监控时需求依据时刻规模进行查找，且要求是依照时刻排序的，刚好能够使用 zset 的依照 score 来排序和查找的特性，用于记载监控点位的时刻戳，为了防止数据量过大，这里记载的单位是秒，也就一秒一个点位。
- fields 数据：存储详细的监控数据，相对应的在 Redis 中选用的是 hash 来存储，使用 hash 中存储 key、value 的特性，来记载恳求成果数据，记载一个点位内（1 秒）的成功与失利的情况，并记载失利的详细原因，key 用来存储恳求成果，value 用来记载对应成果 1 秒内产生的次数。
终究 Redis 中存储的结构样例如下：
1.set
存储已统计的维度，详细到商户号
key: routeAlarm:alarmitems
value: 微信-打款-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
.......
5.2 中心算法
为了防止两次监控间的小顶峰被忽略，保证不漏报，咱们的算法选用的是局部 计数法 加上整体 滑动窗口 的方法来完成的，每秒一个计数的点位，记载成功和失利的数量，监控时会计算整个窗口时刻规模内的成功失利数，终究得出每个通道的失利率，比方：窗口时刻是1分钟，监控频率 10秒/次。
那么监控频率是多少、时刻窗口规模怎么设定，这都会影响咱们终究监控的准确性。假如监控频率过小，就会导致咱们的取数样本太少，成果也没有参考含义。假如监控频率过大，两次窗口之间的小顶峰就或许存在漏报的情况，这些都是影响告警准确性的要素，这就需求经过对各个通道单据量级如：每天、每小时单量、下单频率等目标进行剖析而确定。
5.3 小流量的处理
小流量的通道和时刻段要怎么处理
- 从通道维度看，小流量的通道怎么处理
- 从时刻维度看，底峰时刻段怎么处理
比方转转接入的某一通道，每天总量只要几单，或许凌晨的单量就是很少，针对这种小流量的处理方法是，在监控时刻窗口内只要 1 单且失利，则会扩大时刻窗口，比方咱们正常时刻窗口是 1 分钟，那么扩大 1 倍后，时刻窗口则变更为 2 分钟，1-10 倍逐级增加，扩大到 10 倍之后假如还是高于预警阀值则会触发告警，此刻咱们以为这种也是需求重视的反常。
6 终究作用
1. 通道反常告警，快速定位问题
2. 兼并重复告警项
3. 通道反常康复
7 未来规划
现在的付出通道主动化办理体系还需求在以下几个方面进行优化和升级：
- 继续优化监控算法，提升告警准确率到99%以上；
- 与监控体系合作，完成通道毛病时主动下线的才能；
- 与监控体系合作，完成毛病康复探测及通道主动上线的才能；
关于作者：
张丹，转转付出结算技能部研制工程师，首要担任清结算方向的研制工作
转转研制中心及业界小伙伴们的技能学习交流平台，定期共享一线的实战经验及业界前沿的技能话题。 重视大众号「转转技能」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流共享~
