处于不同发展阶段的企业，支付系统的定位和架构有所不同。 总体而言，我们可以将企业支付系统的发展分为三个阶段：

支付系统：支付作为一个（封闭的）、独立的应用系统，为各个系统提供支付功能支持。 一般来说，这个系统仅限于为公司内部业务提供支付支持，与业务耦合紧密。

支付服务：支付作为一个发达的系统，为公司内外部系统及各项业务提供支付服务。 支付服务本身应该与具体业务解耦。

支付平台：支付是一个可扩展的平台，公司内外用户可以在上面定制和开发自己的服务。

这个划分有点牵强。 简单来说，支付系统仅供内部使用，支付服务可供公司内部和外部调用，并且可以基于服务定制支付平台以支持各种场景。

1、支付系统架构

1、支付业务流程

区分两个概念：支付和交易。 付款是交易的一部分。 一个简单的交易流程包括：顾客下单、顾客完成支付、商家收到订单、商家发货。 这里只考虑下订单的过程。 从软件工程的角度来看，我们首先需要确定接下来的几个参与者。

现在我们已经有了主角，下面是如何上演和支付这部剧的费用。 正常的流程应该是这样的：

1、用户向电商系统提交订单，电商系统审核订单。 如果没有问题，则激活支付接口进行支付。 注意这里的支付接口是在服务器端调用的。 一般来说，支付接口很少是由客户端直接调用的。 出于安全考虑，支付接口一般都需要访问并签名接口。 关于支付接口的设计，我会在单独的博文中介绍。

2、支付系统检查参数的有效性，特别是签名的有效性。

3. 根据用户选择的支付方式和系统支付路由设置，选择合适的收单机构。 这里涉及到三个概念，支付方式和支付路由。 这是另一个缺点。 简单来说，用户可以选择用各种银行卡进行支付，比如微信银行卡，但是你的支付系统没有接入微信银行。 对于此类卡，您可以选择您已连接并支持该卡的收单机构执行支付。 ，例如使用微信、支付宝等第三方支付，或者使用云闪付支付等系统支持的方式。 这就是支付路由，它根据用户提供的银行卡选择合适的收单机构来执行支付。 常见的支付方式还包括第三方支付，比如微信、支付宝等，这种情况下不需要支付路由。

4. 调用收单接口进行支付。 这是支付系统的核心。 每个公司的收单界面都不同。 连接一两个收单机构就可以了。 但如果数量较多，如何统一这些接口就是一个设计难点。

5. 支付成功，收单机构将款项转入商户账户。 商家准备发货。 如何发货不是本文的重点。 这里主要关心的一点是，商家能收到多少钱？ 例如，价值100元的产品，用户支付了100元（不含运费、折扣等）。 只有扣除电商系统的佣金和支付渠道的手续费后，这100元才能最终落到商家手中。 。

这是一个过程。 一切看起来很美好，但实际上每一步都充满陷阱。 一旦考虑不周全，可能会频繁掉单，或者接口被盗刷，损失惨重。

如何防止攻击者修改支付接口参数，比如将100元的商品改为10元？

调用收单接口进行最终实际支付时，如果支付失败，比如卡上没有钱，怎么办？

收单接口已从账户中扣款，但通知支付系统时出现错误（例如网络中断、支付系统重启）。 支付系统并不知道交易已经完成。 怎么处理呢？

还有很多疑问...

在任何一家公司，处理金钱的事情，都逃不开财务部门。 那么财务部门会关注什么？ 当然，最重要的是会计信息。 所有的交易都必须有账，并且公司需要定期进行审计，以确保每一笔账目都必须没有错误。 当然，这要等到审核之后才能查到。 相反，需要每天对账目进行核对，以确保所有交易费用都被抵消，这就是所谓的平衡账目。 分为三种情况：电商系统与商户对账； 电子商务系统与支付系统之间的对账； 支付系统和收单机构之间的对账。 作为支付系统，我们只关注后两种情况。

从软件开发的角度来看，仍然有一些非功能性需求需要实现：

2. 典型的支付结构

所以在支付方面还是存在很多陷阱的。 我们先来看看顶级互联网玩家是如何设计支付系统的？ 我们先来看看某组：

我们来看某Q旅游公司：

将此与一些金融服务进行比较：

最后我们来看看业界最强的金融服务公司：

总体而言，从分层角度来看，支付系统与普通业务系统没有本质区别。 又分为应用、服务、接口、引擎、存储等。在应用层，支付系统一般提供以下子系统：

其他图层功能：

支付服务层：为上述各端系统提供API。 这些API也可以提供给业务系统直接使用。

接口层：与各种相关系统接口的接口，其中最重要的是与支付通道接口的支付网关。

引擎层：包括后台运行的统计分析、风控、反洗钱、信用评估等系统。

存储层：各种持久化数据库支持。

这其实就是一个普通的互联网应用系统架构，没有什么特别之处。 例如，微服务是如何体现的、如何满足性能需求的，就无法在这个视图中体现出来。 这只是从软件角度来看的高级视图。 稍后我们将分解各个主要模块。 从分解的角度来看，我们可以知道如何满足非功能性需求。

2、支付系统监控报警

关于监控，在各个技术网站上几乎都有大量的搜索。 几家大型互联网公司也开发了自己的监控系统。 关于这方面有很多共享。 这里我们介绍支付系统的监控和报警，但大部分内容应该是其他系统通用的。

现在基本上已经成为监控的标准了。 传统的监控实现是部署在被监控机器上，从日志中收集所需数据，分析监控指标，并发送给服务器。 ！ 这种方式监控需要在每台机器上部署客户端并配置数据采集脚本。 部署时可以随操作系统安装所需的软件。

1、系统监控

先说比较简单的系统监控。 一般来说，系统监控主要关注以下指标：

这些指标将提供默认实现，并且可以通过简单的配置来激活。 您可以考虑在安装时统一配置这些监视器。

2.JVM监控

JMX 提供了有关 JVM 的大部分核心信息。 可以在启动时设置参数，支持远程访问JMX。 然后就可以访问JMX来实时读取JVM的CPU、内存等信息。 还支持通过JMX获取信息。

3. 服务监控

服务监控主要是指接口的状态监控。 服务监控重点关注以下指标：

4. 数据库监控

数据库是大多数应用的核心和瓶颈，对其监控尤为必要。 监控可以在应用程序端进行，也可以在数据库服务器上进行。 前者是通过在应用代码中打印日志来实现的，或者直接连接池中的相关方法来统一输出日志。 要对数据库服务器进行监控，需要根据数据库的特点设计方案。 例如，您可以通过监控其bin日志来获取执行的SQL语句和执行时间。 用于连接，收到消息后，解析消息数据，可以获取请求的SQL、参数、执行时间、错误码等信息。