支付架构以及支付实现方式是什么(支付架构以及支付实现方式包括),本文通过数据整理汇集了支付架构以及支付实现方式是什么(支付架构以及支付实现方式包括)相关信息，下面一起看看。

为了更好地支撑交易业务的快速发展，MaHoneycomb支付中心从最初仅支持基础支付和退款的“刀耕火种”阶段，经历了结构调整的“刮痧疗伤”阶段，完成了向实现综合产品平台形态的“沉淀蓄力”阶段的演进。

目前，蜂巢支付中心集成了包括基础订单、收银台、路线管理、支付通道、结算检查、对账单统计等多种能力。并为蜂巢度假(平台、定制)、交通(机票、火车票、用车)、酒店(开放平台、代理商)等近20条业务线提供服务。本文将简要介绍支付中心整体演进不同阶段的核心部分。

1.支付中心1.0开始的时候，是支付、退款和一些快速响应服务的基本需求。支付中心主要负责接入支付通道(支付宝、微信、连连等。)，并且各业务线实现收银，然后调用支付中心进行支付。系统、支付中心和第三方渠道的交互流程图如下：

系统交互过程如下：

商家将订单信息打包，请求支付中心的支付中心对订单信息进行简单处理，然后将支付信息请求添加到第三方支付通道。第三方支付通道将支付结果异步回调到支付中心的支付中心，第三方响应的数据经过简单处理后同步通知到所有业务系统进行逻辑处理、用户通知和页面跳转。业务发展初期，业务量较小，交易场景相对简单。这种设计可以快速响应业务需求，实现功能。然而，随着服务越来越复杂，连接的服务越来越多，这种架构似乎已经不够用了。各业务条线需要重复开发部分功能，支付中心不具备整体管控能力，开发维护成本不断增加。主要问题包括：

维护成本高：各业务线需要单独维护出纳，调用支付系统完成支付。要保证幂等性、安全性等容灾性差。分别是：所有功能都集中在一个大模块里，某个功能出了问题，直接影响到结构的不合理。结构单一，无法满足复杂业务场景的要求。出纳维护收款方式和部分业务路线，缺乏统一管控。为了兼顾快速发展业务的需求响应和系统的高可用性，保证了在线服务。

二。支付中心的2.02.0架构将各种业务的公共交易、支付和财务存放到支付中心，主要解决以下三个主要问题：

建立统一的基础订单、支付、金融体系，抽象封装共同的处理逻辑，形成统一的基础服务，降低业务的接入成本和重复R&D成本；构建安全、稳定、可扩展的系统，为业务快速发展和创新需求提供基础支撑，解决业务“快”和支付“稳”的矛盾；沉淀核心交易数据，为用户、商家、金融提供大数据支撑。2.1核心能力支付中心2.0是整个交易系统快速发展的重要时期。在这个过程中，不仅要升级架构，还要保证服务的稳定性。

目前，支付中心为业务提供的主要能力包括：

支付平台：用户可以使用微信、支付宝等第三方平台进行快捷支付：用户提供银行卡信息，进行便捷支付协议支付：授权后，用户可以在不中断用户体验的情况下进行便捷支付和信用支付：用户可以使用柏华等分期产品在境外进行透支支付；用户可以选择境外支付渠道，对境外产品进行线下支付；用户可以在特定场景下选择ToB渠道进行支付。根据蜂窝业务的特点，目前支持的核心交易场景包括：

支付和退款：适用于普通商品的购买和退款。拆分支付：适用于限额或金额较大的场景下的单笔支付：适用于保险账户被划分为不同收款账户的场景。2.2在架构设计的演进过程中，第一步是将相对独立的网关模块化，网关是统一系统的基础。支付网关抽象出支付、退款、查询的标准请求，然后在网关的基础上逐步梳理支付通道，逐步提取基本订单模块，将业务功能与支付功能解耦，支持复杂的业务场景。目前，系统功能的总体结构如下：

如图所示，从架构上主要分为三个层次：

* *产品层：* *结合核心层提供的支付能力，为终端用户提供收银，为运营财务人员提供运营财务系统* *核心层：* *支付中心核心模块，包括基础订单、支付路线、支付渠道等。* *支持层：* *用于支持整个系统的基础设施，包括监控和报警、日志、消息队列等。2.2.1产品层产品层主要包括本文重点介绍的收银设计思路。

