对付互联网运用和企业大型运用而言，多数都尽可能地哀求做到724小时不间断运行，而要做到完备不间断运行可以说“难于上上苍”。为此，对运用可用性程度的衡量标准一样平常有3个9到5个9。
可用性指标
打算办法
不可用韶光（分钟）
99.9%
0.1%3652460
525.6
99.99%
0.01%3652460
52.56
99.999%
0.001%3652460
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)「付钱拉」启动的时候须要加载一些行列步队信息和配置信息到缓存，如果加载失落败或者行列步队配置禁绝确，会造成要求处理过程的失落败，对此最佳的处理办法是加载数据失落败，JVM直接退出，避免后续启动不可用；
(2)「付钱拉」的实时类交易处理相应韶光最长是40s，如果超过40s前置系统就不再等待，开释线程，奉告商户正在处理中，后续有处理结果会以关照的办法或者业务线主动查询的办法得到结果；
(3)「付钱拉」利用了redis做缓存数据库，用到的地方有实时报警埋点和验重等功能。如果连接redis超过50ms，那么这笔redis操作会自动放弃，在最坏的情形下这个操作带给支付的影响也便是50ms，掌握在系统许可的范围内。
3.1.3 设计具备自我保护能力的系统
系统一样平常都有第三方依赖，比如数据库，三方接口等。系统开拓的时候，须要对第三方保持疑惑，避免第三方涌现问题时候的连锁反应，导致宕机。
（1）拆分行列步队
「付钱拉」供应各种各样的支付接口给商户，常用的就有快捷，个人网银，企业网银，退款，撤销，批量代付，批量代扣，单笔代付，单笔代扣，语音支付，余额查询，身份证鉴权，银行卡鉴权，卡密鉴权等。与其对应的支付通道有微信支付，ApplePay，支付宝等30多家支付通道，并且接入了几百家商户。在这三个维度下，如何确保不同业务、三方、商户、以及支付类型互不影响，「付钱拉」所做的便是拆分行列步队。下图是部分业务行列步队拆分图：
（2）限定资源的利用
对付资源利用的限定设计是高可用系统最主要的一点，也是随意马虎被忽略的一点，资源相对有限，用的过多了，自然会导致运用宕机。为此「付钱拉」做了以下作业：
限定连接数随着分布式的横向扩展，须要考虑数据库连接数，而不是无休止的最大化。数据库的连接数是有限定的，须要全局考量所有的模块，特殊是横向扩展带来的增加。
限定内存的利用内存利用过大，会导致频繁的GC和OOM，内存的利用紧张来自以下两个方面：
A:凑集容量过大；
B:未开释已经不再引用的工具，比如放入ThreadLocal的工具一贯会等到线程退出的时候回收。
限定线程创建线程的无限制创建，终极导致其不可控，特殊是隐蔽在代码中的创建线程方法。
当系统的SY值过高时，表示Linux须要花费更多的韶光进行线程切换。Java造成这种征象的紧张缘故原由是创建的线程比较多，且这些线程都处于不断的壅塞（锁等待，IO等待）和实行状态的变革过程中，这就产生了大量的高下文切换。
除此之外，Java运用在创建线程时会操作JVM堆外的物理内存，太多的线程也会利用过多的物理内存。
对付线程的创建，最好通过线程池来实现，避免线程过多产生高下文切换。
限定并发做过支付系统的该当清楚，部分三方支付公司是对商户的并发有哀求的。三方给开放几个并发是根据实际交易量来评估的，以是如果不掌握并发，所有的交易都发给三方，那么三方只会回答“请降落提交频率”。
以是在系统设计阶段和代码review阶段都须要特殊把稳，将并发限定在三方许可的范围内。
我们讲到「付钱拉」为z实现系统的可用性做了三点改变，其一是尽可能避免故障，接下来讲后面两点。
3.2 及时创造故障
故障就像鬼子进村落，来的惊惶失措。当预防的防线被冲破，如何及时拉起第二道防线，创造故障担保可用性，这时候报警监控系统的开始发挥浸染了。一辆没有仪表盘的汽车，是无法知道车速和油量，转向灯是否亮，就算“老司机”水平再高也是相称危险的。同样，系统也是须要监控的，最好是涌现危险的时候提前报警，这样可以在故障真正引发风险前办理。
3.2.1 实时报警系统
如果没有实时报警，系统运行状态的不愿定性会造成无法量化的灾害。「付钱拉」的监控系统指标如下：
实时性-实现秒级监控；全面性-覆盖所有系统业务，确保无去世角覆盖；实用性-预警分为多个级别，监控职员可以方便实用地根据预警严重程度做出精确的决策；多样性-预警办法供应推拉模式，包括短信，邮件，可视化界面，方便监控职员及时创造问题。报警紧张分为单机报警和集群报警，而「付钱拉」属于集群支配。实时预警紧张依赖各个业务系统实时埋点数据统计剖析实现，因此难度紧张在数据埋点和剖析系统上。
3.2.2 埋点数据
要做到实时剖析，又不影响交易系统的相应韶光，「付钱拉」在系统各个模块中通过redis实时做数据埋点，然后将埋点数据汇总到剖析系统，剖析系统根据规则进行剖析报警。
3.2.3 剖析系统
剖析系统最难做的是业务报警点，例如哪些报警只要一出来就必须出警，哪些报警一出来只须要关注。下面我们对剖析系统做一个详细先容：
(1)系统运行架构
(2)系统运行流程
(3)系统业务监控点
「付钱拉」的业务监控点都是在日常运行过程中一点一滴总结出来的，分为出警类和关注类两大块。
A:出警类
网络非常预警；单笔订单超时未完成预警；实时交易成功率预警；非常状态预警；未回盘预警；失落败关照预警；非常失落败预警；相应码频发预警；核对不一致预警；分外状态预警；B:关注类
交易量非常预警；交易额超过500W预警；短信回填超时预警；造孽IP预警；3.2.4 非业务监控点
非业务监控点紧张是指从运维角度的监控，包括网络，主机，存储，日志等。详细如下：
(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笔，涉及3个通道， 触发了预警阀值.3.2.5 日志记录和剖析系统
对付一个大型系统而言，每天记录大量的日志和剖析日志是有一定的难度的。「付钱拉」每天均匀有200W笔订单量，一笔交易经由十几个模块流转，假设一笔订单记录30条日志，可想而知每天会有多么巨大的日志量。
「付钱拉」日志的剖析有两个浸染，一个是实时日志非常预警，其余一个是供应订单轨迹给运营职员利用。
(1)实时日志预警
实时日志预警是针对所有实时交易日志，实时抓取带有Exception或者Error的关键字然后报警。这样的好处是，如果代码中有任何运行非常，都会第一韶光创造。「付钱拉」针对实时日志预警的处理办法是，首先采取rsyslog完成日志归集，然后通过剖析系统实时抓取，再做实时预警。
(2)订单轨迹
对付交易系统，非常有必要实时理解一笔订单的状态流转。「付钱拉」最初的做法是通过数据库来记录订单轨迹，但是运行一段韶光后，创造订单量剧增导致数据库表过大不利于掩护。
「付钱拉」现在的做法是，每个模块通过打印日志轨迹，日志轨迹打印的格式按照数据库表构造的办法打印，打印好所有日志后，rsyslog来完成日志归集，剖析系统会实时抓取打印的规范日志，进行解析然后按天存放到数据库中，并展示给运营职员可视化界面。
日志打印规范如下：
2016-07-22 18: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-22 18:15:00.170||2016-07-22 18:15:00.496xxxxxxxxxxxxxxxxxxxx
||2016-07-2019:06:13.000||||||||01||0103||111xxxxxxxxxxxxxxxxxxxxxxxxx
||8fb64154bbea060afec5cd2bb0c36a752be734f3e9424ba7xxxxxxxxxxxxxxxxxxxx
||622xxxxxxxxxxxxxxxx||9bc195a59dd35a47||f2ba5254f9e22914824881c242d211
||||||||||||||||||||6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx010||||||||||
简要日志可视化轨迹如下：
日志记录和剖析系统除了以上两点，也供应了交易和相应报文的下载和查看。
3.2.6 724小时监控室
「付钱拉」以上的报警项目给操作职员供应推拉两种办法，一种是短信和邮件推送，一种是报表展示。除此之外，由于支付系统比较互联网其他系统本身的主要性，「付钱拉」采取724小时的监控室担保系统的安全稳定。
3.3 及时处理故障
在故障发生之后，特殊是生产环境，第一韶光要做的不是探求故障发生的缘故原由，而因此最快速率处理故障，保障系统的可用性。「付钱拉」常见的故障和处理方法如下：
3.3.1 自动修复
针对自动修复部分，「付钱拉」常见的故障都是三方不稳定造成的，针对这种情形，便是上面说的系统会自动进行重路由。
3.3.2 做事降级
做事降级指在涌现故障的情形下又无法快速修复的情形下，把某些功能关闭，以担保核心功能的利用。「付钱拉」针对商户匆匆销的时候，如果某个商户交易量过大，会实时的调度这个商户的流量，使此商户做事降级，从而不会影响到其他商户，类似这样的场景还有很多，详细的做事降级功能会在后续系列先容。
四、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: 支付超时后，会涌现网络问题，会不会存在钱已付，订单丢失，如何做容灾及数据同等性，又有没重放日志，修过数据？
A5：做支付最主要的便是安全，以是针对订单状态我们都是守旧处理策略，因此对付网络非常的订单我们都是设置处理中状态，然后终极通过主动查询或者被动接管关照来完成和银行或者三方的终极同等性。支付系统中，除了订单状态还有相应码问题，大家都知道银行或者三方都是通过相应码来相应的，相应码和订单状态的翻译也是一定要守旧策略，确保不会涌现资金多付少付等问题。总之这个点的总体思路是，资金安全第一，所有的策略都是白名单原则。
Q6: 刚才提到过，若某支付通道超时，路由策略会分发至另一通道，根据那个通道图可看出，都是不同的支付办法，比如支付宝或微信支付，那如果我只想通过微信支付，为啥不是重试，而要换到另一通道呢？还是通道本身意思是要求节点？
A6：首先针对超时不可以做重路由，由于socket timeout是不能确定这笔交易是否发送到了三方，是否已经成功或者失落败，如果是成功了，再重试一遍如果成功，针对付款便是多付，这种情形的资金丢失对公司来说不可以的；其次，针对路由功能，须要分业务类型，如果是单笔代收付交易，用户是不关心钱是哪个通道出去的，是可以路由的，如果是扫码通道，用户如果用微信扫码，肯定终极是走微信，但是我们有好多中间渠道，微信是通过中间渠道出去的，这里我们可以路由不同的中间渠道，这样终极对付用户来说还是微信支付。
Q7: 能否举例说下自动修复的过程？如何创造不稳定到重路由的细节？
A7: 自动修复也便是通过重路由做容错处理，这个问题非常好，如果创造不稳定然后去决策重路由。重路由一定是明确当前被重路由的交易没有成功才可以路由，否则就会造成多付多收的资金问题。我们系统目前重路由紧张是通过事后和事中两种办法来决策的，针对事后比如5分钟之内通过实时预警系统创造某个通道不稳定，那么就会把当期之后的交易路由到别的通道；针对事中的，紧张是通过剖析每笔订单返回的失落败相应码，相应码做状态梳理，明确可以重发的才做重路由。这里我指列举这两点，其他的业务点还非常多，鉴于篇幅缘故原由，不做详述，但是总体思路是必须有一个内存实时剖析系统，秒级决策，这个别系必须快，然后结合实时剖析和离线剖析做决策支撑，我们的实时秒级预警系统就做这个事情。
Q8: 商户匆匆销有规律吗？匆匆销时峰值与平时比较会有多少差别？有技能演习训练么？降级的优先级是若何的？
A8：商户匆匆销一样平常我们会事先常常和商户保持沟通，事先理解匆匆销的韶光点和匆匆销量，然后针对性做一些事情；匆匆销峰值和平时差距非常大，匆匆销一样平常都是2个小时之内的比较多，比如有的卖理财产品，匆匆销也就集中在1个小时之内，以是峰值非常高；技能演习训练是我们在理解商户的匆匆销量，然后预估系统的处理能力，然后提前做演习训练；降级的优先级紧张是针对商户的，由于接入我们的商户支付场景比较多的，有理财，有代收付，有快捷，有扫码等等，以是我们整体原则便是不同的商户之间一定不可以相互影响，由于不能由于你家做匆匆销影响了其他商家。
Q9：rsyslog归集日志怎么存储的？
A9: 这个是好问题，刚开始我们的日志也便是订单轨迹log是记录在数据库表中的，结果创造一笔订单流转须要好多模块，这样一笔订单的日志轨迹便是10笔旁边，如果一天400w笔交易的话，这张数据库表就有问题了，就算拆分也是会影响数据库性能的，并且这个属于赞助业务，不应该这样做。然后，我们创造写日志比写数据库好，以是把实时日志打印成表格的形式，打印到硬盘上，这块由于只是实时日志以是日志量不大，便是在日志做事器的一个固定目录下。由于日志都是在分布式机器上，然后通过归集日志到一个集中的地方，这块是通过挂载存储的，然后有专门运维团队写的程序去实时解析这些表格形式的日志，终极通过可视化页面展示到运营操作页面，这样运营职员看到的订单轨迹险些是实时的，您关心的怎么存储实际上不是啥问题，由于我们分了实时日志和离线日志，然后超过一定韶光的离线日志会切割，终极被删除。
Q10: 系统监控和性能监控如何合营的？
A10：我理解的系统监控包括了系统性能监控，系统性能监控是系统整体监控的一部分，不存在合营问题，系统性能监控有多个维度，比如运用层面，中间件，容器等。系统的非业务监控可以查看文章分享。
