CN111651451A - 一种场景驱动的单体系统微服务拆分方法 - Google Patents

Abstract

本发明属于软件工程与微服务技术领域，具体为一种场景驱动的单体系统微服务拆分方法。本发明方法，首先通过监控典型应用场景测试用例的执行，动态分析获取单体系统运行时的方法调用和数据库操作信息，生成系统的数据访问轨迹图；然后对底层的数据表图进行加权和聚合，基于数据表之间的关联分析生成数据库拆分方案；再在数据访问轨迹图上进行搜索，产生相应的代码模块拆分方案。本发明以半自动化的方式，从现有代码和数据模式出发，将业务流程、方法调用链和数据表三者进行关联，使业务的独立性、代码的内聚/耦合性、数据间的关联度都成为数据库拆分依据，生成代码模块的拆分方案；可显著提升微服务拆分的决策速度，减轻开发人员决策负担。

Description

一种场景驱动的单体系统微服务拆分方法

技术领域

本发明属于软件工程与微服务技术领域，具体涉种单体系统微服务拆分方法。

背景技术

微服务是将一个大型复杂的软件系统分解成一组独立运行、以轻量级通信机制进行交互的相对较小的服务。这些服务围绕业务功能进行构建，可以独立开发、测试、部署和更新，以此带来的好处包括系统架构的解耦、单个服务的交付周期缩短、技术选型更灵活、可扩展性更好、复用性更高等等。

在企业实践中，许多微服务系统都是在单体架构的遗留系统基础上通过微服务拆分和改造形成的，其中的拆分决策（尤其是数据库拆分）对于微服务系统的架构质量有着很大的影响。前单体系统的微服务拆分决策主要依赖于架构人员和开发人员的分析和经验，整个过程成本高、耗时长、自动化程度低，相关的研究工作主要集中在经验总结和方法论上。已有的工具并不支持数据库的拆分且代码拆分粒度过大，同时需要人工分析或输入的数据量过多、不适用于大型单体系统的拆分。

发明内容

本发明的目的在于提供一种可显著提升微服务拆分决策速度的场景驱动的单体系统微服务拆分方法。

本发明提出的场景驱动的单体系统微服务拆分方法，基于测试驱动的理念，首先通过监控典型应用场景测试用例的执行，动态分析获取单体系统运行时的方法调用和数据库操作信息，生成系统的数据访问轨迹图；然后根据数据访问轨迹图对底层的数据表图进行加权和聚合，基于数据表之间的关联分析生成数据库拆分方案；再在数据访问轨迹图上自底向上进行搜索，产生相应的代码模块拆分方案。整体流程如图1所示，具体步骤如下。

（1）准备测试用例。即准备一组覆盖了系统主要业务流程和功能的用户使用场景级别的测试用例；一个用例对应于一个用户场景，一个场景包含若干个界面输入或点击操作；每个测试用例对应一个用例权重，权重大小根据对应场景的重要度进行设置。

（2）构建数据访问轨迹图。根据原单体系统的运行时数据构建数据访问轨迹图，如图2所示，具体包括以下子步骤：

1）在单体系统中配置监控工具，顺序执行测试用例，每次执行测试用例时输入对应的场景名与权重；

2）获取系统运行测试用例期间的方法调用和数据访问日志，并将其与用户场景相关联，即每条监控日志都记录了其对应的场景名、场景标识和场景权重；日志共有三种不同的类型，分别用于记录方法调用时的方法签名、执行数据库访问时的SQL（Structured QueryLanguage，结构化查询语言）语句和数据操作时对应的数据表；

3）根据监控日志构建数据访问轨迹图，如图2所示，图中每个场景关联若干请求，每个请求对应一条方法调用链；一条方法调用链是若干方法的执行序列，其中有些方法会关联SQL 节点，这说明该方法执行过程中调用了这些SQL 语句；而SQL 节点会关联若干个数据表节点（在图2中以虚线箭头表示），代表这条SQL 语句在实际执行过程中访问了这些数据表中的数据。

（3）生成微服务拆分方案。根据数据访问轨迹图，结合微服务化拆分有关的多个考量维度，生成一张无向加权的数据表图，然后通过对数据表进行聚类划分，得到数据表的划分方案，最后在数据访问轨迹图中自底向上进行搜索，获取与数据表拆分结果相符合的代码拆分方案。具体包括以下子步骤：

