5.4 支付的技术架构
架构即未来，只有建立在技术架构设计良好的体系上，支付机构才能有美好的未来。如果支付的技术体系在架构上存在问题，那么就没有办法实现高可用性、高安全性、高效率和水平可扩展性。
总结多年来在海内外支付机构主持和参与过的技术架构设计经验，发现基于参考架构的分层架构设计方法，是一个行之有效的支付技术架构设计方法。本节将介绍如何利用分层架构设计的思想方法来构建支付的技术体系架构。
5.4.1 参考架构
所谓参考架构是一个或一组文档，为集成产品和服务形成解决方案而提供的参考性和建议性的架构。参考架构通过分层次，让不同的团队和架构师，分别聚焦自己负责层次的功能抽象和架构设计。
如果认真观察一下就可以发现，互联网技术行业一直采用的就是这种分层次的架构设计思路。例如，大家熟悉的互联网网络协议TCP/IP，就是以ISO OSI的分层次模型为基础发展起来的。大型的集成电路设计其实也是一层一层地分别进行设计，然后集成起来提供计算或者存储的能力。参考架构体现了行业通用的最佳实践，在最佳实践的基础上发展架构设计，可以最大程度地吸收成熟的经验和经过验证的模式。
今天的互联网已经遍布世界，但是在上个世纪的八十年代，不同的计算机网络之间开放互联还是一个战国时代。国际电信联盟和国际标准化组织为了能推动世界范围内的计算机网络开放互联，于1984年公布了ISO/IEC 7498-1标准[1]，这个ISO OSI标准为后来的互联网发展奠定了基础。
OSI的七层模型是一种框架性的设计方法。建立七层模型的主要目的是为解决异构网络互联的时候所遇到的兼容性问题，其最主要的功能就是帮助不同类型的主机实现数据传输。它的最大优点是将服务、接口和协议这三个概念明确地区分开，通过七个层次化的结构模型使不同系统、不同网络之间实现可靠的通讯。从做高层的分布式应用程序到跨越通信介质传输数据的物理实现，共分作七层定义，从上到下逐层依赖[2]：
第七层 应用层：
为了实现不同应用软件之间相互通信而设计的接口，例如HTTP、HTTPS、FTP、SSH、Telnet、SMTP、POP3等。
第六层 表示层：
对接受的数据进行加密、解密、解析等活动。表示层处理流经该结点的数据编码的表示方式问题，以保证一个系统的应用层发出的信息可以被另外一个系统的应用层读出。简而言之，就是把存在于计算机系统的不同格式的数据转化成网络通用的标准表示方式。
第五层 会话层：
通过传输层，即端口，建立数据传输的通路。会话层的主要功能是管理和协调不同主机上各种进程之间的通信或会话，及负责建立、管理和终止应用程序之间的会话。
第四层 传输层：
为上层协议提供端到端的可靠的、透明的数据传输服务，包括处理差错控制和流量控制等问题。
第三层 网络层：
解决如何使数据包通过各结点传送的问题。
第二层 链路层：
数据链路的建立、维护、拆除、指定拓扑结构并提供硬件寻址。
第一层 物理层：
提供传输数据的物理通路，传输数据。
这个开放网络互联的协议，实际上就是定义了一个参考架构，让所有试图连接网络的计算机有一个参考的标准框架。因为参考架构的分层，让每一层都能够聚焦解决一部分问题，实际上也降低了整个体系的复杂性。层和层之间的明确接口定义，也有效地避免了相互之间非必要的干扰。支付技术的架构设计也可以做类似的参考性架构，以此为基础做更详细的分层设计。
5.4.2 支付的参考架构
和上面讨论的ISO OSI开放互联参考架构一样，支付系统的参考架构也把复杂的支付应用分解成支付的前端应用、接入网关、业务应用、通用服务和基础设施五个层次。每个层次分别聚焦在某个特定的方向上，针对相关的功能集合进行思考和设计，最终通过层次之间的调用集成，形成统一的支付技术架构体系。
这么做的主要好处就在于每个层次可以聚焦本层次的核心功能，把一些复杂的其他操作交给其他层次来分别思考设计完成。另外，相同的功能可以归纳为通用服务，这不但可以确保整个系统服务的标准化和行为一致性，同时也提高了对支付技术架构的整体治理能力。支付的参考架构如下图所示：
对上图所示的支付技术体系参考架构的各层次作用和组成描述如下：
前端应用层：
iOS和Android App和Web应用。这部分主要是各种网络应用和移动App的开发，包括为商户便利支付业务完成而开发的收银台，为消费者便于支付而开发的各种电子钱包，以及为商户方便收单而在Android或者iOS上面开发的POS 机App等。
接入网关层：
API网关、金融系统和银行网关、商户接入网关等。对于支付机构而言，最为重要的接入网关是商户的应用接入网关，也就是商户为了完成支付而与支付机构进行的对接，用于传递商户向支付机构发送各种支付请求，以及商户用来接收支付机构返回的支付成功或者失败的结果通知。银行或者其他金融机构的网关接入是另外一个重要的组成部分。这部分主要负责对接银行或者其他金融机构机构，确保支付机构可以把收到的支付请求翻译成支付指令，然后转发给银行或者其他的金融机构，也包括接收银行或者其他金融机构返回的支付指令执行结果。
核心业务层：
客户、业管、费率、支付请求、算费、账户、账务、结算、对账、出款等。这部分是整个支付系统最为核心的部分。主要包括支付机构从商户接收支付请求，把支付请求转译为银行或者金融机构可以使用的支付指令，获取银行或者其他金融机构的支付结果并把支付处理的结果返回给商户。当然也包括支付请求完成后的算费和计费部分，还有支付机构与银行或者其他金融机构的对账，以及在此基础之上进行的结算和出款活动
通用服务层：
日志、数据、通知、鉴权、认证、GUID和风控等通用的基础服务。通用服务层，顾名思义就是包含支付系统的通用功能的应用或者服务，这些功能或者服务是其他应用的基础，广泛地使用在其他的应用中。例如，日志服务就是负责处理所有应用当中各种日志信息的服务。首先，把形形色色的应用日志信息按照规定的格式组合并输出；其次，对日志信息进行包括集合、统计和分析在内的各种处理。再次，根据统计分析的结果向前端提供流量控制和监控信息。
基础设施层：
网络、计算、存储、安全、域名和时间等基础服务。这个部分主要是为上面的几层应用和服务提供计算能力、存储能力和网络能力，也包含网络时间服务、域名解析额服务、数据库服务、数据备份服务以及灾难与恢复服务。基础设施层负责为上层的服务提供生产环境、集成环境、发布环境、性能测试环境、功能测试环境和演示环境，确保为不同目的而设置的各种应用环境能满足各种不同的需要。
在根据参考架构划分了支付技术架构的各个层次之后，就可以安排不同的架构师分别聚焦各自负责的层次，完成本层次的架构设计工作。在各个层次设计的结果上，通过集体讨论，确定各层次的设计目标、原则、接口和功能集合。然后进行进一步的高层设计和详细设计，直到最终完全实现所有的层。层和层之间的服务应该通过内部的服务水平协议来约束。
5.4.3 分层架构设计案例
根据前面的参考架构，负责通用服务层的架构师给出通用服务层所包含的通用基础服务，见下图通用服务层。图中抽象出的五个服务分别是：
CDS: 通用数据服务(Common Data Service)，把物理层的数据和逻辑层的数据隔离。
CKS: 通用密钥服务(Common Key Service)，负责管理各种安全密钥。
CNS: 通用通知服务(Common Notification Service)，发送邮件，SMS等各种通知。
CUS: 通用GUID服务(Common GUID Service)，负责发放具有全局唯一性的ID。
CAS: 通用日志服务(Common Applications Logging Service)负责处理日志信息。
架构师可以再进一步对每个通用服务做出更为具体的设计。这里以通用日志服务CAS为例，给出CAS的架构设计方案。CAS是所有应用都要使用的日志处理服务，因此具有足够的通用性存在于通用服务层。下面描述CAS的主要功能：
标准化日志信息结构
按照预先定义好的格式接收应用日志，确保所有的应用日志都遵循日志输出标准。避免不同应用产生各种不同格式的日志信息，造成后续日志处理困难。
生产者送日志信息入消息队列
定义生产者，把格式化好的数据放入消息队列，实现日志的异步化处理。避免应用日志海量输出造成局部I/O或者网络阻塞的问题。
消费者处理消息队列里的日志
从消息队列中取出日志，并按照处理规则进行深度处理，提升日志数据的价值。例如，一个应用发出的SQL语句，进行数据库相关的操作。从按照时间顺序线性产生的日志中，可以看到SQL语句执行的提交时间、返回时间、返回的数据以及执行结果的状态。消费者可以把提出SQL语句的时间和返回数据的时间进行比对和计算，从而得到SQL语句执行的时长。同时，可以根据历史上相同SQL语句执行的情况进行分析，从而得出该SQL语句在本次调用过程中的执行时长，按90百分位计算处在什么水平。让研发人员能够更直观地了解所调用服务的执行状况与结果。
对每个日志信息进行事件处理
对日志中输出的各种信息进行甄别，例如，对Information级别的日志信息，可以计数然后存储；对Critical级别的日志信息，要做具体分析和判别；对Exception级别的日志信息需要进行更深入的分析或者发出报警。
动态近实时统计数据
根据应用ID等关键词和标志对日志信息进行流式处理。利用类似Stream等工具做实时统计分析。可以为前端的熔断提供流量参考，也可以为支付关键业务的事实数据统计提供数据。
因此，CAS是一个非常有价值的通用服务，构建得好，不但可以标准化所有日志信息的格式，而且可以大幅度地提升应用日志的分析水平，以及对日志中各类应用和系统事件的管控，先于商户提前预警和处理，避免后患。因此，需要负责该层次的架构师能够认真思考，抽象、归纳和分析出有价值的设计关键点。下图展示了通用日志系统CAS的架构设计方案。
在CAS架构设计的基础之上，研发工程师们可以进一步完善和细化CAS的设计，进而得到CAS的详细设计方案，见下图所示。然后把该设计交给具体的研发人员，从而完成整个CAS的详细设计和代码实现。总结多年的技术架构设计与实施经验，很多支付机构的研发技术人员缺乏对所处理业务的总体认识和详细分析。本书将在《第6章 支付前的应用设计》中以与CAS类似的方式讨论支付核心业务层的架构设计。
5.5 支付的整体架构
下图展示了支付的整体架构。不同的支付机构可能会因为所聚焦业务的不同而有所差异，但是大体上应该差不多。基本上可以分成前面提到的五个层次。在设计上，增加了左侧的接入部分和右侧的运营管理平台两个部分。本节将基于这个支付系统的架构设计做稍微详细的介绍。
首先，前端部分包括Web、App、POS和电话IVR接入等各种不同形式的业务接入。可以根据业务发展的具体需要，通过标准化API和SDK，把这些应用接入到支付的主体系统。
其次，这个架构的左侧增加了银行接入、机构接入、合作伙伴接入、PSP接入和监管机构的接入。这个部分可以通过建立标准化的接入服务来实现。如果接入服务设计得好，不但可以提高接入的效率，还可以标准化支付请求处理的过程。
再次，右边增加了运营管理平台，这个平台主要是为支付机构内部的业务运营人员用来管理各项业务。例如签约、申请、审核、批准、开通、费率、对账、结算、出款等具体的操作和审核使用，也包括提供给商户用来查询支付请求的结果和结算报告的商户后台。
最后是中央部分的支付请求处理、账户、账务、计费、结算、出款等核心应用功能，以及最下层的日志、鉴权、认证、通知、ID、证书、密钥和数据处理服务。
其他的几个部分基本上和前面提出的参考架构所描述的层次相同，这里不再赘述。
5.5.1按照利益相关方划分的子系统
从上面对支付功能的分析与归纳可以看到，在支付的生态体系里，不同的利益相关方需要有不同的功能组合来对应。在现实的支付行业实践中，我们往往把这些功能按照所服务的对象以及该对象要管理的业务，组织并归纳成为11个子系统。而这些子系统的总合就构成了支付的总体系统。这11个子系统分别是：
（1）商户
商户收单子系统（店员收单用）：支付中，App或POS。
商户后台子系统（店主管理用）：支付后，商户用BOSS。
（2）消费者
电子钱包子系统（付款者支付用）：支付中，电子钱包App。
（3）监管机构
支付报告子系统（监管机构用）：支付后，反洗钱和打击恐怖融资。
（4）支付机构
支付处理子系统（核心）：支付中。
入网开通子系统（业务管理用）：支付前。
银行接入子系统（技术支持用）：支付前。
商户接入子系统（技术支持用）：支付前。
运营后台子系统（对账结算用）：支付后。
风险管理子系统（风控管理用）：支付中。
数据管理子系统（经营管理用）：支付后。
5.5.2按照支付流程划分的子系统
根据支付前、支付中和支付后三阶段划分的子系统如下：
（1）支付前
入网开通子系统（业务管理用）
银行接入子系统（技术支持用）
商户接入子系统（技术支持用）
（2）支付中
支付处理子系统（核心）
商户收单子系统（店员收单用）
电子钱包子系统（付款者支付用）
风险管理子系统（风控管理用）
（3）支付后
商户后台子系统（店主管理用）
运营后台子系统（对账结算用）
支付报告子系统（监管机构用）
数据管理子系统（经营管理用）
把支付技术体系的各个子系统按照利益相关方和在支付处理流程中的位置归纳如下：
支付前 | 支付中 | 支付后 | |
商户 | 商户收单子系统 | 商户后台子系统 | |
消费者 | 电子钱包子系统 | ||
支付机构 | 入网开通子系统 | 支付处理子系统 | 运营后台子系统 |
监管机构 | 支付报告子系统 | ||
表5.2 支付系统的子系统划分 | |||
5.6 本章小结
本章先描述了支付的生态体系，定义了该生态体系中参与支付活动的各个利益相关主体，并且分析了各个利益相关方在支付活动中的不同作用和诉求。在此基础上，以各个利益相关方为主，分类定义了与各个主体相对应的功能集合。接着，阐述并讨论了支付的技术体系所必须要具备的高可用性、高安全性、高效率和可扩展性四大技术要求。然后，推荐并讨论了用来指导和定义支付技术的架构设计的参考架构设计方法。并且结合具体的实践，深入介绍了如何利用参考架构的思维方法来定义支付架构。以通用服务层中的通用日志服务为例，介绍了构建支付技术架构的思考方法。最后，对支付技术的总体架构作出了定义，并且归纳罗列了支付技术架构应当配备的11个子系统。
本文摘自机械工业出版社出版的《一本书读懂支付》，经出版方授权发布
《一本书读懂支付》
让你成为首批彻底搞懂支付的人！支付领域标志性著作，支付领军人物在中、美、日等4国30年经验总结，中国银联执行副总裁力荐，360°解读支付。
优惠购书链接（6.5折）点击查看原文
可以加入技术琐话读者群，请后台回复：读者群
往期推荐：
-
今年这情况，大家多一手准备吧。。。
从管理1800人团队到退隐江湖，聊聊张雪峰
整理：开源LLM，可微调的项目列表
新书上市 | ChatGPT之父Sam Altman强推，国内首部顶级AI学者GPT原理解释之作
别纯技术视角想问题，论ToB的N种“死”法
AI，多赚了1000
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。
