微服务架构下规则平台方案与规则迁移方法

池炜成，史立学，刘智琼，朱明英

（1.中国电信股份有限公司研究院，广州510630；2.中国电信集团公司，北京100033）

0 引言

为实现数字化转型，企业正大规模实践应用系统上云工程，同时将应用系统由原有的MA架构（Mono⁃lithic Architecture，单体架构）转变为MSA架构（Mi⁃croservice Architecture，微服务架构），升级为基于云平台的微服务化系统。微服务架构遵循职责单一、数据自治、独立部署与运维等理念，通常按业务领域将单体系统拆分成多个微服务，不同业务子域的业务逻辑归入到不同微服务中。业务规则处理是业务逻辑的重要组成部分，所以不同子域的业务规则相应被划分到不同的微服务中处理。然而，在微服务架构下，由于各个微服务可以根据自身的功能、性能、可靠性等不同要求确定自身的实现方式，所以不同的微服务可能采取了不同的业务规则实现方式，如硬编码方式、文件配置方式、数据库配置方式、内嵌规则引擎方式等，而这些差异很容易导致微服务化系统的业务规则管理出现问题，包括业务规则管理分散、无法看到整体的规则视图和定义、无法统一监控业务规则执行情况等等，在微服务架构中引入业务规则平台是解决这些问题的有效办法。

1 微服务架构与业务规则

单体架构系统的代码耦合性强，程序统一开发、打包和部署，而随着应用系统越来越复杂，单体系统业务扩展能力差、难以升级维护等问题越来越明显。为了解决问题，业界提出了微服务架构，它按照分而治之、关注分离的思想将单体系统分解为多个小而自治的微服务，例如BSS（Business Supporting System，业务支撑系统）微服化后，系统拆分为客户中心、订单中心、促销中心、商品中心、批价中心、帐务中心等多个微服务，每个微服务相对独立，可以独立开发、打包和部署，有独立的数据库，令每个微服务可以专注完成某个业务子域的功能，微服务间通过调用轻量级服务的方式获得对方的数据或服务。微服务的高内聚性、高扩展性和高自治性等能够较好地解决单体架构的问题。

微服务架构一般包含五层：基础设施层、服务支撑层、业务逻辑层、访问层和门户层，其中服务支撑层为微服务提供服务管理等公共服务，业务逻辑层包含多个微服务。服务支撑层包含各种支撑微服务体系运行的公共能力，包括服务注册、服务监控、服务日志、服务调用链等等。在业务逻辑层，微服务通常根据业务领域功能划分，遵循“单一职责原则”，每个微服务专注完成一个业务子领域的功能，专门处理一个业务子域的业务逻辑。业务规则是对业务策略的定义和约束，是微服务业务逻辑的重要组成部分，例如，客户中心微服务负责客户实名认证规则的处理、订单中心微服务负责订单检验规则的处理、促销中心微服务负责积分赠送规则的处理，等等。业务规则处理在微服务架构中的位置如图1所示。

图1 微服务架构

2 业务规则实现方式与存在问题

由于每个微服务相对独立，不同微服务可以采用不同的技术实现，所以在微服务架构下，各个微服务对业务规则实现可能存在多种方式，甚至同一微服务中的不同业务规则也可能使用了不同方式，这些方式包括硬编码方式、文件配置方式、数据库配置方式、内嵌规则引擎方式等。

在硬编码方式中，在微服务程序中直接编写业务规则处理的逻辑代码，包括规则的条件和动作语句，而且规则中使用的数值是在程序中固化的，以为积分赠送规则为例，业务规则的逻辑表达如下：如果客户是七星客户且当月帐单额不少于100元，那么当月赠送1000电信积分，“如果”部分表达了规则条件，“那么”部分表达了规则动作。在硬编码方式中，规则的条件和动作以及阈值“7”、“100”、“1000”都写在代码中，在此种方式下，当条件或动作的结构发生变化（如：增加一个判断条件）或者任一阈值发生变化时都要修改程序代码。

文件配置方式是在后台的配置文件中配置业务规则的条件和动作，包括涉及的属性及阈值，微服务程序代码先从文件中读取规则配置信息，然后解释执行规则，如上述积分赠送规则，属性的阈值“7”、“100”、“1000”等在文件中设置，在此种方式下，阈值变化只需要修改配置文件，不需要修改程序，但当条件或动作的结构超出配置范围时仍需修改程序代码。数据库配置方式，与文件配置方式相似，不同在于规则信息保存在数据库中。

内嵌规则引擎方式是将规则引擎组件嵌入在微服务程序中，微服务程序用相对固定的模式通过调用规则引擎组件的能力执行预先定义的业务规则，例如在规则引擎drools中，积分赠送规则的条件和动作定义：when $point:Point（customerClass==7&& billLimit>=100）then$point.setPoint（1000）。在此种方式下，规则的条件和动作结构以及阈值发生变化，只需修改业务规则定义，不需要修改微服务程序代码，例如积分赠送规则中又增加了一个条件：客户在网时长超过5年，那么只需将积分赠送规则定义改为：when$point:Point（customerClass==7&&billLimit>=100&&entryYears>=5）then$point.setPoint（1000）即可。在微服务应用程序中实现业务规则的多种方式如图2所示。

