基于微服务架构的开放卡券销售平台构建

马欢 符为伟

(交通银行信用卡中心，上海 200000)

0 引言

随着微信、支付宝等互联网金融行业的兴起，其对银行的传统支付业务造成了极大的冲击。互联网服务提供商依托其掌握的大量的生活场景、水电煤账单缴费、各种会员卡券的充值及销售等，结合自身的支付能力，构成了完整的业务闭环。传统的银行支付工具(如信用卡)，面临着严重的脱媒风险而沦为支付工具。

银行纷纷推出自己的APP产品，除了包括常规的金融服务，还包括大量生活服务，借此构建完整的业务链条，与互联网金融平台进行正面竞争。

作为专业的金融机构，银行通常不会直接建设这类非主营的生活服务类业务，而是通过整合外部供应商以丰富APP的服务能力。基于此，本文介绍一个基于微服务架构的开放卡券销售平台构建案例，实现敏捷快速的外部服务能力转化，助力银行业务发展。

1 外部服务能力转化面临的挑战

银行APP在整合外部供应商的各种服务能力时，不可避免地要进行内外部系统之间的集成和互操作，常见做法是：由外部供应商提供各类服务能力API的接口，在银行内部建设若干个独立的业务系统集成这些生活服务能力和本行的金融支付能力。该模式面临以下挑战。

1.1 建设速度慢

针对每一个新的生活场景和供应商，都可能需要建设对应的业务系统。从达成商务合作意向后开始进行系统建设，设计、开发、测试的一系列流程通常都需要3个月以上的周期，新业务难以快速投入运营。

1.2 建设成本高

针对每个场景建设的新系统，设计开发、测试的人力成本，各种安全、性能的检测成本，以及系统建成配置的运维成本，使得整体成本高企、投资回报率低。

1.3 配置不灵活

各种场景的重复建设以及赶工期等因素，使得每个场景的业务系统产品成熟度不高，大量的配置信息被硬编码。在产品的运营过程中，一些业务变化都需要重新开发升级系统，这个过程不仅耗时，还极易造成各类功能、性能、安全的缺陷，影响业务开展。

为了应对上述挑战，本文探讨构建一个统一的开放卡券销售平台，通过该平台承接各种外部卡券销售类服务，通过少量的配置和调试工作，迅速将外部第三方的服务能力落地转化为银行的服务能力。

2 开放平台技术的发展趋势

2.1 开放银行

现代商业银行的发展历程大致可以分为以下三个阶段：

(1)线下发展阶段。该阶段完全聚焦于金融业务，以网点的方式进行业务拓展。这种模式下存在的是资金、人力和运营成本之间的矛盾。

(2)线上发展阶段。互联网兴起后，银行业务逐渐线上化，互联网的无界性极大地化解了之前实体网点模式的挑战，但仍以金融业务为主。

(3)互联网金融阶段。在该阶段面临互联网金融的挑战，存在与客户脱离的风险。为了化解这一危机，银行业开始思考银行和各种非银机构的跨界融合，实现以银行为主体的银行生态重构，这个概念被称为“开放银行”，目前头部大型银行都已经构建了自己的开放银行体系。

2.2 开放平台

实现开放银行，从业务方向可以分为两种类型：一种是银行“走出去”，把自己的金融服务API产品化，由其他第三方把银行的金融服务整合在自己的服务场景中，用户无须到银行即可享受金融服务；另一种是“引进来”，即以银行为中心，将各种客户需要的非银服务能力纳入银行的服务体系，让用户在银行的APP中即可体验各种便捷的生活服务。

针对这两种业务模式，都需要开放平台予以技术支持，才能够实现业务规模化发展。对外金融能力服务输出的模式，需要把金融服务API化，然后通过API超市和开放银行网关平台对外发布自己的服务能力，由第三方商户去构建集成金融服务的服务场景。而对内引入各种场景服务能力的模式，同样需要避免每次一对一的大量重复系统开发建设，要有统一开放平台承接各种外部服务，将其迅速落地转化为银行的服务能力。后者即本文探讨的主要内容。

