微服务在福彩销售系统中的应用

赵文华

（中国福利彩票发行管理中心技术部，北京 100101）

目前，福彩销售系统大多是基于分布式存储结构开发的单体应用程序业务系统，市场运行多年来，总体情况良好，有力保障了福彩的发行销售工作。为了保证系统实时安全运行，通常将上述单体应用业务系统部署在不同服务器上实现备份，保障发生故障时系统间相互快速切换，有的地方还建立了异地灾备中心等。但是传统的单体应用模式也导致了资源严重浪费，开发人员运维管理困难，系统可扩展性差等问题。随着云计算技术、微服务技术等新型应用架构的不断兴起、发展和完善，为成功解决上述问题提供了思路。

1 微服务

微服务是以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依据业务功能设计，以全自动的方式集成部署，与其他服务使用HTTP/API 进行通信。同时服务会使用最小规模的集中管理能力，服务可以用不同的编程语言与数据库等组件实现。微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务集组成，微服务架构使应用程序更易于扩展和更好更快的开发，具体特点如下所述。

1.1 异构性

通俗来讲，不同服务内部的开发技术或编程语言可以不一致，为不同的服务选择最适合的技术，系统中不同部分也可以使用不同存储技术。

1.2 隔离性

一个服务故障不会导致另一个服务瘫痪，因为各个服务是相互独立和自治的系统。

1.3 可扩展性

微服务在出现性能瓶颈的时候，可以对造成此原因的服务进行扩展升级，而不是对整个系统应用进行优化升级，极大地降低了系统扩展性成本。

1.4 易部署优化

对于有几百万行代码的单体服务，即使修改了几行代码仍需要重新编译整个应用，而且软件变更带来的不确定性也相对较高，软件部署的影响也比较大。在微服务架构中，各个服务的部署是独立的，如果真出了问题也只是影响单个服务，可以快速回滚版本解决。微服务架构中单个服务的代码量通常不会很大，当需要重构或者优化这些服务的时候，相对较为容易。

通常情况下，对于大型微服务架构的服务运维，往往需要建立一套完备的服务监控系统，服务运维人员需要实时掌握服务运行中的各种状态，在故障发生时，尽可能降低影响范围，尽快恢复正常服务。

有些服务的敏感数据存在安全问题，服务安全就是对敏感服务采用安全鉴权机制，对服务的访问需要进行相应的身份验证和授权，防止数据泄露外溢的风险。

2 常见微服务框架

2.1 Dubbo

Dubbo 是阿里巴巴公司开源的一个Java 高性能服务框架，应用可通过高性能的RPC 实现服务的输入和输出功能，可以和Spring 框架集成，它提供了三大核心功能：面向接口的远程方法调用，智能容错和负载均衡以及服务自动注册发现。

2.2 Tars

腾讯内部经过多年的实践，不断总结形成的开源项目微服务架构TAF，目前仅支持C++语言。

2.3 gRPC

Google 开发的高性能、通用的开源RPC 框架，其由Google 主要面向移动应用开发并基于HTTP/2 协议和序列化协议标准而设计，但其本身不是分布式的，所以要实现上面的框架功能需要进一步开发。

2.4 thrift

最初是由Facebook 开发的内部系统跨语言的高性能RPC 框架，之后成为Apache 开源项目之一，跟gRPC一样，它有一套自己的接口定义语言IDL，可以通过代码生成器，生成各种编程语言的客户端和服务端的SDK 代码，支持多种语言。

3 微服务划分

对于微服务模块划分，可以借鉴传统单体应用业务功能模块划分的思路进行，在这个基础上，会增加数据驱动，SOA 分层思路等，微服务划分不宜太细，粒度划分越细，后续微服务集成和管理的难度就越大。

在IT 应用架构规划大中台的概念下，实际上中台包含了技术中台和业务中台，对于技术中台重点是各个技术组件和技术服务能力的实现，而业务中台主要包括了数据能力和业务规则处理能力的提供。对于业务中台本身也是分层，包括了最基本的数据类中心和业务处理类中心。

数据类中心本身又包括了基础主数据类和核心共享业务数据类，例如，产品中心和用户中心，属于基础主数据类。而订单中心和库存中心则属于业务共享数据类。

