五个9的可用度、秒级故障解决，探寻互联网金融应用之道(2)

付钱拉提供各种各样的支付接口给商户,常用的就有快捷,个人网银,企业网银,退款,撤销,批量代付,批量代扣,单笔代付,单笔代扣,语音支付,余额查询,身份证鉴权,银行卡鉴权,卡密鉴权等.与其对应的支付通道有微信支付,ApplePay,支付宝等30多家支付通道,并且接入了几百家商户.在这三个维度下,如何确保不同业务、三方、商户、以及支付类型互不影响,付钱拉所做的就是拆分消息队列.下图是部分业务消息队列拆分图：

限制资源的使用

对于资源使用的限制设计是高可用系统最重要的一点,也是容易被忽略的一点,资源相对有限,用的过多了,自然会导致应用宕机.为此付钱拉做了以下功课：

(1) 限制连接数

随着分布式的横向扩展,需要考虑数据库连接数,而不是无休止的最大化.数据库的连接数是有限制的,需要全局考量所有的模块,特别是横向扩展带来的增加.

(2) 限制内存的使用

内存使用过大,会导致频繁的GC和OOM,内存的使用主要来自以下两个方面：

A. 集合容量过大；

B. 未释放已经不再引用的对象,比如放入ThreadLocal的对象一直会等到线程退出的时候回收.

(3) 限制线程创建?

线程的无限制创建,最终导致其不可控,特别是隐藏在代码中的创建线程方法.

当系统的SY值过高时,表示linux需要花费更多的时间进行线程切换.Java造成这种现象的主要原因是创建的线程比较多,且这些线程都处于不断的阻塞(锁等待,IO等待)和执行状态的变化过程中,这就产生了大量的上下文切换.

除此之外,Java应用在创建线程时会操作JVM堆外的物理内存,太多的线程也会使用过多的物理内存.

对于线程的创建,最好通过线程池来实现,避免线程过多产生上下文切换.

(4) 限制并发

做过支付系统的应该清楚,部分三方支付公司是对商户的并发有要求的.三方给开放几个并发是根据实际交易量来评估的,所以如果不控制并发,所有的交易都发给三方,那么三方只会回复“请降低提交频率”.

所以在系统设计阶段和代码review阶段都需要特别注意,将并发限制在三方允许的范围内.

我们讲到付钱拉为了实现系统的可用性做了三点改变,其一是尽可能避免故障,接下来讲后面两点.

故障就像鬼子进村,来的猝不及防.当预防的防线被冲破,如何及时拉起第二道防线,发现故障保证可用性,这时候报警监控系统的开始发挥作用了.一辆没有仪表盘的汽车,是无法知道车速和油量,转向灯是否亮,就算“老司机”水平再高也是相当危险的.同样,系统也是需要监控的,最好是出现危险的时候提前报警,这样可以在故障真正引发风险前解决.

一、实时报警系统

如果没有实时报警,系统运行状态的不确定性会造成无法量化的灾难.付钱拉的监控系统指标如下：

• 实时性 – 实现秒级监控；
• 全面性 – 覆盖所有系统业务,确保无死角覆盖；
• 实用性 – 预警分为多个级别,监控人员可以方便实用地根据预警严重程度做出精确的决策；
• 多样性 – 预警方式提供推拉模式,包括短信,邮件,可视化界面,方便监控人员及时发现问题.

报警主要分为单机报警和集群报警,而付钱拉属于集群部署.实时预警主要依靠各个业务系统实时埋点数据统计分析实现,因此难度主要在数据埋点和分析系统上.

二、埋点数据

要做到实时分析,又不影响交易系统的响应时间,付钱拉在系统各个模块中通过Redis实时做数据埋点,然后将埋点数据汇总到分析系统,分析系统根据规则进行分析报警.

三、分析系统

分析系统最难做的是业务报警点,例如哪些报警只要一出来就必须出警,哪些报警一出来只需要关注.下面我们对分析系统做一个详细介绍：

系统运行架构

系统运行流程

系统业务监控点

付钱拉的业务监控点都是在日常运行过程中一点一滴总结出来的,分为出警类和关注类两大块.

(1) 出警类：

网络异常预警；

单笔订单超时未完成预警；

实时交易成功率预警；

异常状态预警；

未回盘预警；

失败通知预警；

异常失败预警；

响应码频发预警；

核对不一致预警；

特殊状态预警；

(2) 关注类：

交易量异常预警；

交易额超过500W预警；

短信回填超时预警；

非法IP预警；

非业务监控点

非业务监控点主要是指从运维角度的监控,包括网络,主机,存储,日志等.具体如下：

(1) 服务可用性监控：

使用JVM采集Young GC/Full GC次数及时间、堆内存、耗时Top 10线程堆栈等信息,包括缓存buffer的长度.

(2) 流量监控：

通过Agent监控代理部署在各个服务器上,实时采集流量情况.

(3) 外部系统监控：

通过间隙性探测来观察三方或者网络是否稳定.

(4) 中间件监控：

针对MQ消费队列,通过RabbitMQ脚本探测,实时分析队列深度；

针对数据库部分,通过安装插件xdb,实时监控数据库性能；

(5) 实时日志监控：

通过rsyslog完成分布式日志的归集,然后通过系统分析处理,完成日志实时监控和分析.最后,通过开发可视化页面展示给使用者.

(6) 系统资源监控：

通过Zabbix监控主机的CPU负载、内存使用率、各网卡的上下行流量、各磁盘读写速率、各磁盘读写次数(IOPS)、各磁盘空间使用率等.

以上就是付钱拉实时监控系统所做的,主要分为业务点监控和运维监控两方面,虽然系统是分布式部署,但是每个预警点都是秒级响应.除此之外,业务系统的报警点也有一个难点,那就是有些报警是少量报出来不一定有问题,大量报警就会有问题,也就是所谓的量变引起质变.

举一个例子,拿网络异常来说,发生一笔可能是网络抖动,但是多笔发生就需要重视网络是否真的有问题,针对网络异常付钱拉的报警样例如下：

单通道网络异常预警：1分钟内A通道网络异常连续发生了12笔,触发了预警阀值；

多通道网络异常预警1: 10分钟内,连续每分钟内网络异常发生了3笔,涉及3个通道,触发了预警阀值；

多通道网络异常预警2： 10分钟内,总共发生网络异常25笔,触发了预警阀值；

四、日志记录和分析系统

对于一个大型系统而言,每天记录大量的日志和分析日志是有一定的难度的.付钱拉每天平均有200W笔订单量,一笔交易经过十几个模块流转,假设一笔订单记录30条日志,可想而知每天会有多么巨大的日志量.

付钱拉日志的分析有两个作用,一个是实时日志异常预警,另外一个是提供订单轨迹给运营人员使用.

五、实时日志预警

（编辑：ASP站长网）