3 开发平台开发的主要技术

构建统一的开放平台主要涉及微服务和云计算平台两方面的技术。

3.1 微服务

微服务是基于SOA(面向服务的架构)的一种用于构建应用系统的架构解决方案。通过微服务的方式，可以实现松散耦合的分布式架构。

一个应用系统可以由多个微服务组成。例如，一个传统的在线商城系统，所有的商品展示、搜索、用户、下单等功能都是一个服务程序，经过微服务改造，可以把系统拆分为商品中心、用户中心、订单中心等几个微服务模块，各个微服务独立部署，联合组成整个商城系统。

这种架构的优势是可以独立部署每个微服务，有自己的应用服务器和数据库服务等资源。一个微服务的更改不会破坏整个应用系统，每个微服务都可以作为一个成熟的组件模块，快速用于搭建新的应用，以满足不断变化的业务需求。

3.2 云计算平台

云计算平台也称云平台，是指基于硬件资源和软件资源的服务，提供计算、网络和存储功能。相比传统服务器的管理方式，基于云的管理方式可以把企业中与自己主营业务无关的IT基础运营解放出来，只需要向云服务提供商按需购买自己的计算和存储能力即可。云服务提供商可以把所有的计算和存储资源池化管理，按租户提供给多个用户，确保在高质量服务的基础上实现更低的运营成本。

根据集中管理的程度，云计算平台通常分为基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。在IaaS模式下，云平台仅提供安装好操作系统、具备网络能力的虚拟机，用户有很高的自由度，但对用户的技术要求也很高。在PaaS模式下，云平台会安装好常见的中间件软件，用户只要负责专注开发自己的应用程序即可。在SaaS模式下，云平台直接提供各种标准应用服务，如客户管理服务、财务服务等，SaaS的用户仅需通过一些配置操作即可满足自己的需求。

4 开放卡券平台的架构设计

为解决引入大量第三方服务商时面临的各种挑战，本文探讨一种基于微服务的开放权益平台。新签约的服务商户只需经过简单的配置调试和验证，即可快速投入生产运营。

4.1 整体介绍

图1展示了组成开放平台的微服务组件，以及开放平台在组织内部和其他微服务以及外部商户服务之间的关系。基于微服务的模式，无须从零做起，组织中现存的微服务组件可以直接用于新平台的构建。本次新平台的构建用到的微服务包括用户中心、订单中心、风控中心等。

4.1.1 用户中心微服务

用户微服务提供用户的注册、登录、登录日志查询、修改密码等与用户相关的操作。组织中的任何对外服务，都可以通过整合用户微服务实现一户畅通。

4.1.2 订单中心微服务

终端用户和组织的所有交易行为，均通过订单微服务进行集中管理。该微服务不提供图形用户界面(GUI)，全部通过API的方式与其他各个业务系统进行交互，具体包括下订单、已购订单列表、待支付订单列表等API功能。

4.1.3 风控中心微服务

终端用户购买的行为数据都会传递到风控中心，包括用户的信息、购买的商品信息、频率、频次、价格等，通过在风控中心设置的风险控制策略，可以对购买行为进行阻断或报警。

为了实现开放平台的能力，本次新开发了5个微服务组件，分别为：内容与商品服务、交易服务、订单服务、运营服务和充值路由服务。

开放平台中的卡券充值服务，都是在用户支付后由合作方商户在线发放，这个过程不可避免地涉及平台和外部权益提供商户的在线实时交互，平台和外部的交互全部由微服务通过接出网关和第三方商户对接。

所有的微服务均部署在PaaS云平台上，每个微服务都有自己独立的容器，可以按需进行扩展部署，并彼此进行隔离以减少相互的影响。

4.2 平台微服务介绍

从上面的整体介绍可以看出，新的系统构建不再是简单地把所有的功能设计实现在一个大的服务中，也没有将系统功能简单地分为用户端、运营端等几个部分，而是根据可复用、易扩展的原则拆分为多个微服务。为了实现开放平台的核心功能，本次新构建开放平台的几个微服务能力，如图2所示。

