中国银联科技事业部架构师 程朝

程朝2011年加入中国银联，拥有三年应用开发设计经验，三年MySQL与Redis内核开发设计经验，三年应用架构设计经验；擅长分布式系统设计，有丰富的系统设计与调优经验，现任云闪付架构优化技术负责人，致力于云闪付系统架构设计与优化工作。

摘要：

云闪付APP作为银联在移动支付领域的重要产品，推出三年多以来用户数已经突破两亿规模，随着近年来营销活动的频次和力度不断加码，现有系统的压力也越来越大，本次演讲程朝主要分享了云闪付后台系统通过不断迭代的架构优化，完成对业务和营销活动的有力支撑。

业务扩大后台迎挑战

云闪付APP与传统的金融APP相比，除了常规的信用卡账单查询和还款、二维码主扫和被扫支付、公共缴费等业务外，也有很多自身特色，比如余额查询，支持330余家银行的余额查询，能够在云闪付中查询所有绑定的借记卡的余额，比如信用卡帐单查询和还款，目前也已经对接140多家银行，并且信用卡还款是免费的，再比如银联卡权益，白金卡的一元机场停车，钻石卡的一元机场接送机等，也是非常给力的。

云闪付APP推出三年多以来，用户量增长迅速，并且在今年9月突破两亿用户；用户活跃度也不断提升，目前云闪付APP月活五千多万；同时，伴随着高频的营销活动和较大的营销力度，交易量也大幅增长。用户迅速增长，活跃度不断提升，交易量大幅增长，营销活动层出不穷，业务增长的同时也对整个后台的系统设计带来了巨大的挑战。

为了应对这些挑战，云闪付后台系统经历了一轮又一轮的架构优化，本次分享将展开其中的一些设计方法和思路，主要包括系统的拆分与隔离，数据层的水平扩展，异步化框架使用，应用级分布式事务解决方案，营销资金类问题解决方案等。

拆分与隔离

云闪付在后台架构设计上最开始对系统进行拆分和隔离，来解决最先碰到的系统横向扩展和系统间业务耦合的问题。

首先对整个系统业务线重新划分，垂直拆分成包括支付业务、营销业务、商城业务、优惠业务在内的十几条业务线。结合内部组织架构分组和板块划分，使得系统相互之间的耦合性减少。纵向拆分完之后再进行横向拆分，对服务进行分层，拆分成WEB层、接入层、业务服务层、数据层等，并将拆分过程中形成的一些公共服务独立成单独的基础业务层。

初期的拆分完成后系统耦合性降低，业务功能相互隔离，问题不会在业务线间蔓延。但是随着业务量的增长，发现某一单独业务线里依然有很大压力，相互之间依然会有一些干扰，此时对支付服务做了进一步拆分，比如拆分为主扫二维码、被扫二维码、乘车码等，形成系统内的多个子系统，耦合性进一步降低。

伴随着系统的拆分，应用也做了很多去状态化工作，形成无状态的应用层，便于应用层的横向扩展。然后在每次的活动之前，业务方都会提一些指标，系统需要根据这些指标做扩容工作。

而评估需要多少台机器需要经过多次压测，每次调整系统规模都比较耗费时间。通过将拆分后的系统单元化分组，得出每组最佳配比，每组每一层多少台机器提供多少性能，就能够根据实际业务指标从容的计算出需要多少资源和每一层的资源数量。通过不断实践优化，现阶段将之整合成一个表格，只要基于业务指标进行输入，就能计算出每条业务线需要扩多少组，需要多少台机器，每台机器分布在哪些业务上。更加从容的应用生产扩缩容。

数据分片

应用层通过一些拆分和隔离做到了应用的无状态和水平扩展，这样系统的压力就到了数据层。数据层解决方案分为两种，一种是应用和数据库之间是松耦合，可以通过消息队列解耦数据库，提升联机交易的处理性能；另外一种是应用和数据库之间是紧耦合，需要提升数据库的整体性能，主要是通过对数据库进行水平拆分。

整个云闪付系统的数据库发展历程，也是伴随着整个银联数据库的演进过程，从七年前的集中式单一数据库DB2，到五年前引入了MySQL，根据业务进行垂直拆分成各个业务库，再到现在的随着现在银联定制数据库UPSQL的发展，以及数据库代理对水平分库的支持，真正做到了数据库的水平拆分。