1）根据数据访问轨迹图，加权累加任意两个数据表出现在同一条SQL语句、同一条方法调用链或同一个用户场景下的场景权重，得到数据表之间的关联度矩阵。两数据表之间的关联权重越大，越倾向于将它们划分到同一个微服务中；

2）计算每个数据表分别在所有场景、方法调用链和SQL语句中出现的比例，将这三个比例加权累加得到数据表的数据共享度。按照0.08到0.3的比例提取共享度高的数据表，再分别从SQL、调用链和场景三个级别计算提取出的共享表之间的数据依赖度，将彼此间数据依赖度满足共享群组提取条件（参见“具体实施方法”第三点的第四小点）的共享表划分到同一个共享群组。以此得到若干个共享群组，这些群组倾向于单独提取出来作为一个微服务；

3）对数据表关联度矩阵做出调整，对于连接同一个共享群组中两张表的边，保持比较大的权重（例如权重调整到0.8以上，或0.9及以上（权重最大值为1）），增加它们被划分到同一个微服务的概率；削减与该表相连的其它边的权重，降低该边相连的两张表被划分到同一个微服务的概率；

4）对数据表关联度矩阵进行聚类划分，同时结合拆分开销，选择最优的数据库拆分方案；

5）对于每个服务中的数据表，在图2的数据访问轨迹图中顺着调用关系自底向上搜索访问了这些数据表的SQL 语句、方法和类节点，得到和数据库拆分对应的代码拆分方案；最终的拆分方案包含了每个微服务所含的数据表、SQL语句、方法和类，并标识出需要进行拆分的SQL语句、方法和类。

（4）反馈调整。用户反馈迭代式地对结果做出微调，从而起到间接优化权重矩阵的作用，令最终的拆分方案更符合实际需求，具体有以下四种反馈调整方式：

1）调整共享群组，可以人工删除那些明显不适合单独提取出来的表，避免生成权重矩阵时错误地削减了相应边的权重，也可以手动添加或者修改共享群组；

2）调整模块度与拆分开销的比例，将拆分开销控制在用户可以接受的范围之内；

3）调整维服务数量，选择合适的拆分粒度；

4）手动调整个别数据表的归属。

本发明以半自动化的方式，从现有的代码和数据模式出发，将业务流程、方法调用链和数据表三者进行关联，使得业务的独立性、代码的内聚/耦合性、数据间的关联度都成为数据库拆分依据，进而根据数据库拆分方案生成代码模块的拆分方案，从而显著提升微服务拆分的决策速度，减轻开发人员的决策负担。

附图说明

图1为本发明的单体系统微服务拆分方法的流程图。

图2为本发明所构建的数据访问轨迹图。

具体实施方式

以下介绍针对使用Spring框架的单体系统的微服务拆分的具体实施方法。

（1）准备测试用例。主要由对系统比较了解的开发人员或测试人员进行用户场景划分、提供测试用例和标记权重。每个测试用例的权重大小默认为1，对于一些比较重要或者使用频率很高的业务场景，例如火车站订票系统的订票场景、购物网站的下单流程等，可以适当增加权重。

（2）构建数据访问轨迹图。通过改造已有的应用性能监控工具Kieker，拦截JDBC执行的SQL 语句，再使用语法解析工具JSqlParser 获取SQL 语句操作的数据表名，实现将方法调用链和操作的数据相关联。同时，在监控工具中新增场景信息输入页面，使得整个用例执行期间生成的每条日志都带有场景名和权重信息。使用Neo4j数据库存储数据访问轨迹图和项目的静态结构。

（3）生成微服务拆分方案。

1）数据关联度定义：定义两数据表在场景/方法调用链/SQL层次的数据关联度分别为同时操作了这两张表的场景/方法调用链/SQL语句的累加权重与操作其中任意一张表的场景/方法调用链/SQL语句的累加权重之比。

2）数据共享度定义：定义单个数据表在场景/方法调用链/SQL层次的数据共享度分别为操作该表的场景/方法调用链/SQL语句数量占总场景/方法调用链/SQL语句数量的比例。