4.2.1 内容和商品微服务

用于展示面向用户的商户、商品、服务、活动、广告、公告等信息，每个新的商户上线后，即可生成自己的商户首页，该首页面向终端用户，用户可以进行查看及选购商品和服务。

4.2.2 交易微服务

交易微服务用户在选购好商品和服务后的支付过程，完成权益平台和订单中心之间的交互，包括终端用户下单过程的订单确认页、支付结果页、订单详情页等用户界面，以及系统之间交互的下单、订单查询等API。交易微服务和前述的内容和商品微服务共同完成了用户客户端的功能。

4.2.3 充值路由微服务

充值路由微服务主要完成整个系统和外部商户之间的充值权益的实时获取交互操作。此处也是开放平台中每个新商户上线需要进行代码级别调试和验证的环节，但是任何新商户的投产都不会影响存量已投产的商户功能，各个商户之间实现隔离，每次开发只关注第三方接口的联调，代码开发量大幅下降，极大地提升了业务需求投产的时效。

4.2.4 运营微服务

运营微服务主要完成系统级的项配置工作，以及新商户服务权益的各项配置能力。考虑到运营端的工作用户数量有限、工作负债很低，故运营端功能全部设计在一个微服务内实现，包括以下管理能力：

(1)商户管理包括新建商户，商户审核，商户查询，商户信息的修改、删除、停权、恢复启用，审核历史等功能。

(2)商品管理提供每家商户可售商品或服务的管理能力，具体包括商品的新建、批量上传导入、商品审核、商品详情展示、商品上架、商品下架、渠道价格等功能。

(3)品牌管理主要完成整个系统的品牌、一级类目、二级类目等新增、修改、删除，以及审核、审核日志查询等功能。

(4)广告管理完成开放权益平台广告位的查询、新增、修改、启用、禁用、送审、审核、审核日志查询等功能。

(5)公告管理功能完成开放权益平台公告信息的新建、删除、列表查询、详情查询、送审、审核等功能。

(6)审核管理功能完成开放权益平台各项配置活动的审核操作，所有培训功能的新建、删除和修改，必须经过送审、审核等功能后才能生效。

(7)订单管理主要完成系统的订单查询功能、可以支持商户、用户、品牌、商品、日期、品类、订单金额、商品名称等多个维度进行订单查询展示，其订单实际存储在组织级的订单微服务数据库中，由订单管理功能通过订单微服务获取展示。针对每一笔订单，可以展示订单详情，并执行退款操作。

4.2.5 订单微服务

订单微服务包括一些定时执行的批量程序，主要处理订单中心和开放平台之间在订单上的一些状态同步功能。

(1)自动退款管理。用户支付订单后，从商户处获取权益发放给客户，如果该过程中发生错误，获取权益失败，无法按预期发放购买的权益，就会按约定自动进行退款处理。

(2)支付状态同步。开放平台的订单微服务和组织级的订单微服务之间的订单状态应保持一致，但在实际运转过程中有时会产生两边状态不一致的情况，需要进行对账处理，确保状态一致。

(3)退款状态同步。在开放平台执行退款操作后，需要把该笔订单的退款状态同步到组织级的订单未付，确保订单状态一致。

5 结语

采用微服务的设计模式，直接复用已经开发好的组件，不仅能节约开发成本和时间、提高质量，还能满足组织中用户统一、订单统一、风控策略统一等要求，极大地提升软件开发的成熟度。基于微服务的技术架构对开发和运维的要求较高，更多的微服务需要部署更多的资源、提高运维要求，在确认拆分微服务时要平衡好开发和运维的矛盾，合理、适度地拆分。

通过构建开放卡券销售平台，对所有卡券类服务均在一个平台进行管理，降低了运营成本，极大地提升了运营效率，新场景能力的构建和发布频率从原来的至少3个月缩短到目前的2周，显著降低了开发周期和开发成本，具有良好的经济效益。