银行支付系统SOA架构演进及运用探讨分析

字数 4767阅读 3833评论 0赞 1

# 1.概述

随着银行改革的深入进行和技术创新，SOA架构体系在银行系统建设中被不断使用和推广，推动着使用者不断追求更高体验的银行业务服务，银行已经在加快从产品销售角色向综合服务提供角色的转变。支付系统作为银行实现资金流转控制的重要信息系统，将在银行转型过程中承担起最重要的职责：支付服务和支付能力。越来越多的银行根据自身情况已经在探索或制定或实施支付系统的重新构建，以满足使用者对服务体验的要求。

如何实现从产品到服务的支付系统全新构架，最大限度地满足使用者的需求，本文针对SOA架构在支付系统中演进和运用进行了探讨和分析。

**关键字：SOA架构、支付系统、支付服务、支付能力，业务场景**

# 2.从支付产品到支付服务体验

2015年4G网络正式在中国普及，微信、支付宝、Apple Pay等互联网支付平台已经发展出差异化支付体验，如：支付宝的刷脸支付、微信红包、微信转账、Apple Pay的便捷支付等，后续又衍生出各类使用场景的电子钱包和余额宝。当互联网交易模式如火如荼快速发展的时候，众多银行却还在坐等观望，认为互联网支付平台不具有存款账户载体，最终的资金流向还是各储蓄银行。

在今日中国的互联网支付能够做到及时付款、及时转账和即时到账，不再需要实体介质做为载体和使用到签名。虽然这些互联网服务都是需要绑定银行账户或银行卡（包括信用卡）进行消费，但这些都属于服务提供公司和银行之间的网络内部活动。在此基础上又发展出个人和商户的应用群体、消费和退款的消费方式、延迟商户到账的付款方式等使用场景。

这种发展趋势，支付的未来发展样貌已经十分清晰：在消费平台之间即时又顺畅地完成支付行为，不需要实体介质做为有效支付载具，并将网络效应和场景使用发挥到极致。因为使用者的行为场景衍生出业务场景，网络效应能够最大程度增强支付的功能和服务，使用者也能够得到更好的、更便捷的服务体验、提出新的服务要求，从而推动和促进银行业发展出更为便捷化的服务和更丰富的体验环境。

未来的支付无可避免的会向丰富的体验环境、低标准的使用障碍和进一步降低对实体载体的依赖，中国人民银行目前正在试点的数字货币和数字货币钱包就是这种发展趋势的最有利的证明。SOA/软件架构设计应运而生，应用新的架构技术能够更契合银行的服务与功能。

# 3.SOA/软件架构演进创建系统架构

## 3.1 建立支付构架目标

支付系统架构设计主要解决：快速迭代、业务标准化、易维护性、高质量性、高稳定性、可持续扩展性等。系统架构的目标是：标准化、支付能力化、交易场景化。这将会成为支付系统未来发展的主要方向和趋势。

标准化：是指在经济、技术、科学和管理等社会实践中，对重复性的事物和概念，通过制订、发布和实施标准达到统一，以获得最佳秩序和社会效益。支付系统中的标准化不仅是流程的标准化、处理方式标准化，还必须实现业务场景的标准化，设计出属于自己的表转化业务场景。

支付能力：支付能力原则要求按照纳税人的负担能力来分担税收，能力不同者负担不同的税收。但对于银行业金融机构而言支付能力是能够为客户提供快速、安全、精准的支付服务，并且能够根据不同的业务场景丰富支付业务数据为大数据分析提供数据基础。

交易场景化：随着消费金融市场蓬勃发展和电商互联网技术的不断升级，金融服务与生活场景逐步走向无缝衔接。支付系统交易场景化是支撑业务标准化、支付能力的基础，是支付系统快速应对变化的市场需求、客户化要求的价值核心。

## 3.2架构演进方向

虽然SOA架构体系实现了技术异构性、弹性、扩展、简化部署、与结织结构相匹配、可组合性和对可替代性的优化等七项优势，但不足之处同样明显：

1）SOA架构并没有抽象化业务场景，没有细化业务场景分类；

