CN110737425A - 一种计费平台系统的应用程序的建立方法及装置 - Google Patents

Abstract

本发明公开了一种计费平台系统的应用程序的建立方法及装置。所述方法包括：将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块，并根据第一预设规则将网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将非网关型模块转换为至少一个第二类型的微服务，然后，可以在建立各微服务之间的接口的基础上，结合各微服务建立第二应用程序系统。如此，能够采用微服务的形式部署新的功能模块，从而可以加快部署速度，缩短部署的窗口时间，精简应用程序的结构，进而可以减轻后续开发维护的工作量，进而减少版本开发维护对在用业务的影响。

Description

一种计费平台系统的应用程序的建立方法及装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种计费平台系统的应用程序的建立方法及装置。

背景技术

随着计算机技术的不断发展，互联网技术已经融入到大众生活的方方面面，互联网时代的应用程序通常用户数目多，需求变化快。这就要求开发人员对软件功能版本进行升级。由于应用程序通常采用一个服务进程来执行该应用程序的所有功能，因此，新功能的开发或者旧功能的更新依然是在原来的服务进程中实现，这就容易导致服务进程所执行的功能越来越多，负载越来越高，进而限制了服务访问性能的提升，也增加了维护应用程序的工作量。

现有技术中已有的一种解决方案为，将应用程序拆分为多个微服务，每个微服务实现一个功能，通过多个微服务之间的交互实现整个应用程序所提供的功能。现有技术在对应用程序进行拆分时，通常是按照能够实现最小功能的模块进行拆分的，即每个微服务都是用于实现最小功能的模块。采用这种方式拆分成的微服务的粒度太细，为了实现一个功能可能需要多次与不同的微服务进行交互，从而加大了部署应用程序系统的难度，也提高了维护应用程序系统的工作量。

基于此，目前亟需一种计费平台系统的应用程序的建立方法，用于解决现有技术在对应用程序系统拆分成微服务的粒度太细，容易导致应用程序系统的部署难度高、维护工作量大的问题。

发明内容

本发明实施例提供一种计费平台系统的应用程序的建立方法及装置，以解决现有技术中在对应用程序系统拆分成微服务的粒度太细，容易导致应用程序系统的部署难度高、维护工作量大的技术问题。

本发明实施例提供一种计费平台系统的应用程序的建立方法，所述方法包括：

将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块；所述网关型模块用于实现所述第一应用程序系统与外部系统的交互；

根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务；

根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口；

根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

采用上述方式拆分成的微服务，将用于实现应用程序内部功能的非网关型模块和用于实现应用程序与外部系统交互功能的网关型模块进行区分，因此，本发明实施例能够将用于实现应用程序内部功能的非网关型模块和用于实现应用程序与外部系统交互功能的网关型模块进行区分，相比于现有技术按照实现最小功能的模块对应用程序进行拆分的方式而言，本发明实施例能够减少微服务之间交互的次数，减少应用程序系统的研发工作量，降低应用程序系统的部署难度；在信息安全的角度上，可以对网关型模块和非网关型模块采用不同的安全策略，从而提高应用程序的安全性；并且，针对网关型模块和非网关型模块，可以分别采用不同的预设规则将其转换为微服务，由于每个微服务都是高度自治的独立业务实体，都是独立的服务进程，因此对应用程序系统中的一个微服务进行开发维护时，只需要更新部署对应的微服务，而不会影响应用程序系统中的其它微服务的正常使用，大大降低版本开发维护对在用业务的影响。

在一种可能的实现方式中，所述根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，包括：

根据所述网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，得到至少一个第一类型的微服务。

如此，可以根据模块的接入方式，可以将不同网络环境中的微服务进行分离，在信息安全的角度上，针对不同部署环境的微服务可以采用不同的安全策略，从而提高应用系统的安全性。

在一种可能的实现方式中，所述根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务，包括：

根据所述属性信息中的业务属性，将所述非网关型模块划分为管理型模块和非管理型模块；所述管理型模块用于实现应用程序的配置功能；

针对所述非管理型模块，根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务；

针对所述管理型模块，根据所述第一类型的微服务对应的配置属性和所述第三类型的微服务对应的配置属性，对所述管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务；各微服务对应的配置属性是根据所述各微服务中包括的每个模块的属性信息得到的。

如此，能够在满足现有业务需求的前提下，实现微服务的拆分粒度的合理性，遵循拆分颗粒度原则，在达成微服务实施目标的同时，尽量避免因对应用拆分成微服务的粒度太粗，使得服务内部的代码容易产生耦合，不能达成微服务改造实施目标的情况，也要避免因对应用拆分成微服务的粒度太细，导致接口数量增多，增加了运维或部署难度的问题。

