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