首页 > 其他分享 >大厂聚合支付系统架构演进(上)

大厂聚合支付系统架构演进(上)

时间:2024-02-06 23:32:32浏览次数:38  
标签:网关 架构 演进 系统 业务 大厂 支付 交易

0 前言

聚合支付主要是就是一个将所有的第三方支付,通过借助形式融合在一起,相当于对接一个支付接口,就可以使用各种支付的场景。如便利店购物,贴个码,上有微信支付,支付宝等各种支付。

大厂聚合支付系统架构演进(上)_系统架构

它主要是针对一个微小商户进行一个收款工具,让商家他那边会有一个收钱吧商户通,第一个可以实时的收听语音报告,当前用户付款多少钱,第二个就是他可以去实时查看账单,了解当天营业额。

还有一个产品就是pos机,主要是一款生态 pos,它里面不仅继承了我们一个我们这个具备支付系统提供的服务,就比如微信支付宝,它们还集成了一个刷卡的功能,就是磁条卡芯片卡,还有各种支付方式。本文聚合支付只涉及交易流,不涉及资金流。

1 V1.0系统

  • 工期短
    基本上所有新项目都这尿性,天天被领导鞭策赶进度
  • 业务不熟
    不知道聚合支付到底做啥的,支付流程啥样?毕竟每个公司支付业务其实完全不一样,无法照搬!
  • 交易量小
    当时的交易量是只有前端的一两个产品在使用,每天的交易笔数也很小
  • 人员缺乏
    新成立的团队做新项目研发,那就只有我和另一十年老鸟同事

该背景下完成 V1.0系统架构,即虚线圈,具体分工:

  • 交易前置
  • 交易网关

直接操作 DB 没做甚至缓存的优化。

大厂聚合支付系统架构演进(上)_数据_02

  • 交易前置:支付核心业务处理,如记录商户交易流水、对接各个支撑服务
  • 风控系统:交易单日/单笔限额、商户黑名单、欺诈行为识别等风险因素控制
  • 路由系统:通过设定的优先级、限额等路由规则,选择合适的渠道,保证成功率,降低成本
  • 交易网关:负责所有支付渠道的报文包装、数据加密、协议转换、签名验证、状态映射

当时就做这样简单架构,第一个开发比较快,直接拿需求进行改代码,方便测试以及上线。经几个月交易猛增,发现

2 系统瓶颈

2.1 渠道隔离

当时对接了几个渠道,特别渠道不稳定的话,如资源不可用、网络问题,导致超时,就会把所有渠道交易全部影响,级联反应导致交易链路雪崩。系统哪边挂了之后立马要赶紧联系。所以说这个渠道隔离放在第一位首要的。

2.2 接口膨胀

特别涉及相似业务的,如消费、撤销、退款接口,就每个业务类型都有这几个接口,随业务发展,也难维护,开发每次来个需求都考虑到底是改哪个接口,要不要都改。

2.3 动态扩容

聚合支付很多交易异步,用户下单时,我们会立即返回就下单成功,或者下单失败,但是这个交易有没有消费成功,我们需要设置定时的任务去查询最终付款结果。

2.4 定时调度

它需定时、定点、定量拉取订单处理,如拉取数据太多OOM,太少很多交易得不到执行。分布式下如何充分提升并发前提下充分使用机器资源变紧迫。

2.5 配置分散

传统将配置文件存放在每个节点,每次升级都要运维手动改。风险高且不好维护。

3 V2.0系统

3.1 设计方向

  • 稳定:支付系统的根基
  • 支付体验:用户使用支付功能时感知零延迟
  • 低耦合:模块间减少依赖,需求变动风险控制在最小范围

过程试了多种方案,最终演变如下系统架构:

大厂聚合支付系统架构演进(上)_系统架构_03

首先将服务划分三条线,绿色和中间红色和最下面一条橙色:

  • 绿色是把交易核心、交易网关独立出来
  • 任务作业和那个查询网关独立部署
  • 两条业务线通过 MQ 解耦
  • 再独立查询服务,对前端业务仅提供一个流水查询功能

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都国企技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:

  • 中央/分销预订系统性能优化
  • 活动&优惠券等营销中台建设
  • 交易平台及数据中台等架构和开发设计

目前主攻降低软件复杂性设计、构建高可用系统方向。

参考:

标签:网关,架构,演进,系统,业务,大厂,支付,交易
From: https://blog.51cto.com/JavaEdge/9632811

相关文章

  • 一文快速了解微服务架构
    服务提供者按照一定格式的服务描述,向注册中心注册服务,声明自己能够提供哪些服务及服务的地址是什么,完成服务发布。服务消费者请求注册中心,查询所需要调用服务的地址,然后以约定的通信协议向服务提供者发起请求,得到请求结果后再按照约定的协议解析结果。在服务的调用过程中,服务的请求......
  • 单元化架构基本设计
    单元化架构基本设计关于架构分层的一些显著定义AccessLayer面向App客户端公网访问。ComputingLayer内网所有无状态的计算模块集合StorageLayer所有存储的集合关于单元化的一些显著定义单元(Set)单元的划分可以是任何维度,比如电商对的买家用户维度。单元对的......
  • 读《凤凰架构》感悟
    本书提供了一个完整的网站代码,网站名字是:凤凰书店。该网站是一个网上卖书的站点。类似于互联网最早期的亚马逊书城、当当网。一个传统的互联网网站。值得关注的是该书提供的不仅仅是勉强把这个网站实现出来的代码,而是用非常好的标准和风格实现了,并且实现了5套,让读者观察5套网站代......
  • 分层架构
    分层架构(layeredarchitecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。虽然没有明确约定,软件一定要分成多少层,但是四层的结构......
  • 微核架构
    微核架构(microkernelarchitecture)又称为"插件架构"(plug-inarchitecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。 优点良好的功能延......
  • 事件驱动架构
    事件(event)是状态发生变化时,软件发出的通知。事件驱动架构(event-drivenarchitecture)就是通过事件进行通信的软件架构。它分成四个部分。 事件队列(eventqueue):接收事件的入口分发器(eventmediator):将不同的事件分发到不同的业务逻辑单元事件通道(eventchannel):分发器与处理......
  • 微服务架构
    微服务架构(microservicesarchitecture)是服务导向架构(service-orientedarchitecture,缩写SOA)的升级。每一个服务就是一个独立的部署单元(separatelydeployedunit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。  微服务架构分成三种实现模式。RE......
  • 云架构
    云结构(cloudarchitecture)主要解决扩展性和并发的问题,是最容易扩展的架构。它的高扩展性,主要原因是没使用中央数据库,而是把数据都复制到内存中,变成可复制的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessingunit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元......
  • SDN关键技术及架构
    SDN是软件定义网络的简称,在SDN中,网络的控制面与数据面分离,并且通过中心控制器进行统一管理。SDN的主要目标是提高网络的灵活性、可编程性和智能化程度,从而更好地适应不断变化的业务需求。SDN可以通过控制器来管理网络设备,控制网络流量和优化网络服务质量。SDN还可以使网络更加安全......
  • 金融行业多端支付系统强一致性架构设计(下)
    2支付能力的快速接入支付快速接入:设计流程主要目标:屏蔽接入第三方支付平台的复杂度,为业务提供便捷接入的支付的能力。整体交互逻辑:用户下单后,业务线生成生订单的同时请求支付系统,返回携带加密后的收银台链接,业务前端渲染收银台H5链接,之后用户操作都直接与支付系统直接交互,不再经过......