总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 互联网后端架构 「互联网后端架构」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

1 支付运营平台的作用

1.1 支付运营平台简介

支付运营平台是提供给支付公司内部员工使用的，用来查交易信息，商户信息，费率信息等的内部服务工具。使用的群体有支付开发人员、测试人员、支付产品人员、清结算人员、财务人员、客服人员等。开发、测试以及产品人员需要使用平台处理值班问题，及时查询数据，监控服务。清结算人员使用平台处理对账以及调账等问题。客服人员使用平台查询交易信息、商户信息以第一时间反馈给咨询的客户。虽然运营平台不在支付体系的主链路上，但是作用绝对不容小觑，任何一家支付公司都离不开支付运营服务。

1.2 支付运营平台发展历程

支付公司单量比较小的时候，支付各个模块都融合在一个系统，因为一个系统能搞定收单、清结算、账务、商户管理等所有的事情。运营平台相当于支付系统的一个后台管理平台，通过该平台维护商户信息、查询交易数据等能力。这时候的支付运营平台提供管理页面，一套SpringMVC框架就搞定，可以直接请求支付系统的数据库对可操作的数据进行增删改查。此时的架构如下所示：

图片

但是随着支付公司业务量的增长，一个支付系统处理所有事情的局限性慢慢凸显出来。首先是耦合性太强，无法灵活扩展，其次是系统性能遇到了瓶颈。这时候迫使要把支付系统按照业务模块拆分成各个子系统，以提升可扩展性和容错能力，比如负责业务逻辑处理的拆分成收单系统，负责结算的拆分成清结算系统，负责记账的拆分成账务系统，负责商户信息管理的拆分成商户系统。系统拆分完成之后也并不能解决性能的问题，因为性能的瓶颈会凸显在数据库，所以需要把数据库也根据子系统来拆分。拆分之后的支付体系架构如下所示：

图片

按照这个架构拆分之后运营平台就会面临各种各样的问题，首先是跨数据源操作数据的问题，其次是安全合规性问题，即是否可以通过运营平台直接操作数据库修改数据。这时候就涉及到如何把运营平台设计的可用性更高一些。

2 支付运营平台业务逻辑

2.1 用户群体分析

技术是为业务服务的，要设计一套高可用的产品，一定要把业务逻辑梳理清楚，梳理业务逻辑首先要理清不同用户群体对产品的需求。支付运营平台的用户群体前面已经讲过，这里我们详细介绍一下这些用户群体对平台的需求。

图片

2.2 业务架构

用户群体的需求梳理清楚之后，需要整理运营平台的业务架构，作为支付运营平台，需要给不同的客户群体提供业务支撑，复杂度相对来说也是比较高的，尤其是需要到不同系统汇总数据、修改数据的情况。支付运营平台的业务架构如下所示：

图片

使用运营平台的人员通过页面查看订单数据、商户信息，并操作相关的数据。运营平台需要到支付的各个业务系统去获取数据，展示数据，并修改数据。

3 支付运营平台设计

3.1 设计原则

运营平台作为给内部员工服务的平台，视觉上没有特别的要求，不需要给太多的视觉冲击。但是对易用性、易学性、安全性等方面要求都是比较高的。

易用性：内部员工使用，操作上要尽可能的简便，不能给太多复杂的操作，要尽可能的节省操作成本。比如客服查询问题的页面要尽可能的简单易懂，输入尽可能少的内容能够得到尽可能多的信息。

易学性：考虑到公司人员流动以及新系统培训的成本，设计的系统要尽可能一目了然，不需要太多的学习成本，尽量能够做到看了操作手册就能上手。不然新招一个客服人员培训很长时间才能上岗，成本非常的高。

安全性：运营平台设计的数据有的是非常隐私的，比如商户的营业执照，法人信息，交易信息这些都是要保密的，所以安全一定要把控好。数据的隔离，数据操作的审批都要严格把控好。

高效率：使用运营平台是为了解决问题，客服人员回复顾客的问题效率也是一个很重要的指标，所以给出的查询、操作一定快速的相应，不能半天查不出数据，或者修改不了商户的费率。

3.2 系统架构

3.2.1 系统交互设计

运营平台的数据来源是支付各个业务系统，考虑到安全、合规等问题运营平台不能直接操作业务系统的数据库，需要通过接口来获取和操作数据。为了扩展性更好一些，一般系统都会做到前后端分离。支付运营平台的交互模式如下所示

图片

支付运营平台前后端分离之后，后端相当于一个业务路由系统，负责整合转发、整合前端数据，判断请求哪个业务系统，并把业务系统的数据返回给前端。

3.2.2 权限模型设计

运营平台无法绕开权限的管理，权限管理是运营平台非常核心的一个模块，一般情况下会专门设计一个权限系统，提供SDK让包括运营平台在内的内部服务系统接入使用。建议使用RBAC模型来设计权限系统。

3.3.3 支付运营平台技术架构

业务逻辑和交互模式梳理清楚之后，我们就可以设计出一套通用的技术架构来支撑支付运营平台。考虑到安全性，所有的操作需要留存操作记录，并且需要接入安全中心，页面也需要打水印以防止截图到处乱发。考虑到易操作性，需要提供统一的审批流程，权限申请流程等。支付运营平台系统架构如下所示：

图片

文章目录
  1. 1. 1 支付运营平台的作用
    1. 1.1. 1.1 支付运营平台简介
    2. 1.2. 1.2 支付运营平台发展历程
  2. 2. 2 支付运营平台业务逻辑
    1. 2.1. 2.1 用户群体分析
    2. 2.2. 2.2 业务架构
  3. 3. 3 支付运营平台设计
    1. 3.1. 3.1 设计原则
    2. 3.2. 3.2 系统架构
      1. 3.2.1. 3.2.1 系统交互设计
      2. 3.2.2. 3.2.2 权限模型设计
      3. 3.2.3. 3.3.3 支付运营平台技术架构