免备案网站怎么收录,网络推广方式主要有,兰州画册设计,福州高端建站5.4 支付的技术架构 架构即未来#xff0c;只有建立在技术架构设计良好的体系上#xff0c;支付机构才能有美好的未来。如果支付的技术体系在架构上存在问题#xff0c;那么就没有办法实现高可用性、高安全性、高效率和水平可扩展性。 总结多年来在海内外支付机构主持和参与… 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 技术琐话 以分布式设计、架构、体系思想为基础兼论研发相关的点点滴滴不限于代码、质量体系和研发管理。
