本文以「付钱拉」后台支付系统为背景，是「付钱拉」支付系统架构系列的第一篇文章，旨在剖析其总体架构实践。本文主要抛砖引玉，简要分析「付钱拉」的架构设计理念，具体的技术实现和最佳实践后续会在其他系列文章详细介绍。
「付钱拉」支付系统每天平均处理订单量100w-200w笔，账单交易日交易量在300万笔以上、每个月处理支付交易流水在300亿左右、对接银行和三方有30多家以及接入商户几千个。从刚开始系统仅仅处于能用阶段，日交易量几千笔到现在，系统架构根据业务的不断发展迭代多个阶段。主要从以下几个方面来分享：
一、系统目标
「付钱拉」支付系统需要满足持续不断的业务增长，系统设计的时候有以下目标。
可伸缩
随着业务量的增长，单个节点不足以满足性能问题，就要各个系统模块支持横向扩展和分部署部署。
可测试
测试是代码质量的最后一道防线，「付钱拉」系统支持分布式部署，但是目前的框架给测试也带来许多困难，比如开发人员在本地测试的时候，不同的开发人员相互争抢MQ消息。
可监控
作为支付系统，和钱打交道，不允许任何出错，实时性要求非常高。如果瞬间发送一个问题，可能影响的交易金额就不可估计了。所以如何及时发现问题，监控系统就是「付钱拉」的眼睛。
可报警
满足了监控，报警就必不可少。但是往往监控项目和场景会非常多，如何选择哪些项目为出警项，哪些为关注项就非常重要。如果全部为出警项，对于报警接受人员，可能造成狼来了的效应，当出现真正需要报警的时候，重视度就会降低。
其次是报警方式，无非是推送和拉取模式，通过监控页面，监控室，短信，邮件等。
可配置
在支付系统有很多的参数，并且随时可以发生变化，如果每次变化都需要重启系统，肯定是不可以的。比如响应码状态的配置，银行维护配置，交易处理时间段等等，可配置就可以解决此类问题，保证客户端无感知。
安全性
安全性能对至于任何系统都是命脉，对于支付系统更加像心脏一样。安全性主要有两个方面，一个是用户数据安全，一个系统支付安全。用户数据安全要求展示层面、存储层面、内部交互层面和外部通信层面都必须是安全的；支付安全，包括人为操作导致的支付损失和系统bug导致的支付损失。
高可用
高可用要求系统能够一直提供稳定的服务，满足SLA的要求。「付钱拉」为了提供高可用服务，所有的系统组件拒绝单点部署，从业务模块，数据库，消息中间，定时服务和Nginx等都做了集群功能。
高性能
高性能要求提供快速的响应时间，「付钱拉」有大量的互联网类型的支付交易，对交易的实时响应时间要求非常高，不可以让用户端感觉支付非常慢。「付钱拉」对整个支付环节的做法是拆分，通过分步和异步提高并发能力。
二、业务痛点
以下就「付钱拉」系统随着业务的演变，不同阶段遇到的业务痛点，从而架构层面都做了哪些改变。
业务量的突然增长
「付钱拉」系统刚上线的时候每天交易量最多也就1Q笔左右，不到两个月的时间系统每天的交易量从1w要增加到200W笔，这时候系统初始的架构不能够满足系统的业务增长量。
做的第一件事，分布式部署。系统业务模块做拆分，一个大的块功能模块拆分成好几个模块来实现，并且每个模块都是无状态的，这样才可以支持横向扩展。
做的第二件事，解决数据库大表问题。「付钱拉」系统有两张大表，一个是支付记录表，另外一个是支付日志轨迹表。系统刚开始支付记录只有一张表来存储，一个月的数据量这张表就已经6000W了，如果一个开发人员因为疏忽sql忘记按照索引查询，对数据库来说可能就像蝴蝶效应一样。为了快速解决问题，「付钱拉」做了一些改变，读写数据分离、冷数据清除和部分功能借助缓存来减少数据库压力。这些都是能够快速去解决问题的，长期方案「付钱拉」采用分库分表的方式。
如何应对滚雪球效应
「付钱拉」系统最初消息队列是按照不同的支付类型来拆分的，但是随着后端三方和银行的不断接入，不同的三方网络和处理能力都不一样。导致同样的支付类型下面，一个三方宕机从而堵塞其他三方的交易，产生滚雪球效应，雪球越滚越大，最后直至拖垮所有交易。
针对这种情况，「付钱拉」做的改变是隔离，按照商户、三方、和支付类型做彻底隔离，确保不同的业务和商户各行其道，相互不受影响。这个改变就好比，原来是单行道，现在变成了多行道，就像高速公路一样。
系统存在的单点故障
任何的单点都是存在风险的，不要相信任何软件或者功能是多么的无坚不摧。举一个例子，「付钱拉」系统之前使用消息中间件是单节点，并且运行一直非常稳定，从来没有出现过故障。但是有一天，它所在的物理机器网卡掉了，瞬间它不能提供服务。所以从这个案例讲，单点故障也许不是你本身的故障，但是如果单点就可能发生风险，
「付钱拉」目前所有的节点包括中间件都是双备。
如何避免操作风险
操作风险可以认为是人为风险。作为互联网系统，如果因为操作风险导致一个小bug，可能充其量就是影响用户体验，立即修复即可。但是对于支付系统，每笔交易都是真金白银，不可以有任何一个小小的操作风险。
「付钱拉」经验总结操作风险主要有以下几种：上线操作风险、代码未审核风险、生产环境变更风险、订单修改风险、测试风险。如何避免这些操作风险，其他系列会详细展开讨论。
系统是否具备自我保护能力
系统具备自我保护能力，就是容错，快速失败，降级和限制使用。系统具备自我保护能力，就是当因为各种原因发生不可预期的问题的时候，它能够自己解决问题。
容错，比如发生一笔交易，发生了网络异常，如果明确知道这笔交易没有发往三方，那么就可以尝试在发送一次来提高成功率；「付钱拉」有一个自动重路由功能，第一次路由到的通道如果交易失败，符合一定条件，会自动重路由去尝试别的通道，这就是很好的容错；还有一种容错场景，一般系统如果发生OOM异常一定会死掉。如果能够在设计系统的时候，预留一部分内存，然后当发生OOM的时候，去catch住处理掉，这样一个小小的容错就能够避免系统一次OOM.
快速失败原则，如果系统启动的时候，明确知道缺少哪些东西，就算启动了服务也不可用，那这时候启动的时候就让启动直接失败；还有针对实时类交易，如果超过响应时间，就快速失败响应用户，而不是无休止等待。
服务降级是在系统达到一定访问量的时候，如果不能满足服务要求，必须要做的事情。「付钱拉」在针对商户活动日的时候，就做了服务降级。
限制，如果系统资源无限制使用，没有管控，一定会在某个时间点发生事故，比如数据库和内存等。「付钱拉」主要做了以下限制:限制各个模块的连接数的个数，因为横向扩展一定会引发这个问题；限制内存的使用，内存过大会导致频繁的GC和OOM; 限制woker线程的个数；限制三方的并发数量。
外挂系统
外挂系统主要是用来支撑核心系统，但是它的引入又不可以影响核心系统。「付钱拉」有两个外挂系统个，一个是日志轨迹系统，一个是实时预警系统。具体的实现会在其他系列讨论。
支付安全问题
「付钱拉」的支付安全主要来自外在安全和内在安全两个方面。外在安全包括用户敏感数据展示、存储、内部交互、外部通信和人为操作；内在安全主要指系统并发导致的资金支付风险。
促销活动
在业务线做促销的时候，交易量剧增，但是受限于指定的支付通道和并发处理能力，如果交易量超过了处理能力，为了满足其他商户不受影响，「付钱拉」针对不同的商户做了服务降级处理。
业务创新
现实业务场景往往比理想的业务场景复杂的多，「付钱拉」在不同的支付类型上做了多种业务创新和封装。比如超级快捷，Token支付，快捷服务化，鉴权服务化，动态重路由，代扣Plus等等的创新来满足各种各样的业务需求。在这个过程中还要处理各种特殊的接入的第三方。
系统架构和业务的演进是不间断的，没有终点，没有银弹。只要矢志不移的去改变，是适应才可以满足业务需求，「付钱拉」的架构和业务改进也将是持续不断的，比如动态路由，比如服务治理等等。虽然目前市面各家系统架构实际众多，但是也都各自有特性。本文以「付钱拉」系统实践来简要剖析支付系统的架构特点，后续会在其他系列对本文中提到的点进行详细讨论。