在一种可能的实现方式中，所述业务关联性是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的；

根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务，包括：

将每个模块的数据实体符合第一设定规则的模块，和/或，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务；或者，

将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

如此，可以将耦合度低的微服务分开，将耦合度高的微服务放在一起，从而能够减少微服务的调用。

在一种可能的实现方式中，所述将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务，包括：

将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务；

将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务；所述第一候选微服务间的耦合度是根据所述第一候选微服务包括的模块间耦合度得到的；

针对所述至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

如此，可以将变化频度高的模块和变化频度低的模块进行分离，降低频繁的变化对应用系统实现带来的影响，能够提升交付速度。可以将耦合度低的微服务分开，将耦合度高的微服务放在一起，从而能够减少微服务的调用。采用这种方式，微服务的粒度既不会过粗，也不会过细，能够有效避免因微服务实施带来的影响。

本发明实施例提供一种计费平台系统的应用程序的建立装置，所述装置包括：

划分单元，用于将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块；所述网关型模块用于实现所述第一应用程序系统与外部系统的交互；

转换单元，用于根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务；

建立单元，用于根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口；以及根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

在一种可能的实现方式中，所述转换单元具体用于：

根据所述网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，得到至少一个第一类型的微服务。

在一种可能的实现方式中，所述转换单元具体用于：

根据所述属性信息中的业务属性，将所述非网关型模块划分为管理型模块和非管理型模块；所述管理型模块用于实现应用程序的配置功能；针对所述非管理型模块，根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务；针对所述管理型模块，根据所述第一类型的微服务对应的配置属性和所述第三类型的微服务对应的配置属性，对所述管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务；各微服务对应的配置属性是根据所述各微服务中包括的每个模块的属性信息得到的。

在一种可能的实现方式中，所述业务关联性是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的；

所述转换单元具体用于：

将每个模块的数据实体符合第一设定规则的模块，和/或，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务；或者，将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

在一种可能的实现方式中，所述转换单元具体用于：

将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务；意见将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务；所述第一候选微服务间的耦合度是根据所述第一候选微服务包括的模块间耦合度得到的；针对所述至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

本发明实施例还提供一种装置，所述装置包括：

存储器，用于存储软件程序；

处理器，用于读取所述存储器中的软件程序并执行上述各种可能的实现方式中所描述的应用程序系统建立的方法。

本发明实施例还提供一种计算机存储介质，所述存储介质中存储软件程序，该软件程序在被一个或多个处理器读取并执行时实现上述各种可能的实现方式中所描述的应用程序系统建立的方法。

本发明实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各种可能的实现方式中所描述的应用程序系统建立的方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍。

图1为本发明实施例适用的一种系统架构的示意图；

图2为本发明实施例提供的一种计费平台系统的应用程序的建立方法对应的流程示意图；

图3为本发明实施例提供的一种微服务转换的示意图；

图4为本发明实施例提供的一种第二应用程序系统的结构示意图；

图5为本发明实施例提供一种计费平台系统的应用程序的建立装置的结构示意图。

具体实施方式

下面结合说明书附图对本申请进行具体说明，方法实施例中的具体操作方法也可以应用于装置实施例中。

图1示例性示出了本发明实施例适用的一种系统架构的示意图。如图1所示，所述系统100包括终端101、应用程序102和数据库103。其中，终端101上安装有应用程序102，应用程序102可以与数据库103连接。本实施例以计费平台系统的应用程序为例进行说明，应用程序102中可以包括多个模块，如图1中示出的平台网关模块、支付网关模块、合同受理模块、用户管理模块、计费批价模块、商品管理模块、账务管理模块等，每个模块可以执行不同的功能。

本发明实施例中，终端可以为多种类型的终端，例如笔记本电脑、智能手机、平板电脑、智能电视等。

基于图1所示的系统架构，图2示例性示出了本发明实施例提供的一种计费平台系统的应用程序的建立方法对应的流程示意图。如图2所示，包括以下步骤：

步骤201，将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块。

步骤202，根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务。

步骤203，根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口。

步骤204，根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

