五个9的可用度、秒级故障解决，探寻互联网金融应用之道
|
《五个9的可用度、秒级故障解决，探寻互联网金融应用之道》要点： 本文源自11月24日『高效开发运维』微信群的在线分享,分享者为付钱拉高级技术经理冯忠旗先生,转载请在文章开头注明来自『高效开发运维』公众号. 一句话背景介绍：付钱拉是一家互联网金融服务商,专为创业公司、中小型企业以及各种有支付需求的团队所设计的一款支付服务产品,可以在移动端应用以及PC网页操作与运行,创业者仅需几行简单代码,就能同时接入主流支付服务商. 嘉宾介绍 冯忠旗,付钱拉高级技术经理.冯先生曾经是IBM中国开发中心IaaS私有云技术负责人.2014年加入付钱拉,主导付钱拉线上线下支付平台的研发,付钱拉线上线下支付平台日处理交易额200多亿,每天平均交易量400万笔.此外,还负责支付平台相关的辅助支撑系统,包括了实时预警系统、报表系统、电商服务解决方案和理财服务解决方案等. 写在前面对于互联网应用和企业大型应用而言,多数都尽可能地要求做到7*24小时不间断运行,而要做到完全的不间断运行可以说“难于上青天”.众所周知,对应用的可用性程度一般衡量标准有三个9到五个9. 对于一个功能和数据量不断增加的应用,要保持比较高的可用性并非易事.为了实现高可用,付钱拉从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践.在不考虑外部依赖系统突发故障,如网络问题、三方支付和银行的大面积不可用等情况下,付钱拉的服务能力可以达到99.999%. 今天重点讨论如何提高应用自身的可用性,为了提高应用的可用性,首先要做的就是尽可能避免应用出现故障,但要完全做到不出故障是不可能的.互联网是个容易产生“蝴蝶效应”的地方,任何一个看似很小的、发生概率为0的事故都可能出现,然后被无限放大. 大家都知道RabbitMQ本身是非常稳定可靠的,付钱拉最开始也一直在使用单点RabbitMQ,并且从未出现运行故障,所以大家在心理上都认为这个东西不太可能出问题. 直到某天,这台节点所在的物理主机硬件因为年久失修坏掉了,当时这台RabbitMQ就无法提供服务,导致系统服务瞬间不可用. 以史为鉴故障发生了也不可怕,最重要的是及时发现并解决故障.付钱拉对自身系统的要求是,秒级发现故障,快速诊断和解决故障,从而降低故障带来的负面影响.首先我们简单的回顾一下,付钱拉曾经碰到的一些问题： (1) 新来的开发同事在处理新接入的三方通道时,由于经验不足忽视了设置超时时间的重要性.就是这样一个小小的细节,导致这个三方队列所在的交易全部堵塞,同时影响到其他通道的交易； (2) 付钱拉系统是分布式部署的,并且支持灰度发布,所以环境和部署模块非常多而且复杂.某次增加了一个新模块,由于存在多个环境,且每个环境都是双节点,新模块上线后导致数据库的连接数不够用,从而影响其他模块功能； (3) 同样是超时问题,一个三方的超时,导致耗尽了当前所配置的所有worker threads,以至于其他交易没有可处理的线程； (4) A三方同时提供鉴权,支付等接口,其中一个接口因为付钱拉交易量突增,从而触发A三方在网络运营商那边的DDoS限制.通常机房的出口IP都是固定的,从而被网络运营商误认为是来自这个出口IP的交易是流量攻击,最终导致A三方鉴权和支付接口同时不可用. (5) 再说一个数据库的问题,同样是因为付钱拉交易量突增引发的.建立序列的同事给某个序列的上限是999,999,但数据库存的这个字段长度是32位,当交易量小的时候,系统产生的值和字段32位是匹配的,序列不会升位.可是随着交易量的增加,序列不知不觉的升位数了,结果导致32位就不够存放. 类似这样的问题对于互联网系统非常常见,并且具有隐蔽性,所以如何避免就显得非常重要了. 下面我们从三个方面来看付钱拉所做的改变,这三个方面分别是尽可能避免故障、及时发现故障、及时处理故障. 尽可能避免故障一、设计可容错的系统 比如重路由,对于用户支付来说,用户并不关心自己的钱具体是从哪个通道支付出去的,用户只关心成功与否.付钱拉连接30多个通道,有可能A通道支付不成功,这个时候就需要动态重路由到B或者C通道,这样就可以通过系统重路由避免用户支付失败,实现支付容错. 还有针对OOM做容错,像Tomcat一样.系统内存总有发生用尽的情况,如果一开始就对应用本身预留一些内存,当系统发生OOM的时候,就可以catch住这个异常,从而避免这次OOM. 二、快速失败“fail fast原则” Fail fast原则是当主流程的任何一步出现问题的时候,应该快速合理地结束整个流程,而不是等到出现负面影响才处理. 举个几个例子： (1) 付钱拉启动的时候需要加载一些队列信息和配置信息到缓存,如果加载失败或者队列配置不正确,会造成请求处理过程的失败,对此最佳的处理方式是加载数据失败,JVM直接退出,避免后续启动不可用； (2) 付钱拉的实时类交易处理响应时间最长是40s,如果超过40s前置系统就不再等待,释放线程,告知商户正在处理中,后续有处理结果会以通知的方式或者业务线主动查询的方式得到结果； (3) 付钱拉使用了Redis做缓存数据库,用到的地方有实时报警埋点和验重等功能.如果连接Redis超过50ms,那么这笔Redis操作会自动放弃,在最坏的情况下这个操作带给支付的影响也就是50ms,控制在系统允许的范围内. 三、设计具备自我保护能力的系统 系统一般都有第三方依赖,比如数据库,三方接口等.系统开发的时候,需要对第三方保持怀疑,避免第三方出现问题时候的连锁反应,导致宕机. 拆分消息队列 （编辑：ASP站长网） |
Redis未授权检测漏洞G
严峻Web对抗环境下的W
遭黑客盗走AMD GPU 部
企业级信息防泄漏大方