当然，对于缓存银联也有自己的定制产品UPRedis，也支持水平拆分，这样从应用层到数据层都具备了一定的水平扩展力，每次营销期间系统的性能也就不再棘手。

即便这样，为了系统整体的稳定，限流也是必不可少的，目前的限流主要两方面，一个是入口层网络设备F5上的限流，根据每个接口限制总的流量，比如设计性能10000，那么一般会在入口上限制为8000；另外一个限流策略则是在服务间调用，对于关键服务调用，会在RPC调用框架(magpie)中设置限流、熔断、降级策略，以保证整体系统的稳定。

最后，值得一提的是所有的架构设计都离不开业务，业务上的设计可以对后台架构设计产生很大影响，一个简单的业务上将营销时间分散，将多个活动峰值错开，就可以大大简化后台系统的设计，同时也可以节省大量的机器资源。

异步化

起因为两年前的一次活动，因为一个行业方过载整个系统响应很慢，导致调用方的线程全部阻塞，进一步导致该调用方提供的其他服务由于没有线程处理也超时，从而上层调用方的线程也全部阻塞，最终蔓延到整条业务线。本来只是一个局部性的问题，但就是因为每一层都是同步调用，最终所有线程全部挂住，问题蔓延至整个系统。

所以当时就将存在不可靠调用的部分外部系统调用做了异步化处理，比如部分余额查询从串行同步执行变成串行异步执行，并最终优化成目前的并行异步执行。

上图为云闪付自研异步化框架，为什么要做这个框架，原因是流程调度并不是简单A调用B，很多时候需要做流程编排，可能有并行调用，也可能串行调用，也可能先并行后串行等等，这样的情况需要一套框架来避免应用自行处理流程调度的内容。

另外一个原因是做基础组件一定要更加方便为应用开发服务，尽量减少应用开发犯错的可能，这个框架将常规的http调用、rpc调用、webservice调用统一封装成标准接口，开发人员只用实现call、onComplete、onTimeout、onError几个接口，系统就能够很好的run起来。

通过性能测试数据可以看出，异步化的性能整体上与同步相当，这是因为整个异步化本质上并不解决性能问题，性能问题依然是依靠于上下游系统的整体性能，但是有效减少了工作线程分配，更是减少了慢服务对快服务的影响，同时通过并行调度在一定程度上缩短了响应时间。

柔性事务

在做拆分中难免有磕绊，服务拆分到一定程度后，各种分布式一致性的问题便纷纷出场，比如扣钱、扣优惠名额问题，如果后一笔超时怎么办？各个业务条线都有自己的异常处理模式，有的把失败和异常记录到数据库或缓存，通过定时任务去回补，有的记录到消息队列，通过消费者去补偿，有的在数据库集群内，通过数据库分布式事务XA方式解决，更有的记录到日志，日终通过手工方式追补。明显各个系统实现的各不一样，会有各种问题，比如消息队列数据丢失，定时任务的可靠性等等，带来较大的业务风险。

后来整体上参考了业界柔性事务解决方案-TCC，自研了一套轻量的应用层分布式事务框架UPTCC，能够较好的支持银联分布式数据库和缓存，也集成了银联RPC框架，通过异步化加速改善整体性能，目前正在一些系统推广使用。

营销资金与安全

在营销这一块碰到的第一个问题就是热点账户问题，由于所有活动的出资方都是同一个账户，每一笔折扣立减都需要访问这个账户，形成了一个超级热点。最开始的方案自然是拆账户，但是拆多了业务方无法接受。再之后也使用硬件解决方案，比如SSD，业内常说所有能用硬件解决的问题都不是问题，但是硬件解决方案依然不能满足新要求。直到两年前UPRedis同步复制出现和数据可靠性的提升，最终通过UPRedis集群解决了此问题。

营销资金是个严肃的话题，所有关于资金类的设计都要慎之又慎。现阶段，云闪付APP对接了银联实时风控系统，防范黄牛和黑产，自身也有平衡试算机制，及时发现异常的资金变动，在应用设计方案上，做到交易幂等，并发控制，分布式一致性，业务监控预警等等，多维度防范资金风险。

补短板对外赋能

由于海量的交易和庞大的用户规模，为了进一步提升系统的可靠性，目前程朝的团队正在做双中心双活工作。

最后，开放赋能也是云闪付APP的重点工作，目前的乘车码、理财平台等都是通过开放平台对接，云闪付APP未来会进一步开放平台打造良好的产业生态，也会输出解决方案对外赋能。