2）SOA架构是包容化的，但并没有实现最小维度的组合化原子功能；

3）演进后的支付系统架构是去模块化和自包含，细分业务场景分解服务、业务流程，最终实现功能原子化为目的，而SOA架构是自包含和模块化的。

4）虽然都是为了满足于松散耦合、可重用的服务、服务接口设计管理、标准化的服务、支持各种消息模式和精确定义的服务契约，但不具备灵活的服务扩展和服务能力化特点。

支付系统架构设计中最重要的一环是业务场景如何划分和切割。业务场景顾名思义：是业务环境中可能发生的一组情况的概述。支付系统的业务场景较为特殊，主要分成两类：一是监管或清算中心业务规则和技术标准（固定规则）；二是面向外部接入使用系统或者客户化业务场景（可变规则）。固定规则：因其受外界业务场景制约因素影响较小，受监管调整而调整，可以视为不变规则进行场景管理。可变规则：面向外部接入使用系统或面向客户化的使用场景，其变化速度受新技术投入使用、生存生活环境变化以及使用者认知水平、文化程度和接受能力的影响，需进行动态化场景管控。

考虑到支付系统的独特特点（支付系统不直接面对银行客户提供支付产品或服务）不应该再将面向对象化架构思维融入到架构中。支付系统向外提供的服务和能力，在架构设计的过程中需要考虑如何将业务场景从众多的交易中剥离出来进行抽象，转化为支付服务和支付能力，因此相面抽象的架构设计思路更加适合于支付系统。为了弥补SOA架构的不足之处，在架构设计时需要将服务按照不同的运营场景不断拆分和分解为最小功能原子，以此解决SOA架构中大块业务逻辑和着重中央管理的不足，因此提出SOA架构的一种演进可能。架构如下图所示。
![](/home/attachment/202103/08/1220553_161516701090780.png)
![](/home/attachment/202103/08/1220553_161516703512487.png)

支付服务系统架构（以下简称支付架构）分为四层，从上到下分别为：服务提供层、交易流程层、交易节点层和原子化功能层。整体架构思路的出发点是按照交易场景和交易处理方式将交易以WBS分解的方式进行逐层细化分解，最终分解为最小工作包即原子功能或原子能力。例如：大额系统行号的管理可拆解为他行行号状态变更控制、行名行号变更控制、变更生效期控制、行名行号查询同步等。业务场景的分类和细化也在该层完成。例如：贷记业务普通汇兑业务场景包含大额录入、小额录入、网上跨行支付清算录入、城银清录入、银联贷记录入、大额复核、小额复核、大额授权通过、小额授权不通过等。

交易节点层顾名思义：交易流程中的控制节点。此层的主要用途为按照业务场景组合原子化功能层中的各种原子功能，将之聚合为交易流程中的一个交易控制节点。此交易节点可以根据不同业务场景的变化进行修改或者新增。其中业务场景是根据原子化功能层中的业务场景进行的第一次场景逻辑抽象。

交易流程层也叫业务逻辑层，将交易节点层的各节点按照业务场景进行整合、归并，形成交易完整的处理流程。其中的业务场景是根据交易节点层中的业务场景进行的第二次逻辑抽象。

服务提供层：为外部接入系统或接入使用方提供标准的服务接口数据标准，规范通信端口治理，制定标准通信规则。该层级结构还能直接将服务转化为开放式能力，对外提供支付能力外输，为银行走向开放式银行提供发展方向。该层还可以将微服务设计纳入其中，实现SOA架构与微服务架构的优势互补。

## 3.3架构优势

**在实施过程中具备以下几大优点：**

1）实施效率：当一个原子功能发生变化时不会因为是公共的方式影响到其他的交易流程或服务。又因为该架构的核心基础是以原子功能做为基点进行拼接，能够在不扩大影响范围的情况下快速完成实施工作。弥补了SOA架构的不足。

2）范围（需求边界控制）：任何项目最大的问题在于需求范围和边界的制定与控制。项目失败的大多数原因就是范围控制出现问题。该架构最大的特点就是范围可控，因为所有的需求都将在实施前转化为具体的原子交易或功能节点，都需要明确适用的业务场景，如此不会再出现范围表述不清难以控制的问题。