采用上述方式拆分成的微服务，由于考虑到应用程序系统中的模块存在网关型模块和非网关型模块的区分，因此，本发明实施例能够将用于实现应用程序内部功能的非网关型模块和用于实现应用程序与外部系统交互功能的网关型模块进行区分，相比于现有技术按照实现最小功能的模块对应用程序进行拆分的方式而言，本发明实施例能够减少微服务之间交互的次数，减少应用程序系统的研发工作量，降低应用程序系统的部署难度；在信息安全的角度上，可以对网关型模块和非网关型模块采用不同的安全策略，从而提高应用程序的安全性；并且，针对网关型模块和非网关型模块，可以分别采用不同的预设规则将其转换为微服务。由于每个微服务都是高度自治的独立业务实体，都是独立的服务进程，因此在对应用程序系统进行升级维护时，只需要更新部署对应的微服务，而不会影响应用程序系统中的其它微服务的正常使用，大大降低版本开发维护对在用业务的影响。

具体来说，步骤201中，网关型模块可以用于实现第一应用程序系统与外部系统的交互。以第一应用程序为计费平台为例，如表1所示，为计费平台中的模块的一种示例。计费平台中的模块可以为“与支付宝交互的接口”、“合同受理”、“与大数据平台交互的接口”、“订单生成”、“用户管理等模块”等。其中，“与支付宝交互的接口”是用于实现计费平台与支付宝的交互，“与大数据平台交互的接口”是用于实现计费平台与大数据平台的交互，因此，表1中示出的“与支付宝交互的接口”和“与大数据平台交互的接口”这两个模块可以作为网关型模块；相应地，表1中示出的合同受理”、“订单生成”和“用户管理”这三个模块可以作为非网关型模块。

表1：计费平台中的模块的一种示例

编号	模块的名称
		1	与支付宝交互的接口
2	合同受理
		3	与大数据平台交互的接口
4	订单生成
		5	用户管理
……	……

步骤202中，针对网关型模块和非网关型模块，本发明实施例可以采用不同的规则来将其转换为微服务。下面对此进行详细说明。

(一)针对网关型模块

如表2所示，为网关型模块的一种示例。网关型模块可以包括“与支付宝交互的接口”、“与大数据平台交互的接口”、“与微信支付交互的接口”、“与银联支付平台交互的接口”、“与网速测试平台交互的接口”和“与业务平台交互的接口”。其中，网速测试平台、业务平台与计费平台可以为同一个系统内的多个平台，换言之，网速测试平台、业务平台、计费平台这三个平台可以处于同一个系统内。

表2：网关型模块的一种示例

编号	网关型模块的名称
		1	与支付宝交互的接口
2	与大数据平台交互的接口
		3	与微信支付交互的接口
4	与银联支付平台交互的接口
		5	与网速测试平台交互的接口
6	与业务平台交互的接口

本发明实施例可以根据第一预设规则将网关型模块转换为至少一个第一类型的微服务。其中，第一预设规则可以为多种类型的规则，例如，第一预设规则可以为以接入方式为基准的规则，也可以为以模块名称为基准的规则，还可以为以通信协议为基准的规则，具体不做限定。

以第一预设规则为以接入方式为基准的规则为例，可以根据网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，从而得到至少一个第一类型的微服务。举个例子，根据表2示出的内容可知，“与支付宝交互的接口”的接入方式是与外网连接的，“与大数据平台交互的接口”的接入方式是与内网中的数据库连接的，“与微信支付交互的接口”的接入方式是与外网连接的，“与银联支付平台交互的接口”的接入方式是与外网连接的，“与网速测试平台交互的接口”的接入方式是与内网中的其它平台连接的，“与业务平台交互的接口”的接入方式是与内网中的其它平台连接的。如此，如表3所示，为网关型模块转换成微服务的一种示例。本发明实施例可将接入方式一致的模块转换为同一个微服务，比如，可以将接入方式同为与外网连接的“与支付宝交互的接口”、“与微信支付交互的接口”、“与银联支付平台交互的接口”这三个模块转换为同一个微服务(即表3中示出的“支付网关微服务”)，得到一个第一类型的微服务。类似地，其它模块也可以根据上述方式进行转换，具体可参见表3中示出的内容，在此不再赘述。即，第一类型的微服务为支付网关微服务、数据网关微服务和平台网关微服务。

表3：网关型模块转换成微服务的一种示例

网关型模块的名称	转换后的微服务
		与支付宝交互的接口	支付网关微服务
与大数据平台交互的接口	数据网关微服务
		与微信支付交互的接口	支付网关微服务
与银联支付平台交互的接口	支付网关微服务
		与网速测试平台交互的接口	平台网关微服务
与业务平台交互的接口	平台网关微服务

