Medo Payment Architecture Design

一、背景

希望通过自己落地实践一个项目，总结学习技术并培养产品思想。以支付系统做案例，一方面结合业务落地技术实践，另一方面实践微服务架构平台。

项目假设

• 五个人的研发团队，三个后端工程师、两个前端工程师

• 没有测试人员（所以更加需要研发编写相关单元测试代码）

• 首先保证项目上线，暂时支持微信、支付宝两个渠道，对账和结算功能先不考虑

• 功能稳定后，维护平台基础功能

• 拥有基本能力后，实现对账、结算功能



多租户（多商户场景）

支付渠道支持三方应用模式，商户自助在 medo 平台注册并授权支付渠道支付功能，后续交易直接操作商户帐号。

二、需求

项目致力于聚合支付，现阶段需要支持支付宝支付、微信支付两种支付渠道。包括线下支付、线上支付两种场景，线下场景支持静态码、动态码、B 扫 C 三种支付方式，线上应用支付动态码支付。



• 平台线下到支付渠道开放 API 平台申请平台帐号，用作系统支付收款主账户

1. 静态码

• 管理员通过系统生成静态码，打印制作支付二维码，商户张贴二维码供用户扫码支付。

• 用户打开支付渠道客户端扫描静态码，客户端跳出系统定义支付金额输入页面，输入需要支付的金额，点击确认，唤醒客户端支付确认密码页面，用户输入密码确认支付，支付完成。

2. 动态码

• 收银员通过收款系统输入商品金额生成有时效的动态码，并给用户展示动态码

• 用户打开客户端扫描动态码，跳出密码输入页面，进行支付

3. B 扫 C

• 用户打开支付渠道客户端，展示付款码

• 收银员使用扫码枪，扫描付款码，进行支付

4. 退款

• 用户支付后对部分商品不满意到售后柜台要求退款，售后确认后通知收款柜台对订单进行退款操作

• 收银员收入订单号及退款商品金额，进行退款操作

5. 对账与结算

• 系统每天从支付渠道下载、查询前日支付、退款记录

• 根据订单号匹配对比每一笔交易，看其金额、状态是否一致，是否存在查询不到的订单

• 对于匹配成功的订单针对每个商户生成结算记录，并对相应的支付渠道生成结算文件

• 记录匹配失败的订单，提供扎账功能

6. 支付商户管理

• 系统管理人员需要维护商户信息，包括商户基本信息、商户门店信息、门店终端信息

• 系统管理人员通过打印从系统生成下载的二微码（静态码）交由商户在门店处张贴

7. 线上支付&应用内支付



8. 商户注册

• 支付商户需要在支付渠道注册才能进行支付，商户信息用作结算依据

三、事件风暴

TODO

四、用例模型





五、部署模型



说明：

• 服务部署到 k8s 中，由 k8s 平台提供基础的服务发现、负载均衡及配置中心功能

• MySQL 采用一主两从部署

• KAFKA 部署两台集群

• Redis 采用集群部署两台

• 应用服务器各部署两个实例保证服务的可用性

六、组件模型

Merchant Service



Payment Service



Account Service



User Center

TODO

通用用户管理中心，管理平台登录、权限管理

七、类图



MerchantServiceClass



Payment





活动图

时序图



状态图

Payment 订单状态图



关键技术点



支付渠道扩展策略



为适应不同的并发情况，设计两种部署策略。

1. 一、最终支付渠道的调用由 Payment 项目发起

2. 二、各支付渠道做为微服务独立部署，Payment 对 Channel Service 发起 rest 请求或者发送支付事件



各个支付渠道的对接都以 Gradle 模块的形式，抽象定义 ChannelClient 接口类，该类中描述各支付渠道需要实现的功能，支付渠道实现类实现该接口适配该支付渠道 api。



方式一渠道扩展路由策略：

• 只部署 Payment 一个微服务项目，依赖支付渠道实现的 Spring Bean

• 定义 ChannelRouter 类，根据 Channel Id 配置路由规则，通过 Spring 依赖查找获取具体的实现类实例，完成调用。

• 后续扩展支付渠道需要新增支付渠道实现模块，修改路由规则，并在 Payment 中添加依赖,重新部署 Payment 项目来扩展。

方式二渠道扩展路由策略：

• Payment 及各个支付渠道都作为微服务应用部署，Payment 依赖支付渠道服务提供的功能

• 添加 ChannelService 模块，定义通用 REST API 路由，各支付渠道策略模块依赖该模块，实现通用 API 路由维护

• 

参考



参考项目