3）质量控制：系统实施或维护最大的问题就是质量控制问题。质量控制上最大的问题就是对需求的理解偏差；对影响分析遗漏；对整体结构或架构不熟悉等。实施人员不需要再花费更多的注意力去考虑设计是否符合架构标准，只需要再完全熟悉业务需求后完成积木拼装即可。因此实施过程中的质量控制问题将不再是困扰项目或系统实施的最大问题。

4）部署方式的不同（部署方式的可扩展）：该架构在开始设计之初就考虑到了技术快速发展，可能出现部署方式以追求更安全、更稳定为目标（部署方式可能发生改变）。该架构可以在软件层面上支持多种中间键或消息队列，可以根据监管的安全标准或应用技术要求进行快速更换；能够支持服务与应用分离，或使用微服务或采用容器技术；能够将单一应用快速分离成多应用分布式部署，能够支持数据库分布式部署；不存在因技术方式发生变化出现应用无法支撑新硬件技术的瓶颈限制（除非系统的技术语言全面落后，或出现更先进的开发集成框架）。

## 3.4架构不足

该架构最大的不足就是它最大的优势：化繁为简。如何化繁为简取决于项目的管理者、系统的实施者、后期的系统运营管理人员和维护开发人员；取决于他们对业务场景的认知程度；取决于他们如何划分业务场景，对业务场景的理解；取决于他们对于分解颗粒度的一致性，是越细越好还是只分解到一定程度（颗粒度较粗）即可；取决于他们对业务流程的理解一致性；取决于系统开发公司业务专家的参与程度或银行内部业务专家的能力程度；取决于项目组成员的持续高效沟通，因一旦出现沟通冲突该项目将很难再持续高效的推动或执行。对于以上该架构的不足而言都能够通过提前制定系统建设目标、项目建设计划、制定项目沟通计划、制定项目章程和参与人员绩效考核的项目管理方法和软件工程学方法来进行有效控制和解决。

该架构的不足将会突显在应用该架构的项目建设初期（还未投入使用前），系统全面交互投产进行运营后，随着整体项目组人员的共同成长，该劣势也将会以线性递减的方式快速减弱但并不会消失。

# 4.对未来发展的展望

该架构不仅能够适用于支付系统，对于银行内部其他的业务系统而言均可以进行运用，系统架构设计不再受限制于业务层级的影响。并且能够将业务架构直接融入进系统应用架构设计中，更进一步的实现业务架构与应用架构的融合；能够做到系统应用架构以业务架构为基础；统一全行的应用系统架构设计规范，减少运维成本和实施成本投入，增大创新投入；统一全行开发平台，真正做到中小银行研发自助可控；打破了中台对银行目前发展的制约，将产品化推向面向最终用户的服务化体验，提高银行的服务创新能力；解决中小银行面临的系统架构设计混乱和系统运维管理凌乱的困境，实现中小银行从一套系统一个架构发展为真正的企业级架构，助力中小银行对系统应用架构的应用和管理的跨越式发展；对银行数字化转型发展过程中运用区块链、大数据、云平台和容器等技术提供了基础技术演进框架和数据标准化治理的基础。

# 5.结语

随着市场不断的深入话发展，支付系统将成为银行越来越不可替代的核心系统，甚至重要性将超越核心业务系统，因为核心业务系统本身不会存在业务场景，存在业务场景的系统又不具备支付服务能力，如何考虑建设支付系统对于银行业的发展和影响将成为中国各银行越来越重要且频繁讨论的议题。每家银行都会从自身情况提出对未来支付系统发展的构想，以及创新化的架构方案，但就支付系统本身而言是无法做到科技引领业务发展的，因为它只是人们生活中必须具备的工具，如何更好的更方便的使用工具将需要科技和业务密切配合，最终的使用选择权在我们的最终使用客户手中。实践是检验真理的唯一标准。

银行支付系统 SOA 支付系统业务场景

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

银行支付系统SOA架构演进及运用探讨分析

添加新评论0 条评论

作者其他文章

相关文章

相关问题