E缴通V2概要设计文档

1. 项目背景

平台需要完成的功能主要是2个大类：会员网上缴款，商户收款。同时需要具备比较高的扩展能力，以供后期对接不同的支付渠道接入，和商户接入。

2. 业务架构

针对整个平台，在业务上需要完成如下的几个目标：

1. 具备一个订单模块用于管理订单相关的数据，并且完成订单清算和资金核算
2. 具备一个用户模块用于管理用户相关数据并实现与用户相关的所有逻辑。包含登录和信用体现。
3. 具备一个商户模块用于管理商户相关的数据并实现商户，账户相关的逻辑。
4. 具备一个产品模块用于管理产品信息和校验信息。
5. 具备一个运营模块用于针对整个平台的业务进行实时分析和离线的汇总统计报表。
6. 具备一个渠道模块，用于解析和生成不同支付渠道的报文。接口系统中其他模块相关渠道相关的工作。
7. 具备一个收银台模块，作为用户的支付代理，完成所有相关的支付代理操作。
8. 具备一个会员中心，让会员可以查询自己的订单情况。
9. 具备一个商户中心，让商户可以查询订单，运营情况。并且管理自身的账户信息。
10. 具备一个权限中心，用于解耦各个模块当中权限相关的操作。

为了完成业务需求目标,针对系统应当具备的功能进行识别分析并且模块化后，可以得到如下的业务架构。

在业务模块区分清晰的情况下，平台主要完成2类支付动作：网关支付和无跳转支付。一个完整的支付流程动作，会涉及到多个业务模块的配合。可以参考下面的支付时序。

2.1 网关支付

网关支付的时序如下图所示：

2.2 无跳转支付

无跳转支付的流程如下如所示：

3. 技术架构

为了支撑这样的业务模块划分，系统采用分布式的服务化思路来构建。具体到技术架构，实现如下

架构的基本思路如下
1. 将业务中能否满足独立自洽原则的部分抽象为一个独立的服务。服务有其内聚于功能边界内的数据存储，缓存。服务外部的对服务的调用只能通过RPC进行。
2. 将业务架构中基本的三个基本的数据来源抽象为3个服务：订单服务，会员服务，商户服务。这三个基本服务本身的数据没有耦合关系。并且三个服务都是数据的原始来源。
3. 业务需求需要一个运营中心来获得实时数据分析和离线的报表统计。因此抽象出一个服务专门处理此类请求，命名为统计分析服务（以下简称分析服务）。分析服务的数据来源于三个基本服务。但是服务的数据边界规定了不能直接获取其他服务的数据。因此分析服务和三个基本服务之间通过消息总线的方式进行数据共享。三个基本在生产数据的时候会将对应的数据推送到消息总线上。而分析服务则订阅其中自己感兴趣的内容。通过这种方式，分析服务就可以从三个基本服务中获得自己需要的数据。
4. 通过将支付渠道相关报文功能的剥离，可以抽象出一个渠道服务。该服务不产生不消费数据，单纯作为一种处理手段存在。可以解耦所有和支付报文相关的工作。
5. 对于各个不同的服务接口，本身是不具备权限这种概念。但是对于上层的应用而言，却需要这样的功能。因此将权限认证作为一个单独的服务抽象。用于提供所有和权限相关的认证工作。
6. 基础的服务能力构架完成之后就可以开始扩展上层应用，也就是业务应用。所有的业务应用本质上都是内聚的业务包装，以及对底层服务的混排调用。