1、概述
互联网时代对金融支付提出了越来越高的要求，既要保证金融的稳定安全可靠，又要去适应互联网时代的灵活多变、快速响应。与此同时，逐步成熟的大数据、云计算、分布式等信息技术也在不断加快技术和金融的融合，对金融业务的驱动作用更加显着。
在这个UVCA时代，如何构建一个安全、稳定、高性能、高可扩展的大型支付系统，是很多企业面临的实际课题，从业务架构、技术架构、研发体系等多方面进行阐述。
2、面临的问题
1. 业务发展不确定性的提高
互联网兴起之初谁也没有预料如此爆发性发展，金融支付领域也面临着从纸币到刷卡支付到PC端的无卡支付，又发展到移动端支付，再到扫码支付以及现在兴起的以刷脸为主流的生物特征支付，每一步迭代都比前面更快。
面对C端用户、B端用户的高要求，面对同行业的强力竞争，如何更好服务客户，如何快速调整产品去适应市场，抢占市场？单纯靠人力累加很难完美地去解决这个问题，需要考虑从技术架构上去寻找解决方案。
2. 系统稳定高效运行的要求逐步提高
随着通信技术、互联网技术的快速发展，为金融支付业务也提供了很完善的技术基础设施，国内的移动互联网支付业务发展迅猛，极度依赖移动互联网的同时，人们对互联网上支付的要求也越来越高，大型抢购时候系统是否流畅？是否能规避某些不可抗力导致的业务中断？支付业务中是否会存在用户扣款未发货的情况？
3. 安全和快捷的矛盾变得激烈
新时代下的支付越来越便捷，支付载体经历了很多演变，支付场景也从最早的面对面方式转移到千里之外的基于互联网的支付，继续转移到无感支付，在发展过程中也出现过很多的安全隐患，钓鱼网站、盗刷、敏感信息泄露、营销套利、套现等情况，如何解决安全和快捷的问题成为一个非常重要的问题。
3、建设方案
面对上述的多种挑战，如何解决“又好又快”的问题，实现“敏态”和“稳态”共存的系统，可以从下面几个方向进行分析和研究。
1. 业务架构
一个好的系统需要有明确的业务架构，能够将服务间的边界约定得尽量清晰，服务的复用度要尽量高。
可以结合业务功能通过DDD方法进行分解归类，从功能上将服务分为常规业务服务、共享业务服务、技术基础服务等几种类型，从使用实体角度由上而下进行划分，从数据聚合角度由下而上进行划分，寻找交集，形成高内聚的服务。常规业务服务要求业务集中，要求能自成体系；共享业务服务尽量要求无状态，支持幂等性等；技术基础服务要求原子化、依赖少。
最终将整体平台划分为多个有机的服务，例如支付业务服务、通道业务服务、路由服务、订单服务、安全服务等等，同时我们从运维角度根据服务的重要程度分为全局级服务、中心级服务、单元级服务，针对不同级别的服务采取不同的应急策略和切换方案，最后通过底层的分布式调用框架将这些服务连接在一起。
实践过程中，发现清晰的业务架构能够减少后续开发过程中的互相扯皮，并且能够在很大程度上降低系统的复杂度，减少缺陷，同时还能够方便进行静态的容量评估，总体提高了系统的整体稳定。
2. 技术架构
（1）系统容灾
多地容灾常规有两个关键指标RTO、RPO。对与无状态的业务是非常简单的，但是支付业务中往往非常复杂，最关键的是数据的一致性，常规的做法是把所有的关注点聚焦数据同步上，但除去这个之外可以考虑中心单元化方案，从应用层面可以实现扩展性更好的方法。
选取整体支付业务中关键分中心要素，常规的有商户、用户等，这个关键分中心要素要保证所有业务入口都要有该要素，并且分中心会相对保持流量均匀。
按这个关键要素对系统进行划分，但是当业务复杂之后，部分数据是无法按照该关键要素维度进行切割，比如当选择了商户+订单号之后，平台上确有用户相关的信息，这种情况下用户信息就是相对的全局数据，遇到这种情况就需要将这类业务独立服务，独立单元，从这个业务的特殊维度进行解决，根据全局数据是否接受调用时延和是否能接受数据时差分分别采用本地访问配合数据同步和异地异地分片配合数据同步两种方法。
（2）系统应用
在大的容灾架构下，一般应用架构设计中会考虑5高，分别是高安全、高可用、高性能、高可扩展、高可管理。
高安全方面：
1）接入层面，主要考虑接入报文的通信安全、数据安全、防抵赖防篡改安全，常规的做法是必须采用https协议，尽量采用双向https验证，同时对敏感数据进行额外的RSA或者国密SM2算法加密，对整体报文进行加盐摘要后采用RSA或者国密SM2进行签名；
2）应用安全，注意敏感信息日志脱敏，应用通过预编译、参数校验等方式规避SQL注入风险和XSS攻击风险，私钥信息尽量通过加密机，如果无加密机也尽量进行数据库加密存储，用户敏感信息需要根据情况加密或者加密摘要，同时注意敏感数据返显遮掩处理等等。
3）部署安全，实际部署上要尽量分层部署，每层之间进行预设的网络管控，入口处尽量通过反向代理服务器进行安全管控，常规的Web容器尽量只开放业务端口，避免出现较多的风险敞口。
高可用方面：
1）从外部公网入口处，采用F5、Ngnix、Apache等负载均衡设备，针对F5可以通过探测应用的额外http请求进行心跳，Ngnix和Apache等代理基本有各自通用的随机、轮训等负载均衡策略。
2）应用的高可用，采用NIO这种链路复用的长连接方式，可以通过客户端独立心跳线程，按照固定间隔进行心跳和重连。在连接负载上面建议采用基础轮训方式，能达到较好的负载均衡效果，但在云环境下因为环境复杂会存在服务端资源不均衡或者网络闪断情况，可以考虑两种策略，实现类似滑动窗口机制的动态负载均衡来支持服务端资源不均，实现针对幂等服务使用TP99双发机制达到补偿，上述方案可以更好地提高可用性。
3）数据的高可用，数据主要两类为主，数据库数据和缓存数据。数据库是落盘之后响应，所以重点考虑数据库备份措施，常规可以使用类似MySQL的主从、主主复制，还有一种可以用应用根据数据时间片来实现数据同步。缓存方面常用的Redis方面也有类似的AOF、RDB持久化方案。
高性能方面，除去算法本身之外，需要注意几点：在研发过程中要注意好日志的的级别和规范，减少无用日志的打印；通信方面尽量采用NIO等链路复用，规避每次建链的消耗；数据的缓存化更是提高性能的一个关键点，可以采用应用内存、分布式缓存结合的方案减少数据库的访问，极大提高性能。
高可扩展方面，要求应用要尽量无状态化，应用间通过注册发现解决随时扩缩容问题，尽量避免写死环境参数，尽量通过配置中心进行集群归类管理等方面去考虑。
高可管理方面，需要重点关注应用的自动化安装和大量服务下的链路跟踪和日志监控。自动化安装的难点是应用需要梳理内部的环境参数，将该类参数进行集中管理，同时维护应用部署管理和安装顺序。监控方面有以下几个建议，采用日志和消息结合，通过消息上报紧急的事件，通过松耦合的日志记录更多地监控数据达到更详细的监控效果。
（3）技术架构总结
上文描述的各方面都需要有专门团队进行平台、组件的研发，当这些基础的技术框架不断完善后，应用的开发就变得轻松，系统就会更加稳定。
技术框架是整体业务发展的奠基石，特别是在大型的分布式系统中，完善的底层框架能够为整体系统的稳定运行和业务快速发展提供充分的支撑，工欲善其事必先利其器，在技术框架上的投入是一个必要工作。
3. 研发体系
需要约定好内部的服务边界职责、详细定义服务接口；搭建mock平台，来解决面向接口的服务测试；搭建持续集成平台，积累业务案例，提高持续构建的速度和质量；采用预发布、灰度发布、蓝绿发布等方式，降低版本发布风险。
4、结语
设计和总结是多年支付领域研发工作的一些经验，每一个方面和领域展开又是一个复杂的课题，但作为大型支付系统研发工作需要全方位的考虑各个内容。总体而言，业务的发展促使技术的进步，技术的进步也更加服务业务，甚至促进业务。
“快”和“好”并不冲突，鱼和熊掌也可兼得。这个就是技术人员的价值，通过理念的变化、技术手段的升级去完成以前认为不可能的事情。
