【支付架构】支付运营平台设计

目录

1 支付运营平台的作用

1.1 支付运营平台简介

1.2 支付运营平台发展历程

2 支付运营平台业务逻辑

2.1 用户群体分析

2.2 业务架构

3 支付运营平台设计

3.1 设计原则

3.2 系统架构

3.2.1 系统交互设计

3.2.2 权限模型设计

3.3.3 支付运营平台技术架构

4 总结

---

1 支付运营平台的作用

1.1 支付运营平台简介

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

1.2 支付运营平台发展历程

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

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

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

2 支付运营平台业务逻辑

2.1 用户群体分析

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

岗位	需求	体验目标
支付开发、测试、产品	日常值班问题排查，交易、商户信息查询，查看自身系统数据是否正常。	信息查询易操作，易排查问题。
客服人员	查询交易信息、查询商户信息，查询费用信息等，以处理客户问题。	信息查询快速响应，根据提供的少量信息能查出客户所需的信息，信息呈现清晰易浏览。
运营人员	合规安全保证，权限分配。	权限分配易操作，易维护。
清结算人员	对账结果查看，差错处理，调账。	信息准确有效，操作安全。
财务人员	营收情况统计，会计核算。	信息准确有效，易操作。
风控人员	风控策略配置，风控信息查询。	易操作，易查询。

2.2 业务架构

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

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

3 支付运营平台设计

3.1 设计原则

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

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

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

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

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

3.2 系统架构

3.2.1 系统交互设计

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

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

3.2.2 权限模型设计

运营平台无法绕开权限的管理，权限管理是运营平台非常核心的一个模块，一般情况下会专门设计一个权限系统，提供SDK让包括运营平台在内的内部服务系统接入使用。建议使用RBAC模型来设计权限系统。在《最全的权限系统设计》（地址：https://blog.csdn.net/u010482601/article/details/104989532）那篇文章中详细讲解了权限模型的设计，可以从中挑选一个模型来使用，这里不再赘述。

3.3.3 支付运营平台技术架构

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

4 总结

本文介绍了支付运营平台的系统发展历程，并给出了比较理想的系统设计模型。做支付的小伙伴都非常清楚支付运营平台的重要性，以及对性能，安全的要求。可以用本介绍的模型对比自己公司的运营平台是否有能改进的地方，也欢迎留言一起讨论。