可用性高达5个9！支付系统高可用架构设计实战

可用性高达5个9！支付系统高可用架构设计实战

一、背景

对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全不间断运行可以说“难于上青天”。为此，对应用可用性程度的衡量标准一般有3个9到5个9。

可用性指标	计算方式	不可用时间（分钟）
99.9%	0.1%*365*24*60	525.6
99.99%	0.01%*365*24*60	52.56
99.999%	0.001%*365*24*60	5.256

对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，宜信支付系统从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。

在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，宜信支付系统的服务能力可以达到99.999%。

本文重点讨论如何提高应用自身的可用性，关于如何避免单点故障和解决交易量增长问题会在其他系列讨论。

为了提高应用的可用性，首先要做的就是尽可能避免应用出现故障，但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方，任何一个看似很小的、发生概率为0的事故都可能出现，然后被无限放大。

大家都知道RabbitMQ本身是非常稳定可靠的，宜信支付系统最开始也一直在使用单点RabbitMQ，并且从未出现运行故障，所以大家在心理上都认为这个东西不太可能出问题。

直到某天，这台节点所在的物理主机硬件因为年久失修坏掉了，当时这台RabbitMQ就无法提供服务，导致系统服务瞬间不可用。

故障发生了也不可怕，最重要的是及时发现并解决故障。宜信支付系统对自身系统的要求是，秒级发现故障，快速诊断和解决故障，从而降低故障带来的负面影响。

二、问题

以史为鉴。首先我们简单的回顾一下，宜信支付系统曾经碰到的一些问题：

(1) 新来的开发同事在处理新接入的三方通道时，由于经验不足忽视了设置超时时间的重要性。就是这样一个小小的细节，导致这个三方队列所在的交易全部堵塞，同时影响到其他通道的交易；

(2) 宜信支付系统是分布式部署的，并且支持灰度发布，所以环境和部署模块非常多而且复杂。某次增加了一个新模块，由于存在多个环境，且每个环境都是双节点，新模块上线后导致数据库的连接数不够用，从而影响其他模块功能；

(3) 同样是超时问题，一个三方的超时，导致耗尽了当前所配置的所有worker threads, 以至于其他交易没有可处理的线程；

(4) A三方同时提供鉴权，支付等接口，其中一个接口因为宜信支付系统交易量突增，从而触发A三方在网络运营商那边的DDoS限制。通常机房的出口IP都是固定的，从而被网络运营商误认为是来自这个出口IP的交易是流量攻击，最终导致A三方鉴权和支付接口同时不可用。

(5) 再说一个数据库的问题，同样是因为宜信支付系统交易量突增引发的。建立序列的同事给某个序列的上限是999，999，999，但数据库存的这个字段长度是32位，当交易量小的时候，系统产生的值和字段32位是匹配的，序列不会升位。可是随着交易量的增加，序列不知不觉的升位数了，结果导致32位就不够存放。

类似这样的问题对于互联网系统非常常见，并且具有隐蔽性，所以如何避免就显得非常重要了。

三、解决方案

下面我们从三个方面来看宜信支付系统所做的改变。

3.1 尽可能避免故障

3.1.1 设计可容错的系统

比如重路由，对于用户支付来说，用户并不关心自己的钱具体是从哪个通道支付出去的，用户只关心成功与否。宜信支付系统连接30多个通道，有可能A通道支付不成功，这个时候就需要动态重路由到B或者C通道，这样就可以通过系统重路由避免用户支付失败，实现支付容错。

还有针对OOM做容错，像Tomcat一样。系统内存总有发生用尽的情况，如果一开始就对应用本身预留一些内存，当系统发生OOM的时候，就可以catch住这个异常，从而避免这次OOM。

3.1.2 某些环节快速失败“fail fast原则”

Fail fast原则是当主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，而不是等到出现负面影响才处理。

举个几个例子：

(1)支付系统启动的时候需要加载一些队列信息和配置信息到缓存，如果加载失败或者队列配置不正确，会造成请求处理过程的失败&