《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 支付运营平台技术架构