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

发布时间：2021-01-07 06:05 所属栏目：53 来源：网络整理

导读：实时日志预警是针对所有实时交易日志,实时抓取带有Exception或者Error的关键字然后报警.这样的好处是,如果代码中有任何运行异常,都会第一时间发现.付钱拉针对实时日志预警的处理方式是,首先采用rsyslog完成日志归集

实时日志预警是针对所有实时交易日志,实时抓取带有Exception或者Error的关键字然后报警.这样的好处是,如果代码中有任何运行异常,都会第一时间发现.付钱拉针对实时日志预警的处理方式是,首先采用rsyslog完成日志归集,然后通过分析系统实时抓取,再做实时预警.

六、订单轨迹

对于交易系统,非常有必要实时了解一笔订单的状态流转.付钱拉最初的做法是通过数据库来记录订单轨迹,但是运行一段时间后,发现订单量剧增导致数据库表过大不利于维护.

付钱拉现在的做法是,每个模块通过打印日志轨迹,日志轨迹打印的格式按照数据库表结构的方式打印,打印好所有日志后,rsyslog来完成日志归集,分析系统会实时抓取打印的规范日志,进行解析然后按天存放到数据库中,并展示给运营人员可视化界面.

日志打印规范如下：

2016-07-2218:15:00.512||pool-73-thread-4||通道适配器||通道适配器-发三方后||CEX16XXXXXXX5751||16201XXXX337||||||04||9000||【结算平台消息】处理中||0000105||98XX543210||GHT||03||11||2016-07-22 18:15:00.512||张张||||01||tunnelQuery||true||||Pending||||10.100.140.101||8cff785d-0d01-4ed4-b771-cb0b1faa7f95||10.999.140.101||O001||||0.01||||||||http://10.100.444.59:8080/regression/notice||||240||2016-07-20 19:06:13.000xxxxxxx

||2016-07-2218:15:00.170||2016-07-22 18:15:00.496xxxxxxxxxxxxxxxxxxxx

||2016-07-2019:06:13.000||||||||01||0103||111xxxxxxxxxxxxxxxxxxxxxxxxx

||8fb64154bbea060afec5cd2bb0c36a752be734f3e9424ba7xxxxxxxxxxxxxxxxxxxx

||622xxxxxxxxxxxxxxxx||9bc195a59dd35a47||f2ba5254f9e22914824881c242d211

||||||||||||||||||||6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx010||||||||||

简要日志可视化轨迹如下：

日志记录和分析系统除了以上两点,也提供了交易和响应报文的下载和查看.

七、7*24小时监控室

付钱拉以上的报警项目给操作人员提供推拉两种方式,一种是短信和邮件推送,一种是报表展示.除此之外,由于支付系统相比互联网其他系统本身的重要性,付钱拉采用7*24小时的监控室保证系统的安全稳定.

及时处理故障

在故障发生之后,特别是生产环境,第一时间要做的不是寻找故障发生的原因,而是以最快速度处理故障,保障系统的可用性.付钱拉常见的故障和处理措施如下：

一、自动修复

针对自动修复部分,付钱拉常见的故障都是三方不稳定造成的,针对这种情况,就是上面说的系统会自动进行重路由.

二、服务降级

服务降级指在出现故障的情况下又无法快速修复的情况下,把某些功能关闭,以保证核心功能的使用.付钱拉针对商户促销的时候,如果某个商户交易量过大,会实时的调整这个商户的流量,使此商户服务降级,从而不会影响到其他商户,类似这样的场景还有很多,具体的服务降级功能会在后续系列介绍.

本文主要的关注点是如何提供应用的可用性,以付钱拉最佳实践为背景来讲述的,后续会继续讨论付钱拉支付架构其他系列.

Q&A

Q1: 谢谢冯老师,能讲讲当年那台RabbitMQ宕掉的具体细节和处理方案吗?

A1: RabbitMQ宕机时间引发了对系统可用性的思考,当时我们的RabbitMQ本身并没有宕机(RabbitMQ还是很稳定的),宕机的是RabbitMQ所在的硬件机器,但是问题就出在当时RabbiMQ的部署是单点部署,并且大家惯性思维认为RabbitMQ不会宕机,从而忽略了它所在的容器,所以这个问题的产生对于我们的思考就是所有的业务不可以有单点,包括应用服务器、中间件、网络设备等.单点不仅仅需要从单点本身考虑,比如整个服务做双份,然后AB测试,当然也有双机房的.

Q2: 贵公司的开发运维是在一起的吗?

A2: 我们开发运维是分开的,今天的分享主要是站在整个系统可用性层面来考虑的,开发偏多,有一部分运维的东西.这些付钱拉的走过的路,是我一路见证过的.

Q3: 你们的后台全部使用的Java吗?有没有考虑其他语言?

A3: 我们目前系统多数是java,有少数的python、php、C++,这个取决于业务类型,目前java这个阶段最适合我们,可能随着业务的扩展,会考虑其他语言.

Q4: 对第三方依赖保持怀疑,能否举个具体的例子说明下怎么样做?万一第三方完全不了用了怎么办?

A4: 系统一般都有第三方依赖,导致宕机.大家都知道系统一旦发生问题都是滚雪球的,越来越大.比如说我们扫码通道,如果只有一家扫码通道,当这家扫码通道发生问题的时候是没有任何办法的,所以一开始就对它表示怀疑,通过接入多家通道,如果一旦发生异常,实时监控系统触发报警后就自动进行路由通道切换,保证服务的可用性；其二,针对不同的支付类型、商户、交易类型做异步消息拆分,确保如果一旦有一种类型的交易发生不可预估的异常后,从而不会影响到其他通道,这个就好比高速公路多车道一样,快车和慢车道互不影响.其实总体思路就是容错+拆分+隔离,这个具体问题具体对待.

Q5: 支付超时后,会出现网络问题,会不会存在钱已付,订单丢失,如何做容灾及数据一致性,又有没重放日志,修过数据?

（编辑：ASP站长网）