一、引言
目前，云计算服务正日益演变成为新型的信息基础设施。2020年，我国政府出台了多项政策鼓励云计算的发展。其中，由国家发改委和中央网信办于2020年4月联合发布的《关于推进“上云用数赋智”行动培育新经济发展实施方案》中提到，鼓励在具备条件的行业领域和企业范围内，探索大数据、人工智能、云计算、数字孪生、5G、物联网和区块链等新一代数字技术的应用和集成创新。文件再一次明确了云计算在实现行业或企业数字化转型中的重要地位。
第二代支付系统是我国重要的金融基础设施之一，具有适应新兴电子支付发展、面向参与者管理需要、功能更完善、架构更合理、技术更先进、管理更简便等特点。
本文试图论证云计算应用于第二代支付系统的可行性，分析支付系统向云平台迁移的策略，并针对每个步骤、每个具体的央行支付子系统进行具体分析，根据不同子系统的特点，逐个提出了针对性的上云方案。
二、云计算简介
云计算是分布式计算的一种，通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后通过多部服务器组成的系统处理和分析这些小程序，得到结果并返回给用户。与传统的网络应用模式相比，云计算具有动态可扩展、按需部署、灵活性高、可靠性高、性价比高、可扩展性等优势。
云计算按照部署方式可以分公有云、私有云和混合云。公有云通常指第三方为用户提供的云，其可通过Internet使用，特点是价格低廉，核心属性是共享服务资源。私有云是为一个用户单独使用而构建的，可以部署在数据中心的防火墙内，核心属性是专有资源，在数据安全性和质量服务上可以有效控管。
混合云则融合了公有云和私有云的优劣势，综合了数据安全性和资源共享性两方面的考虑，个性化的方案达到了省钱安全的目的。
云计算的服务类型主要分为基础设施即服务（Iaa S）、平台即服务（Paa S）和软件即服务（Saa S)3类。基础设施即服务向云计算提供商的个人或组织提供虚拟化计算资源，如虚拟机、存储、网络和操作系统；
平台即服务为开发人员提供通过全球互联网构建应用程序和服务的平台，为开发、测试和管理软件应用程序提供按需开发环境；软件即服务通过互联网提供按需软件付费应用程序，以及云计算提供商托管和管理软件应用程序，其允许用户连接到应用程序并通过全球互联网访问应用程序。
三、支付系统架构介绍
立足第一代支付系统的成功经验，第二代支付系统引入先进的清算管理理念和技术，进一步丰富系统功能，提高清算效率，拓宽服务范围，加强运行监控，完善灾备系统。第二代支付系统以清算账户管理系统为核心，大额支付系统、小额支付系统、支票影像交换系统、网银互联子系统为业务应用子系统，公共管理控制系统和支付管理为支持系统。
金融系统的发展趋势是数据集中化，第二代支付系统在设计上同样倾向于数据集中处理架构。数据集中架构具有系统结构简单、利于集中运行维护、业务流程简单的优点，但也有不足之处：随着业务的发展，基础设施投入将成倍增加；规模扩大使系统维护成本和难度成几何级数增长；系统运行风险高度集中。
合理运用云计算技术可以很好地解决数据集中架构所带来的问题，由此，引入云计算技术具有一定的现实意义。
四、云计算在央行支付系统的应用规划
（一）实施路径规划
云计算技术与二代支付系统的结合，最重要的是整个过程不能影响支付系统的正常工作。要充分考虑系统的实际情况，按照支付系统建设的基本要求和准则，从前期的系统分析、规划设计，到实施过程的系统开发、部署，再到后期的测试、运维管理，都要配套严谨周密的实施方案，有条理、有计划地分阶段逐步进行，力争在最低风险的前提下获得最大的收益。
本文认为，支付系统向云平台迁移主要可以分为4个阶段。
1. 第一阶段——云平台搭建阶段
主体采用容器技术和容器编排管理系统，完成云原生平台的初步搭建。搭建过程要求符合国家相关的安全等保规则，且与二代支付系统生产环境隔离，确保始终不会影响支付系统的正常运行。
云平台搭建完成后，可以将现有的历史数据迁移到云平台，建设基础数据中心，构建统一的数据存储体系，统一进行数据建模，为数据的价值呈现奠定基础。同时数据处理能力下沉，建设集中的数据处理中心，提供强大的数据处理能力；通过统一的数据管理监控体系，保障系统的稳定运行。
2. 第二阶段——大数据分析平台
该阶段可在搭建好的云平台的基础上，利用海量基础设施和数据仓库进一步搭建大数据分析平台，依靠弹性伸缩机制实现高效稳定的数据存储和处理，建设出统一的云数据中心，满足查询系统不同的交互需求。
3. 第三阶段——支付信息类、管理类以及监控类系统迁移阶段
该阶段中，计划对不直接参与业务系统运行的管理系统进行尝试性的迁移，包括统计分析、行名行号、支付参数管理等一系列子系统。该类型系统上云改造时要考虑分布式架构改造，使用面向服务模式的技术架构，让系统功能形成服务集群，为其他业务系统提供支撑服务。
4. 第四阶段——核心业务处理系统迁移阶段
在前期多个阶段的实践中，相关人员已经积累了充分的经验和技术，可以尝试实现核心业务系统逐步上云。主要的迁移目标是业务系统和清算系统：业务系统指的是央行支付系统的核心业务处理系统，包含大小额支付、超级网银、境内外币支付等子系统，是最主要的业务处理系统；
清算系统指清算账户管理系统，主要负责交易的风险控制和资金清算处理，是支付系统的核心支持系统，通过集中存储清算账户，处理支付业务的资金清算并对清算账户进行管理。这两类系统都具有业务量多、并发量大的特点，也是迁移过程中难度最大的系统。
根据上述央行支付系统的划分以及上云的优先级，笔者认为各类支付系统可以依据这种步骤逐步上云，将适合云化部署且准备充分的服务置于首选地位，以使央行支付系统上云带来的收益最大化、成本和风险最小化。
（二）整体架构规划
云计算在央行支付系统的应用按照上述实施规划分步实施。实施过程按照面向服务的架构进行设计，利用集群和分布式技术，从基础设施层、平台层以及应用层进行服务化建设，从各个层次提供不同的服务。
整体架构按照云计算架构分为3层：基础设施层、平台中间件层、应用层。
基础设施层主要提供基础的IT资源。以“异地多活”为实现目标，首先进行多地多机房的物理建设，利用虚拟化技术和云管平台，将各种硬件资源虚拟化并重组管理起来。
平台层基于基础设施层搭建，提供了稳定的开发部署平台和中间件服务，尽可能地减少重复建设，提高组件的重用率。
最终的系统应用建设在应用层，采用面向服务的架构，对系统功能进行合理的分割和分层，在基础设施层和平台层的基础上，采用集群和分布式架构，建立起高可用、高性能的系统服务。整体架构如下图1所示。
图1 整体架构
五、结合云计算平台的央行支付系统设计
（一）云计算平台建设
基础设施层是二代支付云平台的最底层设施，主要为平台层和应用层提供计算、网络、存储等基础资源以及对这些资源的管理服务。该部分主要依赖现有成熟云平台搭建技术进行搭建。
参考了目前业界广泛采用的云方案，同时为了满足二代支付系统对高可靠高可用的要求，笔者在设计云计算整体架构时，引入了地域和可用区的设计思想。
地域通常由某个行政区域内的所有数据中心组合成的一个云服务合集，可用区是指地理位置靠近的一组数据中心群。一个地域内包含多个可用区，一个可用区通常由一个或多个数据中心组成。
在基础设施的设计中，每个可用区各自为一个隔离的单元，电力设施独立建设互不干扰，这样一来，即使单个机房或可用区发生故障，也仅局限于其所在的可用区，而不会波及周边的可用区。同时，利用云计算技术易扩展、易接入的特点，通过高速网络将同一地域内的可用区连接起来，内网互联，极大地提高了地域内云平台运行的可用性。
传统的灾备设计中，“两地三中心”是一种广泛被提及和应用的架构，旨在通过异地冗余和主备切换的方式实现容灾。然而在这种模式下，一方面，异地备份机房的设备多数情况下都处于闲置状态，形成资源浪费；另一方面，由于异地机房没有实时参与支付业务，并不清楚这些设备真正的运行情况，增加了主备切换失败的风险。
因此，在本文的架构设计中，摈弃了现有的“两地三中心”的设计思想，而是采用“三地六中心”的异地多活架构来改进支付系统基础设施——生产环境分三个地域进行部署，每个地域包含两个数据中心（可用区），六个可用区的硬件资源可以同时处理结算业务请求。
相比于原来的设计，该方案既提高了资源利用率和基础设施的可靠性，又无需担心切换难的问题，同时还极大地提升了系统的运算性能。
作为我国最关键的金融通道之一，二代支付系统对稳定性、安全性和保密性都有极高的要求。如果将二代支付系统与云计算技术结合，笔者认为私有云是最符合需求的部署模型——在为金融机构和清算组织提供支付、清算、轧差云服务的同时，屏蔽底层的基础设施和信息，并由内部的运维人员对云平台进行监控管理。
（二）数据存储和数据备份
利用云编排技术，在应用层以地域为单元统一部署Hadoop数据服务集群，主要用作当前历史业务数据的云仓库。每当生产环境的历史数据库发生更新时，立刻主动或被动地同步到云平台，按照一定的规则分片导入到三个地域的Hadoop数据中。其大致架构如图2所示（以地域A为例）。
图2 大数据存储架构和业务流
（三）大数据分析系统应用
大数据分析系统架构如图3所示。
图3 大数据分析系统架构
首先在已构建好的大数据存储备份平台的基础上，通过技术手段采集更多的相关信息，丰富数据来源，为上层的数据处理和数据分析提供数据材料。
有了数据基础，充分利用大数据技术和数据仓库技术，建设更高效的数据应用中心。根据业务特点，构建面向不同主题的数据集市，提供高度汇总的统计数据，降低数据使用门槛。
在数据基础上，构建统一的分析应用，提供各种BI产品，满足业务需求，体现数据价值。
（四）轧差服务系统应用
轧差数据来源于各地各业务系统的数据，并通过相应的轧差运算，逐步向上汇集，完成整个轧差任务，轧差数据流如图4所示。
图4 轧差数据流
各地各业务系统产生的业务数据分布于各地各数据中心各机房的存储设备中。通过数据传输，当地的待轧差数据在当地建立一个待轧差数据备份，形成一个轧差数据集。各地的轧差逻辑同时对当地的轧差数据集进行轧差运算，形成一份当地的轧差结果。该阶段充分利用当地的计算和存储资源，并发计算，减少每个轧差逻辑的运算负载，提高了运算速度。
各地轧差逻辑运算完成后，将当地的轧差数据上送到轧差结果平台，由集中轧差逻辑统一对各地域提交的数据进行合并运算，得出最终的轧差结果。
（五）支付管理系统应用
支付管理类系统数据流如图5所示。
图5 支付管理类系统数据流
管理员向三地的支付管理系统提交指令；接入层将支付指令发送给同地域的业务层系统，业务层系统进行相应的业务处理后，将数据操作指令发送给同地域的数据层服务；数据层服务对数据库进行读写操作，同时为了减轻数据库压力，主动将热点数据（如支付参数、session数据等）加载到缓存数据库，便于应用对热点数据更高效的取用；现有的业务系统可以从云平台进行支付参数等数据的查询。
（六）清算账户管理系统
清算系统在架构和应用层的设计上大体与核心业务系统相似，但笔者认为，数据库层在应用分库分表、读写分离等数据库技术的基础上，还可以采用“双写”策略来进一步提供数据的可靠性。在设计数据层时，首先根据一定的策略进行分库，如根据不同商业银行的类型（工农中建等）进行切分，降低单点并发。
在三个地域都正常工作的情况下，核心业务层的应用会将每家商业银行的账户数据，选择ABC三个地域内的其中两个进行同步写入和更新，即将两地的数据更新视为一个原子性操作，如果其中一个地域的数据库写入不成功，则将本次更新操作视为写入失败，并撤回在另一个地域上进行的写入操作。当且仅当两地的数据库都返回更新成功的消息时，才表明清算账户信息修改成功。数据层双写机制如图6所示。
图6 SAPS系统改造后的数据库“双写”机制
云平台会对三地数据库进行实时健康检查，并把检查结果发送给核心业务层的应用。如果发生城市级灾难或者主干光纤故障导致某个地域（假设为地域A）完全不可用，云管平台将会检测到系统故障，并将该地域的的业务流量迁移到其他地域（假设为地域B）。
同时，在地域B通过弹性伸缩技术临时扩大系统的计算能力以应对猛增的业务流量，保障核心业务的连续工作，且只对地域B的数据进行操作。直到故障排除，两地数据完全同步后，再转为“双写”策略。
（七）业务处理系统
该类系统是最主要的业务处理系统，如大小额、网银等核心支付系统。该类型系统面向商业银行和特许组织服务，每日的业务访问量大，对处理能力要求高。改造的基本思路是通过分割为无状态集群来规划部署，实现高容错、低耦合的弹性分布式架构，从而达到目标。下文将从架构概览、应用层设计和数据层设计等方面进行阐述。
1. 架构概览
业务处理类系统如图7所示。
图7 业务处理类系统
2. 应用层设计
笔者从软件架构和应用架构两个角度进行阐述。
（1）软件架构
软件架构采用横向和纵向切割的模式，对业务流程和业务功能进行梳理，将一个大的业务系统划分成独立的功能组件来部署，形成一个个微服务，降低系统间各功能之间的耦合度，降低各功能服务的维护成本，提高并行开发建设的效率。
以小额批量支付系统为例，可以将业务流程简化为如下功能服务：通信服务、报文检查服务、数据访问服务、风控服务、核心业务处理服务。
通过逻辑组件化、服务化，将复杂的系统分割成一个个只处理某单一逻辑的微服务，每个微服务可以独立开发、测试和部署。同时，每个微服务也可以集群部署，通过服务调用而组装成各种不同的业务功能。
（2）应用架构
整体应用架构采用集群方式达到性能和高可用性的提高，如图8所示。
图8 集群应用架构
在性能方面，通过集群将全国的业务流量分摊到各地数据中心，每个地域的系统只需要处理全部流程的1/3。随着业务的增加，数据中心和集群规模还可以不断扩展，形成三地六中心。如果六中心机房同时使用，每个机房的流程只是全国流量的1/6，如果每个机房中还有集群部署，假设每个机房至少有两套应用的集群，那么每套应用只需要处理全国流量的1/12。这种集群横向扩展的模式，可以降低单一系统的流量负载，提高整体系统集群的处理能力。
在高可用方面，由于集群中多个系统都能实时接管业务流，如果某个应用、某个机房，甚至某地域出现故障，可以通过健康检查机制及时发现，并将流量切换到其他可用区或地市的数据中心，让其应用集群维持业务的正常运转，平滑切换，从而提高了系统的高可用性。另外，这种基于地域的流量分流方式，也有利于缩短网络延迟。如图9所示。
图9 应用集群流量切换
3. 数据层设计
在数据架构上，首先采用“多地多中心”的多活架构。如图10所示，两地数据中心同时投入使用，以支撑多地的应用集群，提高系统处理能力和实现应用的高可用性。
图10 “一主三从”的分布式数据集群架构
在多地多中心架构的基础上，数据架构采用“一主三从”的数据集群模式，保证一定的数据冗余，提高数据的高可用性。“一主三从”是指通过成熟稳定的数据复制技术，保证每个主数据库在不同地方还有三个从数据库，三个从数据库分别在同一个机房中、同城另外一个可用区中和异地的一个可用区中。
如果主库出现故障，集群自动切换，同个机房的从库可以继续工作；如果整个机房都出现故障了，那么同城另外一个可用区的从库还可以发挥作用；如果发生比较极端的情况，整个城市两个可用区都出现故障了，那么异地的从库将继续工作，保证数据的可靠性，如图11所示。
图11 数据故障转移
在单个机房内，数据架构还采用分布式架构，通过使用成熟的分库分表组件，将单一数据库的压力分摊到多个数据库中。
在分析数据量的基础上，对数据进行合理拆分，平均分配数据量，最大化提高数据的并行处理效率。在业务数据分库策略上，分布式数据架构可以按收付款行进行数据的合理拆分，争取达到每个库的数据量均等。如对于小额批量支付系统，业务量较大的四大国有行各单独一个库，城商行一个库，使每个库的交易量基本相等，各个库的负载基本相同。
采用该分库策略，在空间维度上将数据拆分，平均分配数据量后，避免了单一数据库的数据访问压力。同时，按收付款行拆分的方式，有利于按银行归集数据，提高对账文件处理逻辑以及明细文件生成等逻辑的处理效率。
六、总结
央行支付系统举足轻重、影响重大，云计算在央行支付系统的应用面涉及甚广，在技术上如何选型，在众多技术细节上如何处理，在业务管理架构上如何适应性调整，诸多问题还有待细化和探索，本文的研究还有不足之处，应用研究任重道远。