业务处理类则主要是进行核心业务逻辑和功能的处理，包括交易中心、结算中心及计费中心等，都可以看作是业务处理类的中台模块。当然，业务处理类中台也可为关键的领域服务提供组件，此类组件需要调用底层更多基础子模块的核心接口。

3.1 数据驱动

数据是驱动业务流程的关键性因素，特别是对于一些基础数据和共享数据，是业务系统的核心所在。如果将一个基础主数据划分为一个微服务模块，那么会导致微服务模块的数量比较大，从效率上来讲不太可行。如果是按标准的主数据管理系统的业务模块划分，一定程度上，它不是按照数据维度进行划分，一般主数据系统包含元数据和数据对象，又细分为数据集成和调度、数据清理、流程引擎及数据内容管理等各个模块。

对于基础主数据类微服务模块，最好的方式是按数据域进行拆分，例如对于用户、组织、岗位和人员等划分到一个人力域数据中心，对于供应链、物料编码和采购类别等划分到采购或供应链域微服务模块。这种划分既实现了一定程度上的模块拆分和松耦合，同时按域划分后，同一个域的基础主数据本身在一个数据库中进行管理，这些基础主数据本身可能存在一定的耦合关系，那么这些耦合关系的处理将不再需要提升到分布式事务层面去处理。

3.2 业务流程

在把基础和共享数据划分出来之后，再考虑上层的各个业务以及业务流程与业务规则处理等还需要单独设置哪些微服务模块。

对于单体业务系统，还可从已有的业务系统入手进行微服务模块划分。这种划分方式通常考虑了高内聚低耦合的道理。单体应用构建更多是从纵向业务功能的角度出发，是偏纵向垂直方式构建业务功能的，而对于微服务架构思想下，引入了SOA 架构思路，主要思考目前的业务功能和业务流程，从数据→功能→流程的横向分层思路来搭建。

参考已有的业务系统模块划分，也要考虑核心共性基础数据下沉为独立的微服务，而流程类业务功能上升到前台类应用也作为独立的微服务。在整个过程中可以多参考业务系统的功能架构图，通过对比分析，再结合实际业务需求和业务流程情况进行优化整合。

4 福彩销售系统

4.1 主要功能

福彩销售系统是发行福利彩票的重要技术载体，也是管理福利彩票的主要技术手段。目前，以在运行的福利彩票“快乐8”销售系统为例，按照功能模块划分，主要包括中央核心交易系统、游戏引擎管理系统、线下渠道管理系统及销售终端软件系统。系统功能架构如图1 所示。

中央核心交易系统主要实现彩票交易流转、彩票数据稽核、彩民账户管理、彩票游戏管理等核心业务功能，并且针对游戏引擎和前端服务系统均提供了标准接口。

游戏引擎管理系统主要完成“快乐8”游戏规则参数化设置、游戏投注方式、游戏风险控制、兑奖查询及服务等功能。

线下渠道管理系统主要包括投注站权限管理、投注站点新增、撤销以及调整、站点缴款、业务运行监控、多维度统计分析及日志审计等。

销售终端软件系统是指安装部署在销售终端上（含自助终端）的业务软件系统，用于销售彩票、兑奖服务、通知公告查询、销售报表查询和在线培训等。

4.2 主要业务流程

按照上述系统功能架构要求，游戏引擎系统与核心交易系统在基诺游戏彩票核心交易业务中的逻辑关系如图2 所示。

图2 功能架构

彩票销售系统中的核心业务流程包括销售和兑奖，业务流程如图3 所示，具体描述如下。

图3 业务流程

4.2.1 彩票销售流程

（1）业主、彩民通过销售终端软件系统购买彩票，销售终端软件系统将购彩请求发送渠道管理系统；（2）渠道管理系统进行相关业务规则校验通过，并完成渠道业务处理，将彩票交易请求转发核心交易系统；（3）核心交易系统进行相关业务规则校验通过，并完成彩民业务处理，将彩票交易请求转发游戏引擎系统；（4）游戏引擎系统处理投注请求完成，将结果返回核心交易系统；（5）核心交易系统根据投注结果，对彩民业务进行处理，并将交易结果返回渠道管理系统；（6）渠道管理系统根据投注结果，对渠道业务进行处理，并将交易结果返回销售终端软件系统；（7）销售终端软件系统根据投注结果打印彩票或者给予相应提示。

4.2.2 彩票兑奖流程

