支付运营平台架构设计

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

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