图2 业务规则实现方式

从微服务化系统的整体来看，不同微服务采用不同业务规则实现方式会产生多种问题，主要包括：第一，不同微服务的灵活性参差不齐，方式一最差，其次是方式二或方式三，最好的是方式四，但对整个微服务化系统而言，灵活性较差的微服务会直接拉低了系统整体的灵活性，导致业务需求响应缓慢，并影响系统整体的稳定性，难以适应业务规则繁多易变的市场环境；第二，由于业务规则的管理和实现分散在各个微服务中，缺乏整体的业务规则目录和视图，业务规则的实现缺乏透明度，无法统一获取各类业务规则的配置和执行情况，给业务运营和规则解释造成较大障碍；第三，业务规则实现的重用性低，同一业务规则可能在不同微服务中被重复开发甚至执行不一致，从而不但增加了业务规则实现的开发成本，还导致整体的业务策略难以落实。

3 业务规则平台方案

在微服务架构中引入统一的业务规则平台是解决上述问题的一个有效办法。从微服务架构看，在服务支撑层新设业务规则平台。与服务注册、服务监控等一样，业务规则平台为微服务提供公共的平台级服务，负责统一配置和执行所有微服务的业务规则。各个微服务可通过轻量级服务调用方式调用业务规则平台的规则执行服务，并获取规则执行的结果。业务规则平台在微服务架构中的定位如图3所示。

图3 业务规则平台在微服务架构中的定位

业务规则平台将原来分散在各微服务中的业务规则配置和执行工作抽取出来统一处理，主要功能是规则配置和规则执行。

在规则配置方面，功能包括对象配置、规则配置、规则转换等，其中对象配置业务规则中引用的数据对象定义，包括数据对象的属性及获取相应属性值的服务编排，如客户等级从客户中心微服务提供的客户信息查询服务中获取；规则配置是业务规则的定义，支持令业务人员容易理解的类自然语言形式表达；数据对象和规则配置的数据以结构化数据的形式保存在数据库（如MySQL）中，同时将结构化的业务规则自动转化为规则引擎可解析的规则文件，如规则引擎Drools的DRL（Drools Rule Language，Drools规则语言）文件，形成规则文件库。

在规则执行方面，功能包括规则执行服务、对象取数、对象构造、规则触发、规则执行、日志生成、日志入库等，其中规则执行服务以轻量级服务接口的方式（如Restful API，REST风格的应用程序接口）对所有微服务提供统一的规则执行服务，只需要微服务传入规则名称和少量的规则处理对象数据（如客户标识）；对象取数是根据规则中引用的数据对象定义，通过调用相应的微服务获取数据值；对象构造是创建数据对象并对象插入规则引擎中；规则触发是激活规则引擎，使其对插入的数据对象执行相应的规则；规则引擎组件主要功能是规则匹配、规则执行，它根据规则定义与数据对象进行规则推理和执行；规则日志生成与入库是记录和保存规则执行服务的调用和处理过程，日志记录通过消息队列（如Kafka）最终存储到分布式列数据库（如HBase）中。业务规则平台技术方案如图4所示。

图4 业务规则平台技术方案

4 业务规则迁移方法

面对已实施微服务架构但各微服务业务规则实现方式不统一的情形，除了在服务支撑层部署业务规则平台，还需要有一套统一的业务规则迁移方法，以有序地将原来的分散在各微服务中的业务规则迁移到业务规则平台，从而统一业务规则的方式实现。

微服务的业务规则迁移到业务规则平台，总体上可分为四个阶段，包括规则设计、规则配置、微服务适配、规则发布。在规则设计阶段，主要完成规则梳理和规则整合。规则梳理是各微服务根据自己原来的业务规则实现方式梳理出业务规则的详细描述；规则整合是分析所有微服务已梳理出来的业务规则，然后整合相似规则，去除原来不一致的地方，重新设计业务规则。在规则配置阶段，主要完成规则基本信息配置、数据对象配置、对象服务映射配置、条件配置和动作配置。在微服务适配阶段，各微服务将原来的业务规则剥离出来，改造成调用平台服务的方式实现业务规则。其中，数据服务是微服务根据业务规则的数据对象需要，提供相应的服务API给业务规则平台使用；规则服务调用是调用业务规则平台提供的统一规则执行服务完成业务规则的执行，并获取规则执行的结果。在规则发布阶段，主要完成规则测试、规则核准和规则启用，其中规则测试是对规则的配置和执行进行自动化的测试和验证；规则核准是对测试结果进行审核和确认，确保规则的定义和执行与预期一致；规则启用是规则正式上线使用，投入生产。业务规则迁移方法如图5所示。

图5 业务规则迁移方法

5 结语

本文研究了微服务架构的特点，分析了微服务中业务规则的实现方式及存在问题，并提出微服务架构下业务规则平台技术方案及业务规则迁移方法。在微服务架构中的服务支撑层引入业务规则平台，是解决微服务分散处理业务规则带来的各种问题的有效措施，一方面能够减少众多微服务各自重复开发业务规则功能带来的成本，另一方面能够保证业务规则的配置和执行一致性，从而提高微服务化系统的灵活性和可维护性，更快地响应各种业务需求的变化。