3）数据依赖度定义：定义表A对表B的场景/方法调用链/SQL依赖度分别为同时操作A、B两张表的场景/方法调用链/SQL语句数量占操作表A的场景/方法调用链/SQL语句数量的比例。

4）共享群组提取条件（两共享表A和B之间的数据依赖度满足以下任一条件即可被划分为同一共享群组）：

条件一：表A对表B的SQL依赖度与表B对表A的SQL依赖度之和大于1.4；

条件二：表A对表B的方法调用链依赖度与表B对表A的方法调用链依赖度之和大于1.6；

条件三：表A对表B的场景依赖度与表B对表A的场景依赖度之和大于2；

条件四：表A对表B的SQL依赖度、方法调用链依赖度与表B对表A的SQL依赖度、方法调用链依赖度之和大于2.8，并且表A对表B的场景依赖度与表B对表A的场景依赖度之和大于1；

5）使用Girvan-Newman算法进行数据表图的聚类，得到若干个粒度不同的数据表划分方案。计算每个拆分方案对应的模块度和需要拆分的SQL语句、方法和类的数量，结合模块度和拆分开销选择评分最高的一个方案作为最终的数据库拆分方案；

6）根据数据库拆分方案，在数据访问轨迹图中自底向上进行搜索，将操作了同一个分组中数据表的SQL语句和方法划分到同一个微服务中。如果一个SQL语句、方法或类操作了不同分组的数据表，则认为需要对该SQL语句、方法或类进行拆分。

（4）反馈调整。四种反馈调整的策略作用于整个方法流程的不同时期。其中“调整共享群组”直接影响数据表关联度矩阵，需要重新运行数据表聚类算法；“调整模块度与拆分开销的比例”和“调整服务数量”后，在已有的多个数据表划分方案中根据调整后的参数进行选择，不需要重新运行聚类算法；“手动调整个别数据表所归属的服务”后数据库表划分方案已经确定，可以据此直接给出相应的代码拆分方案。

本发明方法对四个不同领域的开源软件系统进行了案例研究和对比实验，其中人工拆分在四个系统上的平均耗时分别是204.3分钟、265.3分钟、237分钟和296分钟，而本方法的最终拆分耗时分别是93分钟、125分钟、125分钟和178分钟，一定程度上表明本方法与人工拆分相比耗时更少。同时，本方法的拆分粒度可以细化到方法级别，且能够给出包含数据表和SQL语句的完整的微服务拆分方案。另外，本方法自动化程度高，所需输入数据形式简单、易于获得。

Claims (5)

1.一种场景驱动的单体系统微服务拆分方法，其特征在于，首先通过监控典型应用场景测试用例的执行，动态分析获取单体系统运行时的方法调用和数据库操作信息，生成系统的数据访问轨迹图；然后根据数据访问轨迹图对底层的数据表图进行加权和聚合，基于数据表之间的关联分析生成数据库拆分方案；再在数据访问轨迹图上自底向上进行搜索，产生相应的代码模块拆分方案；具体步骤如下：

（1）准备测试用例：准备一组覆盖了系统主要业务流程和功能的用户使用场景级别的测试用例；一个用例对应于一个用户场景，一个场景包含若干个界面输入或点击操作；每个测试用例对应一个用例权重，权重大小根据对应场景的重要度进行设置；

（2）构建数据访问轨迹图：根据原单体系统的运行时数据构建数据访问轨迹图；

（3）生成微服务拆分方案：根据数据访问轨迹图，结合微服务化拆分有关的多个考量维度，生成一张无向加权的数据表图，然后通过对数据表进行聚类划分，得到数据表的划分方案，最后在数据访问轨迹图中自底向上进行搜索，获取与数据表拆分结果相符合的代码拆分方案；

（4）反馈调整：用户反馈迭代式地对结果做出微调，从而起到间接优化权重矩阵的作用，令最终的拆分方案更符合实际需求。

2.根据权利要求1所述的单体系统微服务拆分方法，其特征在于，步骤（2）所述构建数据访问轨迹图的具体流程为：

1）在单体系统中配置监控工具，顺序执行测试用例，每次执行测试用例时输入对应的场景名与权重；

