一、支付系统的简介
什么是支付系统？自古以来，所有的商业活动都会伴随着经济的收款与付款行为。随着时代的发展，记录收付款行为的方式不断迭代：古代的钱庄通过手工（算盘）记账，工业社会通过收银机机械记账……
如今，互联网/移动互联网时代，我们的商业行为也一同进行了数字化与信息化的演变，这就是所谓的电子商务。
支付系统伴随着电子商务的发展而出现，它为各类电子商务经营活动实现在线收付款交易以及管理交易资金等功能，获得支付牌照的第三方支付公司可以参与资金的核算及存管，简单说就是可以在合法期限、合法范围内挪用资金。是具有一定独立性的内部系统模块----很多公司称之为中台。
二、支付行业发展的前世今生
亿欧网上一篇中国支付行业发展史里的图片，既形象又简洁的代表了支付行业发展的前世今生：
而近代的支付行业发展史，可简单描述为以下几个时代：
第一个是现金时代
第二个是刷卡时代
第三个是二维码时代
第四个是刷脸时代
三、互联网支付系统架构
以小编之前在第三方支付公司工作的经历来说，有幸参与了公司从0到1搭建支付系统（重构）的过程。完整熟悉了支付行业生态及产品业务，基于微服务分布式全新搭建的一套支付系统。查看另一篇文章，小编在支付公司的经历：
3.1 技术栈：
- Java
- SpringBoot/SpringCloud
- MyBatis
- Redis
- Kafka
- swagger2
- ELK
- Maven
3.2 设计原则
- 分而治之
- 微服务化：根据业务功能、不同的性能需求等将系统划分为多个微服务，每个微服务独立开发、独立部署、独立运行，拥有独立的数据库存储，各个微服务之间使用接口通信，不允许跨微服务访问数据库。
- 服务分层：支付系统系统的微服务按照在业务处理流程中的地位以及后续功能变更频率分为公共服务层、基础业务服务层、基础支撑服务层。
- 业务与平台分离：业务系统（包括公司的业务系统和商户系统）与平台从开发到部署完全分离，尤其需要强调的是公司的业务系统与公司在部署上也需分离，例如部分特殊的业务可部署在阿里云。
- 前后端分离：所有包含界面的子系统遵循该原则，后端负责提供基础的业务服务接口，前端负责展示界面的逻辑（前端包括客户端的JS、后续可能的APP界面以及部署在服务端的负责根据界面展示需求聚合请求的Node.js等）。
- 动静分离：静态资源和动态请求分离开发和部署，静态资源后期可考虑上CDN。
- 业务驱动设计：
- 处理流程不强行抽象：例如支付服务的不同支付方式的处理流程如果存在较大不同，则内部处理逻辑不强行抽象，避免各个环节均在判断的情况。
- 接口不强行抽象，根据业务适度抽象定义接口，避免大而全的接口出现
- 注重非功能性质量要求：
- 性能：避免不必要的性能损耗，合适的追求性能提升
- 异步优于同步，示例如下：
- 如果微服务A的业务处理过程中，需要驱动微服务B进行相关处理，但是并不依赖微服务B的处理结果，则使用异步消息机制，避免各个微服务之间产生不必要的性能耦合；例如清算服务异步通知支付服务清算结果，账务系统驱动会计系统执行会计分录等。
- 对上游渠道的通知处理，仅完成必要的处理后即返回，保证对上游渠道系统的友好性
- 不追求强一致性，保证最终一致性
- 微服务间同步调用采用HTTP协议，不使用二进制协议，保证数据交互的良好可读性
- 异步优于同步，示例如下：
- 可用性：充分考虑各种情况
- 所有服务均采用集群+业务调用无状态化
- 自动降级、限流
- 性能：避免不必要的性能损耗，合适的追求性能提升
3. 安全性
3.3 架构逻辑
系统整体采用微服务架构，各个微服务独立开发、独立部署、独立运行、拥有独立的数据库，各个微服务之间接口进行通信，不共享任何文件、数据。
系统逻辑上分为产品应用层、接入层，公共服务层、基础业务服务层和基础支撑服务层五层，外加跨各层的运维支撑的系统，如下图所示。
四、支付产品
支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力，基础支付产品分类如下：
- 账户产品：企业账户服务（充值、提现、转账等） 集团账户（分级管理、资金调拨等）
- 基础收款产品：代收代付、分账、分润等
- 基础付款产品：批量付款、委托结算等
互联网支付产品，结合支付场景和流程，产品的主要应用和分类又分为如下所示：
详细可查看移动支付网一篇较为经典的文章，既介绍了支付产品的业务和场景，支付系统的架构，又把几个典型的互联网电子商务公司的支付系统整体架构图罗列和讲解了一番，非常值得推荐：
互联网支付系统整体架构详解
1287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