以第一预设规则为以模块名称为基准的规则为例，可以根据网关型模块中每个模块对应的模块名称，将模块名称一致的模块转换为同一个微服务，从而得到至少一个第一类型的微服务。举个例子，根据表2示出的内容可知，“与支付宝交互的接口”、“与大数据平台交互的接口”、“与微信支付交互的接口”、“与银联支付平台交互的接口”、“与网速测试平台交互的接口”和“与业务平台交互的接口”这8个模块可以分别作为8个微服务，即“与支付宝交互的微服务”、“与大数据平台交互的微服务”、“与微信支付交互的微服务”、“与银联支付平台交互的微服务”、“与网速测试平台交互的微服务”和“与业务平台交互的微服务”。

采用上述方法，可以根据模块的接入方式，可以将不同网络环境中的微服务进行分离，在信息安全的角度上，针对不同部署环境的微服务可以采用不同的安全策略，从而提高应用系统的安全性。

(二)针对非网关型模块

如表4所示，为非网关型模块的一种示例。非网关型模块可以包括“订单生成”、“订单修改”、“订单中商品配置”、“订单配置参数”、“用户类别”、“用户信息”、“用户增删”、“用户配置参数”、“费用计算”、“费用查询”、“费用配置参数”、“余额查询”、“余额变更”、“余额配置参数”、“账务信息”、“账务管理”、“账务配置参数”、“合同校验”、“合同延期”、“合同结构化”、“合同中商品配置”、“合同配置参数”、“平台结构设置”、“平台配置参数”、“平台颜色设置”等模块。

表4：非网关型模块的一种示例

进一步地，模块的属性信息可以包括业务属性、数据实体、变化频度和耦合度等。其中，以业务属性为例，可以将用于实现应用程序的配置功能的模块的业务属性归类为管理型。以数据实体为例，根据数据架构设计角度，数据逻辑模型中定义了不同的数据实体，例如，用户、合同、订单等都是不同的数据实体，不同类的数据实体转换为不同的微服务，同类数据实体尽量转换为同一微服务；进一步地，在大型的应用程序系统中，数据实体本身可能存在主从关系，比如，用户、合同、订单等可以为主数据实体，而用户联系信息、用户识别信息作为从数据实体与用户这一主数据实体关联，从数据实体与关联的主数据实体可以转换为同一微服务。

以表4中示出的非网关型模块为例，如表5所示，为每个模块的属性信息的一种示例。例如，“订单生成”模块的属性信息中，业务属性为非管理型模块，数据实体为订单、变化频度为低、且该模块不与配置属性相关，其它模块的属性信息可以参见表5示出的内容，此处不再具体描述。

表5：每个模块的属性信息的一种示例

模块的属性信息中包括的耦合度具体可以是指任意两个模块之间的信息或参数依赖的程度。以表4中示出的部分非网关型模块为例，如表6所示，为模块之间的属性信息的一种示例。其中，“余额查询”和“余额变更”之间的耦合度为90％，“余额查询”和“账务信息”之间的耦合度为80％，“余额查询”和“账务管理”之间的耦合度为80％，“余额查询”和“合同校验”之间的耦合度为10％，“余额查询”和“合同延期”之间的耦合度为10％，“余额查询”和“合同结构化”之间的耦合度为10％。

表6：模块之间的属性信息的一种示例

本发明实施例可以根据第二预设规则将非网关型模块转换为至少一个第二类型的微服务。其中，第二预设规则可以为多种类型的规则，例如，第二预设规则可以为以数据实体为基准的规则，举个例子，可以根据表5所述的内容，将非网关型模块转换为订单微服务、用户微服务、计费微服务、余额微服务、账务微服务、合同微服务、系统微服务等第二类型的微服务；或者，第二预设规则也可以为以耦合度为基准的规则；或者，第二预设规则还可以为以变化频度为基准的规则，具体不做限定。

进一步地，在非网关型模块转换为至少一个第二类型的微服务之前，可以先根据属性信息中的业务属性，将非网关型模块划分为管理型模块和非管理型模块，如表5所示，管理型模块可以包括“订单中商品配置”、“订单配置参数”、“用户配置参数”、“费用配置参数”、“余额配置参数”、“账务配置参数”、“合同中商品配置”、“合同配置参数”、“平台结构设置”、“平台配置参数”、“平台颜色设置”、“平台网关配置参数”、“数据网关配置参数”、“支付网关配置参数”这些模块；非管理型模块可以包括“订单生成”、“订单修改”、“用户类别”、“用户信息”、“用户增删”、“费用计算”、“费用查询”、“余额查询”、“余额变更”、“账务信息”、“账务管理”、“合同校验”、“合同延期”、“合同结构化”这些模块。

更进一步地，针对非管理型模块，可以根据非管理型模块中每个模块之间的业务关联性，对非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务。其中，业务关联性可以是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的。根据业务关联性的不同，得到的微服务也不同，下面进行具体说明。