（1）业主、彩民通过销售终端软件系统进行彩票兑奖，销售终端软件系统将兑奖请求发送渠道管理系统；（2）渠道管理系统进行相关业务规则校验通过，将彩票兑奖请求转发核心交易系统；（3）核心交易系统进行相关业务规则校验通过，将彩票兑奖请求转发游戏引擎系统；（4）游戏引擎系统处理兑奖请求完成，将结果返回核心交易系统；（5）核心交易系统根据兑奖结果，对彩民业务进行处理，并将交易结果返回渠道管理系统；（6）渠道管理系统根据兑奖结果，对渠道业务进行处理，并将交易结果返回前端售彩系统；（7）销售终端软件系统根据兑奖结果给予相应提示。

5 福彩销售系统中的微服务应用

在福彩销售系统中主要应用的微服务包括：注册发现服务（registry）、异步消息通信（MQ）、负载均衡（load balance）、内存数据库（非关系型数据库）（redis）、安全服务（security）及日志监控服务（monitor）等。

注册发现服务注册中心是用来集中管理微服务，实现服务的注册、发现、检查等功能；服务A 与服务B 在注册中心C 注册，形成服务注册表（表里登记了服务A 和服务B 的地址等相关信息）。当A 服务想要访问B 服务时，可以通过注册中心C 的服务发现机制，获取服务注册表进而找到服务B。注册发现服务是整个销售系统的基础，系统中所涉及的微服务均在此注册访问。

异步消息通信是指两个互不同步的设备通过计时机制或其他技术进行数据传输，异步通信中两个字符之间的时间间隔是不固定的，而在一个字符内各位的时间间隔是固定的。基本上，发送方可以随时传输数据，而接收方必须在信息到达时准备好接收。异步消息通信对于解决在销售彩票高峰阶段且并发量较大的数据是一种较好的处理机制。

负载均衡就是指将负载工作任务进行平衡、分摊到多个操作单元上进行运行，例如核心应用服务器和其他主要任务服务器等，从而协同完成工作任务。负载均衡软件解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，它基于特定环境，配置简单且使用灵活，可以满足一般的负载均衡需求。

目前使用的负载均衡算法为动态负载均衡算法以服务器的实时负载状态信息来决定任务的分配，例如加权最小连接法。最小连接法适用于各个节点处理的性能相似时，任务分发单元会将任务平滑分配给服务器。但当服务器性能差距较大时，就无法达到预期的效果。因为此时连接数并不能准确表明处理能力，连接数小而自身性能很差的服务器可能不及连接数大而自身性能极好的服务器，所以在这个时候就会导致任务无法准确地分配到剩余处理能力强的机器上。

内存数据库是一个非常快速的、开源的、支持网络、可基于内存亦可持久化的日志型、非关系类型的数据库，一定程度上是对关系型数据库的很好补充。它提供了Java，C/C++等客户端，支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。使得其可执行单层树复制，存盘可以有意无意地对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。

安全服务的主要内容包括：安全机制、安全连接、安全协议和安全策略等，它们能在一定程度上弥补和完善现有操作系统和网络信息系统的安全漏洞。具体内容包括，鉴别用于保证通信的真实性，正式接收的数据就来自所要求的源方，包括对等实体鉴别和数据源鉴别。数据源鉴别连同无连接的服务一起操作，而对等实体鉴别通常与面向连接的服务一起操作，一方面可确保双方实体可信，另一方面可确保该连接不被第三方干扰，如假冒其中的一方进行非授权的传输或接收；访问控制用于防止对网络资源的非授权访问，保证系统的可控性。访问控制可以用于通信源或目的，或是通信链路上的某一地方。

日志监控服务主要是指实时掌握服务运行中的各种状态，例如内存使用效率、调用次数和健康状况等，建立一套完备的服务监控体系，包括拓扑关系、日志审计、预警通知和调用追踪等。

6 结束语

福彩销售系统既是发行和销售福利彩票的重要载体，也是管理和服务福彩市场的有效手段，为我国彩票事业的持续发展提供了有力的技术支撑。微服务技术架构在福彩销售系统中的应用将极大程度地提高该系统的可扩展性、高可用性及安全性等，进一步丰富福彩销售系统的功能模块，提升福彩销售系统的性能指标，从广义上来讲，也将促进福利彩票销售市场的韧性，扩大福利彩票销售市场的规模，其必将更好地服务于我国民生民政事业和公益慈善事业持续创新发展。