收银员由H5收银员和PC收银员组成：

移动端：

PC端：

如上图所示，收银主要由订单基本信息(包括订单号和付款金额)、订单明细(包括日期信息、商品信息和基本信息)和付款方式(平台支付、信用支付等)三部分组成。).

由于收银台是用户进入整个支付中心的唯一入口，所以用户体验和安全性非常重要。同时，为了支持个性化的业务和用户一致的体验，收银主要通过定制和配置来实现。对于商科学生来说，访问也很简单，只需通过订单号跳转到收银页面，后续流程将由支付中心完成。

用户下单后会到达收银台页面，收银台会通过订单所属的业务线、支付金额、订单是否合并等信息显示可用的支付渠道。同时，风控系统会对产品、订单、用户行为等维度进行监控，屏蔽高风险支付渠道。当支付通道出现故障时，可以在收银台暂停显示。

(1)定制

为了支持收银下各业务线不同模式和显示的特点统一，采用工厂继承的模式实现各业务数据和显示风格。收银台的主要属性分为展示模块和通道路由，其中具有重复和默认功能的模块以模板的形式由抽象类实现，子类可以使用默认方法或覆盖父方法定制。display cashier实现类实现了一个默认的cashier，它包含了大部分必要的组件(比如倒计时、表头定制、订单明细等。).一般来说，每个业务线只需添加一个特定的实现类(2)配置，就可以生成一个清晰丰富的页面。

出纳配置主要是根据每笔业务的属性(业务类型、类别等)来配置后续的操作。)，如：

基于后端路由，收银显示层被区别对待。用户可以看到的渠道列表(微信、支付宝等。)，以及分拣、打顶、打标等。满足不同场景的要求，不同的业务以相同的支付方式收款到不同的收款账户。根据不同的场景，采用不同的结算方式和结算渠道，这是2.2.2核心支付中心中的核心模块，包括基础订单、支付路线、支付渠道等。

基础订单系统是连接交易业务线、支付中心和结算系统的桥梁，实现了业务与支付结算的解耦。主要涵盖业务创建订单、关闭订单、支付、退款、回拨通知等API模块。基础数据支持普通缴费、单笔缴费、拆分缴费、保险缴费等场景的缴费功能。各系统的交互过程如下：

目前，基本订单系统可以支持以下两种特殊场景：

(1)一个订单对多个商品

一个基本订单可以包含N个商品(商品信息包括商品名称、商品ID、单价、数量、折扣等。订单信息包括用户UID、手机号、支付金额、订单折扣等汇总基础信息。)，N个商品对应M个业务子订单(MN)。如果所有业务子订单的业务类型相同，则为正常模式；否则，它们处于捆绑模式；每笔业务订单对应一个对账单元素(付款成功后付款信息会同步到对账系统)，一单VS多商品的创建模式基本支持当前所有场景，包括未来可能出现的购物车模式。

(2)一个订单与多个支付订单

普通订单用户选择支付宝、微信等渠道生成支付订单；当金额超过5000元时，可以选择拆分订单金额进行付款，然后会生成多张付款单；如果下单时勾选了保险，则由第三方赔付，会生成两个赔付单；同时，拆分支付也会导致用户部分支付或超额支付，监控会自动退还异常支付；大额订单转化率提升10%以上，一单VS多单支付的模式更好的支撑了马蜂窝的支付场景。

渠道管理渠道路由主要包括两个方面，一是服务端需要控制支付渠道，二是支付端需要选择支付账户。

(1)支付账户管理

在创建支付指令和处理回拨的过程中，需要根据业务类型、支付方式和支付渠道确定支付账号。在早期版本中，这种对应关系是通过配置文件来维护的。一个业务类型对应多个配置项，每个新业务需要添加多个配置。随着更多支付渠道的接入，新业务需要配置的信息越来越多，维护难度大。

优化后，将已有的配置对应关系放入数据库，数据表按业务类型、支付方式、支付渠道唯一确定一个收款账号，支付账号的具体参数信息仍放入文件配置中。创建订单时，根据业务类型、支付方式、支付渠道查询收款账号，将账户信息记录在支付订单数据表中，回拨时直接从订单表中查询支付账号。

(2)支付渠道管理