一个示例中，可以将每个模块的数据实体符合第一设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。举个例子，可以将数据实体一致的模块转换为同一个微服务。以表5示出的内容为例，第三类型的微服务可以为订单微服务、用户微服务、计费微服务、余额微服务、账务微服务、合同微服务等。

又一个示例中，可以将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。举个例子，可以将变化频度一致的模块转换为同一个微服务。以表5示出的内容为例，“用户增删”和“合同结构化”这两个模块的变化频度较高，可以将这两个模块转换为同一个微服务，相应地，可以将其它模块转换为同一个微服务，如此，第三类型的微服务可以为高变化频度微服务和低变化频度微服务。

又一个示例中，可以将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。举个例子，先可以将数据实体一致的模块转换为同一个微服务，即可以为订单微服务、用户微服务、计费微服务、余额微服务、账务微服务、合同微服务等；然后可以将变化频度一致的模块转换为同一个微服务，比如，用户微服务中“用户增删”这个模块的变化频度远远高于其它模块，则可以将“用户增删”这个模块转换为用户增删微服务；又比如，合同微服务中“合同结构化”这个模块的变化频度远远高于其它模块，则可以将“合同结构化”这个模块转换为合同结构化微服务。如此，第三类型的微服务可以为订单微服务、用户微服务、计费微服务、余额微服务、账务微服务、合同微服务、用户增删微服务和合同结构化微服务。

又一个示例中，可以将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

具体来说，如图3所示，为本发明实施例提供的一种微服务转换的示意图，包括如下步骤：

步骤301，将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务。

具体来说，可以将数据实体一致的模块转换为同一个微服务，得到至少一个第一候选微服务。以表5示出的内容为例，第一候选微服务可以为订单候选微服务、用户候选微服务、计费候选微服务、余额候选微服务、账务候选微服务、合同候选微服务等。

步骤302，将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务。

具体来说，第一候选微服务间的耦合度可以是根据第一候选微服务包括的模块间耦合度得到的。比如，可以将模块间耦合度的平均值作为第一候选微服务间的耦合度，或者也可以将模块间耦合度的最大值作为第一候选微服务间的耦合度，具体不做限定。以将模块间耦合度的平均值作为第一候选微服务间的耦合度为例，根据表6以及步骤301中所述的内容可知，表6中示出的多个模块根据步骤301的描述可以转换为余额候选微服务、账务候选微服务和合同候选微服务。而余额候选微服务和账务候选微服务间的耦合度可以根据表6中“余额查询”和“账务信息”之间80％的耦合度、“余额查询”和“账务管理”之间80％的耦合度、“余额变更”和“账务信息”之间80％的耦合度、“余额变更”和“账务管理”之间80％的耦合度，得到余额候选微服务和账务候选微服务间的耦合度为80％；类似地，余额候选微服务和合同候选微服务间的耦合度可以根据表6中“余额查询”和“合同校验”之间10％的耦合度、“余额查询”和“合同延期”之间10％的耦合度，“余额查询”和“合同结构化”之间10％的耦合度、“余额变更”和“合同校验”之间10％的耦合度、“余额变更”和“合同延期”之间10％的耦合度，“余额变更”和“合同结构化”之间10％的耦合度，得到余额候选微服务和合同候选微服务间的耦合度为10％；采用同样的方法，账务候选微服务和合同候选微服务间的耦合度也为10％。

进一步地，可以将耦合度相近的模块转换为同一个微服务，得到至少一个第二候选微服务。即，第二候选微服务可以为订单候选微服务、用户候选微服务、计费候选微服务、余额及账务候选微服务、合同候选微服务等。

如此，可以将耦合度低的微服务分开，将耦合度高的微服务放在一起，从而能够减少微服务的调用。

步骤303，针对至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

具体来说，针对上文得到的多个第二候选微服务，可以将变化频度一致的模块转换为同一个微服务，比如，合同候选微服务中“合同结构化”这个模块的变化频度远远高于其它模块，则可以将“合同结构化”这个模块转换为合同结构化微服务。如此，第三类型的微服务可以为订单微服务、用户微服务、计费微服务、余额及账务微服务、合同微服务、和合同结构化微服务。

采用上述步骤301至步骤303所描述的方法，可以将变化频度高的模块和变化频度低的模块进行分离，降低频繁的变化对应用系统实现带来的影响，能够提升交付速度。可以将耦合度低的微服务分开，将耦合度高的微服务放在一起，从而能够减少微服务的调用。采用这种方式，微服务的粒度既不会过粗，也不会过细，能够有效避免因微服务实施带来的影响。

