Page 158 - 《软件学报》2020年第11期
P. 158
3474 Journal of Software 软件学报 Vol.31, No.11, November 2020
在“手动调整页面”,用户可以拖动标签、改变任意数据表的服务归属.点击其中一个微服务标题,页面右上
角部分会显示与该服务包含的数据表相关联的代码结构,粒度精确到方法级别,且与原单体系统的包结构相对
应.页面右下角显示该服务包含的所有 SQL 语句、方法和类,其中,箭头标识出的表示需要进行拆分.另外,存在
一些可以监控到、但没有与任何数据表相关联的方法和类(比如某些读取缓存、直接返回的场景),由于没有实
际执行 SQL 语句,无法依据数据关联将它们划分到任何一个服务中,所以 MSDecomposer 将这些代码收集到一
个单独的微服务中,设计人员或实施拆分的人员可以根据实际情况自行决定这些代码的服务归属.
3.4 算法性能测试
在完成监控工具配置、场景整理和数据收集后,实际使用工具的时间很短,其中耗时最长的部分在于使用
G-N 算法对数据表图进行聚类.由于 G-N 算法在边介数的计算上时间复杂度很高,所以这种算法一般用来处理
几百个节点的中小规模网络.在拥有 2.5GHz CPU,8GB RAM 的计算机上单独运行 G-N 算法,随机生成含有 20
个~100 个顶点的数据表图,以 44%的比例生成点与点之间的边,边的权重为大于 0 小于 1 的随机值.其中,44%的
比例值是根据实际数据表图的边数与对应的全连接图的边数之比计算出的平均值.相同顶点数量的实验重复
10 次,求得平均边数与平均耗时,得到性能测试结果见表 2.
Table 2 Performance test results of G-N algorithm
表 2 G-N 算法性能测试结果
顶点数量 平均边数 平均耗时(ms)
20 82 588.4
30 193 1 853.2
40 343 5 050.7
50 542 8 332.8
60 779 15 142.4
70 1 055 30 102.2
80 1 383 59 033.2
90 1 759 119 139.6
100 2 198 201 506
可以看出,100 个顶点以内的数据表图,G-N 算法可以在 4min 内得出结果.我们认为,这样的性能对于普通的
中小型项目是完全可以接受的.对于一些数据库规模很大、有成百上千张数据表的项目,人工分析其代码结构
和数据关联的难度也会相应增大,据我们所知,可能需要花费几周甚至几个月的时间.相比之下,几个小时或者
几天的算法运行时间并不会让人觉得不可忍受.当然,在这种情况下,也可以使用其他算法复杂度更低的聚类算
法进行替换,例如谱聚类算法 [31] .实际上,MSDecomposer 已经内置了谱聚类和其他几种算法的实现,但是这些算
法由于并不会像 G-N 算法一样生成社区结构树,也就无法实现基于社区结构树的反馈调整策略.
4 案例研究
本文选取了 4 个开源软件系统进行案例研究,研究系统分属电商、ERP(企业资源计划)、线上测试和社交
博客等个不同的领域类型,项目规模在开源软件系统中相对较大.下面首先以其中一个系统 Spring JPetStore 为
例,直观地给出本文所提出的微服务拆分方法的输入输出和中间结果,通过与文献[27]中的方法结果和适用范
围进行比较,验证本文方法可以得出正确合理、可解释、且更加精准的拆分方案.案例研究的第二部分挑选了 5
位具有微服务研究背景和开发经验的硕士研究生,对 4 个实验系统进行了人工分析并给出微服务拆分方案.通
过对比,总结本文提出的方法有哪些优缺点,且其是否符合微服务开发者的经验直觉、是否能够真正地加速拆
分决策过程.最后,讨论部分指出了本方法的几点局限性.
4.1 Spring JPetStore案例分析
Spring JPetStore [40] 是一个基于 Spring [41] ,Spring MVC 和 Mybatis [42] 框架实现的小型宠物商店系统,包含了
用户认证、商品展示、下订单等一系列电商网站必备的功能模块.该系统最早是 Sun 公司开发的一个项目示例,
用于展示如何使用 Mybatis 框架.由于其结构简单、功能完善,常被用作实验和教学.本文以这个经典的电子商