2）获取系统运行测试用例期间的方法调用和数据访问日志，并将其与用户场景相关联，即每条监控日志都记录了其对应的场景名、场景标识和场景权重；日志共有三种不同的类型，分别用于记录方法调用时的方法签名、执行数据库访问时的SQL语句和数据操作时对应的数据表；

3）根据监控日志构建数据访问轨迹图，图中每个场景关联若干请求，每个请求对应一条方法调用链；一条方法调用链是若干方法的执行序列，其中有些方法关联SQL 节点，这说明该方法执行过程中调用了这些SQL 语句；而SQL 节点关联若干个数据表节点，代表这条SQL 语句在实际执行过程中访问了这些数据表中的数据。

3.根据权利要求2所述的单体系统微服务拆分方法，其特征在于，步骤（3）所述生成微服务拆分方案的具体流程为：

1）根据数据访问轨迹图，加权累加任意两个数据表出现在同一条SQL语句、同一条方法调用链或同一个用户场景下的场景权重，得到数据表之间的关联度矩阵；两数据表之间的关联权重越大，越倾向于将它们划分到同一个微服务中；

2）计算每个数据表分别在所有场景、方法调用链和SQL语句中出现的比例，将这三个比例加权累加得到数据表的数据共享度；按照0.08到0.3的比例提取共享度高的数据表，再分别从SQL、调用链和场景三个级别计算提取出的共享表之间的数据依赖度，将彼此间数据依赖度满足共享群组提取条件的共享表划分到同一个共享群组；以此得到若干个共享群组，这些群组倾向于单独提取出来作为一个微服务；

3）对数据表关联度矩阵做出调整，对于连接同一个共享群组中两张表的边，保持比较大的权重，增加它们被划分到同一个微服务的概率；削减与该表相连的其它边的权重，降低该边相连的两张表被划分到同一个微服务的概率；

4）对数据表关联度矩阵进行聚类划分，同时结合拆分开销，选择最优的数据库拆分方案；

5）对于每个服务中的数据表，在数据访问轨迹图中顺着调用关系自底向上搜索访问这些数据表的SQL 语句、方法和类节点，得到和数据库拆分对应的代码拆分方案；最终的拆分方案包含每个微服务所含的数据表、SQL语句、方法和类，并标识出需要进行拆分的SQL语句、方法和类；

所述数据表之间的关联度，是指两数据表在场景/方法调用链/SQL层次的数据关联度分别为同时操作了这两张表的场景/方法调用链/SQL语句的累加权重与操作其中任意一张表的场景/方法调用链/SQL语句的累加权重之比例；

所述数据共享度，是指单个数据表在场景/方法调用链/SQL层次的数据共享度分别为操作该表的场景/方法调用链/SQL语句数量占总场景/方法调用链/SQL语句数量的比例；

所述数据依赖度，是指表A对表B的场景/方法调用链/SQL依赖度分别为同时操作A、B两张表的场景/方法调用链/SQL语句数量占操作表A的场景/方法调用链/SQL语句数量的比例。

4.根据权利要求3所述的单体系统微服务拆分方法，其特征在于，步骤（3）所述中所述共享群组提取条件为：两共享表A和B之间的数据依赖度满足以下任一条件即可被划分为同一共享群组：

条件一：表A对表B的SQL依赖度与表B对表A的SQL依赖度之和大于1.4；

条件二：表A对表B的方法调用链依赖度与表B对表A的方法调用链依赖度之和大于1.6；

条件三：表A对表B的场景依赖度与表B对表A的场景依赖度之和大于2；

条件四：表A对表B的SQL依赖度、方法调用链依赖度与表B对表A的SQL依赖度、方法调用链依赖度之和大于2.8，并且表A对表B的场景依赖度与表B对表A的场景依赖度之和大于1。

5.根据权利要求3所述的单体系统微服务拆分方法，其特征在于，步骤（4）所述反馈调整；具体有以下四种反馈调整方式：

1）调整共享群组，由人工删除那些明显不适合单独提取出来的表，避免生成权重矩阵时错误地削减相应边的权重，或者手动添加或者修改共享群组；

2）调整模块度与拆分开销的比例，将拆分开销控制在用户可以接受的范围之内；

3）调整维服务数量，选择合适的拆分粒度；

4）手动调整个别数据表的归属。

Images