在其它可能的示例中，可以将每个模块的实现难度符合设定规则的模块，转换为同一个微服务，如此能够减少Bug出现的概率；或者，还可以将每个模块的活跃度符合设定规则的模块，转换为同一个微服务，例如，系统中各应用系统间的交互十分频繁，平台网关模块的访问次数多，相应地，平台网关模块的活跃度高，而系统配置模块的访问的次数少，相应地，系统配置模块的活跃度低，这两个模块可以拆分为不同的微服务应用。如此可以避免每次改动都要重新部署所有模块，减少很多潜在的风险和不确定性因素。

针对管理型模块，可以根据第一类型的微服务对应的配置属性和第三类型的微服务对应的配置属性，对管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务。其中，各微服务对应的配置属性可以是根据各微服务中包括的每个模块的属性信息得到的，比如，微服务对应的配置属性可以根据与该微服务中各模块的数据实体一致的，且与配置属性相关的模块得到。

具体地，根据上文所描述的内容，如表7所示，为管理型模块的一种示例。其中，管理型模块可以包括“订单中商品配置”、“订单配置参数”、“用户配置参数”、“费用配置参数”、“余额配置参数”、“账务配置参数”、“合同中商品配置”、“合同配置参数”、“平台结构设置”、“平台配置参数”、“平台颜色设置”、“平台网关配置参数”、“数据网关配置参数”、“支付网关配置参数”等模块，每个模块对应的数据实体可以参考表7示出的内容，此处不再详细描述。

表7：管理型模块的一种示例

编号	网关型模块的名称	数据实体
			1	订单中商品配置	订单
2	订单配置参数	订单
			3	用户配置参数	用户
4	费用配置参数	费用
			5	余额配置参数	余额
6	账务配置参数	账务
			7	合同中商品配置	合同
8	合同配置参数	合同
			9	平台结构设置	系统
10	平台配置参数	系统
			11	平台颜色设置	系统
12	平台网关配置参数	网关
			13	数据网关配置参数	网关
14	支付网关配置参数	网关

若第一类型的微服务为支付网关微服务、数据网关微服务和平台网关微服务，第三类型的微服务为订单微服务、用户微服务、计费微服务、余额及账务微服务、合同微服务和合同结构化微服务，则以订单微服务为例，该微服务中包括的模块为“订单生成”、“订单修改”模块，这两个模块所属的数据实体为订单，根据表7示出的内容，“订单中商品配置”和“订单配置参数”这两个管理型模块的数据实体也为订单，可以将管理型模块中的“订单中商品配置”和“订单配置参数”这两个模块划分为同一个微服务，比如订单配置微服务。类似地，其余微服务也可以采用上述方式进行划分，具体不再赘述。如此，第四类型的微服务可以为平台网关配置微服务、数据网关配置微服务、支付网关配置微服务、订单配置微服务、用户配置微服务、计费配置微服务、余额及账目配置微服务、账务配置微服务、合同配置微服务、系统配置微服务。

进一步地，为了减少微服务之间的接口，可以对上述第四类型的微服务进行转换，比如，可以将订单配置微服务中的“订单中商品配置”和合同配置微服务中的“合同中商品配置”转换为同一个微服务，如商品配置微服务；可以将订单配置微服务中的“订单配置参数”模块、合同配置微服务中的“合同配置参数”模块、以及用户配置微服务、计费配置微服务、余额及账目配置微服务、账务配置微服务中的模块转换为同一个微服务，如参数微服务；可以将平台网关配置微服务、数据网关配置微服务、支付网关配置微服务中的模块转换为同一个微服务，如公共资源配置微服务。如此，第四类型的微服务可以为商品配置微服务、参数配置微服务、公共资源配置微服务、系统配置微服务。

如此，能够在满足现有业务需求的前提下，实现微服务的拆分粒度的合理性，遵循拆分颗粒度原则，在达成微服务实施目标的同时，尽量避免因对应用拆分成微服务的粒度太粗，使得服务内部的代码容易产生耦合，不能达成微服务改造实施目标的情况，也要避免因对应用拆分成微服务的粒度太细，导致接口数量增多，增加了运维或部署难度的问题。

步骤203和步骤204中，为了便于各微服务之间的交互，需要在各微服务之间建立接口。一种可能的实施方式为，根据各微服务之间的关联属性来建立各微服务之间的接口，其中，各微服务之间的关联属性可以根据各微服务中包括的每个模块的属性信息得到。以订单微服务和费用微服务为例，订单微服务中包括“订单生成”和“订单修改”模块，且这两个模块的数据实体均为订单；费用微服务中包括“费用计算”和“费用查询”模块，且这两个模块的数据实体均为计费。一个订单中会包括费用，那么订单和计费这两个数据实体之间存在关联，进而，订单微服务和费用微服务之间也存在关联，如此，可以建立订单微服务和费用微服务之间的接口。