目前接入支付宝、支付宝国际、微信、JD.com支付、applepay、连连支付、银联2B等第三方渠道每个渠道下都有多个支付产品。第三方渠道的界面形式千差万别，但都提供订购、退款、查询、支付通知、账单下载等标准功能。支付中心对这些支付通道进行一次封装，使用一个抽象类作为基类，使用模板方法设计模式，在基类中定义一个标准流程，具体在通道各自的实现类中实现。一个类只需要关心基类的公共方法，与具体的通道无关。

2.2.3支撑层支撑层包括监控报警、日志管理、签名检查、配置管理、消息总线等模块。日志由ELK收集和管理，系统配置由公司自主开发的分布式配置中心管理，消息总线由公司二次打包的RabbitMQ分发和消费。

由于支付系统对可用性和支付数据的敏感性要求很高，支付中心独立实现了监控和报警系统。下面将详细描述该监控和报警系统的功能和设计思想。

为了保证监控系统的实时性和有效性，监控所依赖的资源如数据库等必须与业务库隔离(避免鸡蛋放在同一个篮子里)。支付监控系统涵盖API监控、服务性能监控、数据库监控等。并能提供统一的报警、分析和故障排除能力。从异常数据采集到主动故障发现和稳定性趋势分析，为支付系统优化提供数据支持。

(1)监控背景

背景主要

接口监控可以针对固定host IP 绑定以及设置超时时间，监控请求支持GET、POST 两种方式，POST 方式可以设置固定请求参数辅助，监控频率支持分钟、秒两种级别配置；响应数据模块可以校验HTTP code 是否异常，配置响应数据类型，比较检测返回key 值，针对DB 监控还可以设置DB 查询超时时间；报警模块目前支持短信和邮件两种方式，可以设置最小、最大报警阈值，超过最大阈值每隔最大报警数会触发一次报警，规避了故障期间短信轰炸问题。

（2）监控核心

为了实现最快监控频率10 秒，同时可以支持成千上万的监控项并行运行，支付监控采用了多进程管理的方式。父进程创建指定数量的子进程，每个子进程完成固定数量的监控任务退出任务，此时父进程实时监控子进程状态并创建新的子进程执行任务；父进程还可以接受外部信号完成服务重启以及停止，流程如下：

（3）监控报警

执行监控项会根据监控配置进行接口请求以及返回数据分析处理，然后通过Redis 计数方式按报警策略进行报警通知。日常监控短信示例：

2.3 实践经验（1）数据一致性

上文提到，我们采用模块化的方式来解耦业务功能与支付功能。在这个过程中，每引入一个模块就会涉及到系统交互问题，因此最核心的便是数据一致性问题。针对数据一致性问题需要引入事务，实时、延迟校验以及补偿机制保证数据的最终一致性。从架构看是很清晰的，但是对于整个改造过程是艰难的，犹如给飞行的飞机更换发动机，所以我们也把这个过程形容为一个刮骨疗伤的阶段。

（2）稳定性

支付服务都是由第三方支付通道提供的，支付通道存在不稳定性。比如用户用支付宝支付了一笔订单，由于各种原因，支付中心没有收到支付成功的通知，用户又用微信再次付款，导致重复支付。

为了解决这个问题，支付中心采用定时扫描的策略，主动发现重复支付单并自动执行退款，不需要人工参与。退款流程中，退款单需要经过申请、审核、调用退款接口等流程，在调接口环节，可能会发生失败。调用失败的退款单，会根据退避算法发起重试，逐渐加大重试间隔，直到次数超过限制。失败单数量超过阈值、或者有订单处于失败时间超过阈值时会触发报警。自动处理不了的退款单可以人工检测，或线下退款。

三、总结展望目前，马蜂窝支付中心已经具备支持多业务、多场景、多支付方式的能力，但想要实现一个真正意义上「百花齐放」的平台，还有很多地方需要改进和完善。

即将到来的支付中心3.0 将以微服务的思想把单体应用按照业务进行解耦，会逐渐从一个高耦合的单一系统演变为众多子系统组成的高并发、高可用、支持更多交易支付场景的分布式系统。微服务化拆分后，在系统结构上将更加清晰，但对于整体系统的开发管理和维护也将带来更大的挑战。

更多支付架构以及支付实现方式是什么(支付架构以及支付实现方式包括)相关信息请关注本站，本文仅仅做为展示！