在其它可能的实现方式中，也可以在任意两个微服务之间均建立接口，具体不做限定。

进一步地，本发明实施例可以根据第一类型的微服务、第三类型的微服务、第四类型的微服务及各微服务之间的接口，建立第二应用程序系统。

为了更清楚地介绍上述第二应用程序系统的结构，图4示例性示出了本发明实施例提供的一种第二应用程序系统的结构示意图。如图4所示，第二应用程序系统可以分为Web展现层、微服务应用层和数据存储层。Web展现层可以负责前端展示和用户请求的处理；微服务应用层用于实现核心业务逻辑；数据存储层用于实现资源的存储。进一步地，微服务应用层可以分为三大类，分别为接口类微服务、业务类微服务和管理类微服务，每一大类的微服务都可以以独立部署的方式运行。微服务应用层的具体结构可以参考图4示出的内容，此处不再赘述。

基于同样的发明构思，图5示例性示出了本发明实施例提供一种计费平台系统的应用程序的建立装置的结构示意图，如图5所示，所述装置包括划分单元501、转换单元502和建立单元503。

划分单元501，用于将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块；所述网关型模块用于实现所述第一应用程序系统与外部系统的交互；

转换单元502，用于根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务；

建立单元503，用于根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口；以及根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

在一种可能的实现方式中，所述转换单元502具体用于：

根据所述网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，得到至少一个第一类型的微服务。

在一种可能的实现方式中，所述转换单元502具体用于：

根据所述属性信息中的业务属性，将所述非网关型模块划分为管理型模块和非管理型模块；所述管理型模块用于实现应用程序的配置功能；针对所述非管理型模块，根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务；针对所述管理型模块，根据所述第一类型的微服务对应的配置属性和所述第三类型的微服务对应的配置属性，对所述管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务；各微服务对应的配置属性是根据所述各微服务中包括的每个模块的属性信息得到的。

在一种可能的实现方式中，所述业务关联性是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的；

所述转换单元502具体用于：

将每个模块的数据实体符合第一设定规则的模块，和/或，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务；或者，将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

在一种可能的实现方式中，所述转换单元502具体用于：

将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务；意见将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务；所述第一候选微服务间的耦合度是根据所述第一候选微服务包括的模块间耦合度得到的；针对所述至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

本发明实施例还提供一种装置，所述装置包括：

存储器，用于存储软件程序；

处理器，用于读取所述存储器中的软件程序并执行上述各种可能的实现方式中所描述的应用程序系统建立的方法。

本发明实施例还提供一种计算机存储介质，所述存储介质中存储软件程序，该软件程序在被一个或多个处理器读取并执行时实现上述各种可能的实现方式中所描述的应用程序系统建立的方法。

本发明实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各种可能的实现方式中所描述的应用程序系统建立的方法。

综上所述，本发明实施例首先将用于实现应用程序内部功能的非网关型模块和用于实现应用程序与外部系统交互功能的网关型模块进行区分，相比于现有技术按照实现最小功能的模块对应用程序进行拆分的方式而言，本发明实施例能够减少微服务之间交互的次数，进而降低应用程序系统的研发工作量；其次，在信息安全的角度上，可以对网关型模块和非网关型模块采用不同的安全策略，从而提高应用程序的安全性；再次，针对网关型模块和非网关型模块，可以分别采用不同的预设规则将其转换为微服务，使得每个微服务都是高度自治的独立业务实体，每个微服务都是独立的服务进程，在对应用程序进行升级时，只需要更新对应的微服务进程，而不影响应用程序系统中的其它微服务的正常使用，大大降低版本更新部署对在用业务的影响；同时，在将非网关型模块转换成微服务的过程中，能够在满足现有业务需求的前提下，实现微服务的拆分粒度的合理性，遵循拆分颗粒度原则，在达成微服务实施目标的同时，尽量避免因对应用拆分成微服务的粒度太粗，使得服务内部的代码容易产生耦合，不能达成微服务改造实施目标的情况，也要避免因对应用拆分成微服务的粒度太细，导致接口数量增多，增加了运维或部署难度的问题。因此，一方面，本发明实施例通过将多个模块按照多种预设规则转换为微服务的方式，使得不同的微服务能够部署到不同的主机上，通过对各个微服务的性能进行监控，来提升核心进程的性能；另一方面，本发明实施例通过微服务的结构，在添加新的功能模块时，能够采用微服务的形式部署新的功能模块，从而可以加快部署速度，缩短部署的窗口时间，精简应用程序的结构，进而可以减轻后续开发维护的工作量，进而减少版本更新部署对在用业务的影响。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种计费平台系统的应用程序的建立方法，其特征在于，所述方法包括：

将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块；所述网关型模块用于实现所述第一应用程序系统与外部系统的交互；

根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务；

根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口；

根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

2.根据权利要求1所述的方法，其特征在于，所述根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，包括：

根据所述网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，得到至少一个第一类型的微服务。

3.根据权利要求1所述的方法，其特征在于，所述根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务，包括：

根据所述属性信息中的业务属性，将所述非网关型模块划分为管理型模块和非管理型模块；所述管理型模块用于实现应用程序的配置功能；

针对所述非管理型模块，根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务；

针对所述管理型模块，根据所述第一类型的微服务对应的配置属性和所述第三类型的微服务对应的配置属性，对所述管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务；各微服务对应的配置属性是根据所述各微服务中包括的每个模块的属性信息得到的。

4.根据权利要求3所述的方法，其特征在于，所述业务关联性是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的；

根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务，包括：

将每个模块的数据实体符合第一设定规则的模块，和/或，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务；或者，

将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

5.根据权利要求4所述的方法，其特征在于，所述将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务，包括：

将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务；

将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务；所述第一候选微服务间的耦合度是根据所述第一候选微服务包括的模块间耦合度得到的；

针对所述至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

6.一种计费平台系统的应用程序的建立装置，其特征在于，所述装置包括：

划分单元，用于将第一应用程序系统中包括的多个模块划分为网关型模块和非网关型模块；所述网关型模块用于实现所述第一应用程序系统与外部系统的交互；

转换单元，用于根据第一预设规则将所述网关型模块转换为至少一个第一类型的微服务，以及根据第二预设规则将所述非网关型模块转换为至少一个第二类型的微服务；

建立单元，用于根据各微服务中包括的每个模块的属性信息，确定所述各微服务之间的关联属性，并根据所述关联属性建立各微服务之间的接口；以及根据所述至少一个第一类型的微服务、所述至少一个第二类型的微服务及所述各微服务之间的接口，建立第二应用程序系统。

7.根据权利要求6所述的装置，其特征在于，所述转换单元具体用于：

根据所述网关型模块中每个模块对应的接入方式，将接入方式一致的模块转换为同一个微服务，得到至少一个第一类型的微服务。

8.根据权利要求6所述的装置，其特征在于，所述转换单元具体用于：

根据所述属性信息中的业务属性，将所述非网关型模块划分为管理型模块和非管理型模块；所述管理型模块用于实现应用程序的配置功能；针对所述非管理型模块，根据所述非管理型模块中每个模块之间的业务关联性，对所述非管理型模块中的多个模块进行划分，得到至少一个第三类型的微服务；针对所述管理型模块，根据所述第一类型的微服务对应的配置属性和所述第三类型的微服务对应的配置属性，对所述管理型模块中的多个模块进行划分，得到至少一个第四类型的微服务；各微服务对应的配置属性是根据所述各微服务中包括的每个模块的属性信息得到的。

9.根据权利要求8所述的装置，其特征在于，所述业务关联性是根据每个模块的属性信息中的数据实体、变化频度和耦合度中的一项或多项确定的；

所述转换单元具体用于：

将每个模块的数据实体符合第一设定规则的模块，和/或，将每个模块的变化频度符合第二设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务；或者，将每个模块的数据实体符合第一设定规则的模块，且，将每个模块的变化频度符合第二设定规则的模块，且，模块间耦合度符合第三设定规则的模块，转换为同一个微服务，得到至少一个第三类型的微服务。

10.根据权利要求9所述的装置，其特征在于，所述转换单元具体用于：

将每个模块的数据实体符合第一设定规则的模块，转换为同一个候选微服务，得到至少一个第一候选微服务；意见将耦合度符合所述第三设定规则的第一候选微服务，转换为同一个候选微服务，得到至少一个第二候选微服务；所述第一候选微服务间的耦合度是根据所述第一候选微服务包括的模块间耦合度得到的；针对所述至少一个第二候选微服务中的任一第二候选微服务，将所述第二候选微服务中变化频度符合第二设定规则的模块，转换为同一微服务，得到至少一个第三类型的微服务。

11.一种计算机可读存储介质，其特征在于，所述存储介质存储有指令，当所述指令在计算机上运行时，使得计算机实现执行权利要求1至5中任一项所述的方法。

12.一种计算机设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如权利要求1至5任一权利要求所述的方法。

Images