Page 162 - 《软件学报》2020年第11期

3478 Journal of Software 软件学报 Vol.31, No.11, November 2020

的是 4 个,最多的有 19 个.其中,4 个服务的方案简单地将系统按照原本的项目模块分成了“系统设置”、“内容管
理”、“办公自动化”和“代码生成”这 4 个部分,而 19 个服务的方案则对这 4 个部分做了更进一步的细化,比如将
“办公自动化”这个部分细化成了“请假”、“通告”和“审核”这 3 个服务.目前,在微服务拆分的粒度方面并没有权
威的方法论指导,需要视系统的实际需求和使用场景进行权衡.
随后,本文向实验参与者展示了 MSDecomposer 的使用方法和拆分结果.首先,5 位参与者都认可工具以场
景级别的测试用例作为数据拆分依据具有一定的合理性,且都认同相比于领域模型和其他设计模型,我们能够
更为轻松地获得这些测试用例.对 MSDecomposer 的拆分方案评分(满分 5 分),5 位参与者分别给出了 5 分、4
分、3.5 分、3 分和 3 分.令我们感到高兴的是,所有参与者都对 MSDecomposer 给出的拆分方案持认可的态度,
他们认为:生成的方案符合人的直觉,对帮助他们了解系统、得到最终的方案有很大的帮助.另外,参与者们都反
映 MSDecomposer 工具简单易学,能够迭代反馈,相比人工分析更加细致和高效.
4.3 讨 论
上述案例研究验证了本文提出的单体系统微服务拆分方法在实际系统的拆分中可以很好地运行,在更短
的时间内生成理想的微服务拆分方案.然而,本文的实验和方法还存在以下几点不足.
• 第一,参与对比实验需要具有软件工程和微服务领域的研究背景,本文寻找到的符合要求的实验参与
者人数较少,与实际从事微服务开发的从业人员相比,在实践经验等方面存在一定的差距,导致实验结
果缺乏足够的代表性.
• 第二,可以用于案例研究的开源单体系统很少,且数据库规模普遍较小.实际生产系统可能会有成百上
千张数据表,本文提出的方法能否在这样的系统上得出比较好的结果仍未可知,但至少提供了一种新
的思路.
• 最后,场景的划分对实验结果有一定的影响.由于本文的假设前提是同一场景中涉及的数据和代码倾
向于划分到同一个微服务中,所以划分场景、识别每个场景中包含的用户操作对于得出正确的拆分方
案十分重要.这要求测试用例的设计者对系统的功能和业务流程有一定程度的了解,如果对场景的识
别不够准确或不够全面,都可能对最终的结果产生负面的影响.

5 总 结
微服务系统相对于单体系统有着可扩展性强、复用性高等诸多优点,但从单体到微服务的拆分过程目前主
要依赖于人工分析,成本高、耗时长.本文提出了一种场景驱动、自底向上的单体系统微服务拆分方法,并在此
基础上实现了原型工具 MSDecomposer.拆分方法的输入为一组用户场景级别的测试用例和权重,通过分析系
统运行时监控日志、构建数据访问轨迹图和数据表图,再对数据表图进行聚类得到合适的数据拆分方案,最后
从数据表出发,自底向上搜索得到代码模块的拆分方案.最终的拆分方案给出了从数据表、SQL 语句、方法到
类的完整拆分建议,且中间过程中允许用户进行多个维度的反馈调整.实验验证了方法的可行性与拆分结果的
正确性,并且从实验参与者的反馈情况来看,这种半自动化的方法产生的结果的确可以作为微服务拆分的重要
参考,尤其是在系统逻辑比较复杂、数据表很多的情况下,将极大地减轻开发人员的决策负担.
由于目前的方法对于数据的拆分粒度限制在表的级别,而原单体系统由于数据库设计的问题可能存在一
张表含有几十甚至几百个字段,在进行微服务拆分时就可能涉及到拆表的操作,所以我们未来的一个工作方向
就是将数据拆分粒度细化到字段级别,从而得到更加准确和耦合度更低的微服务拆分方案.

References:
[1] Lewis J, Fowler M. Microservices: A definition of this new architectural term. 2014. https://martinfowler.com/articles/microser
vices.html
[2] Ford N. The state of microservices maturity. 2018. https://www.oreilly.com/programming/free/the-state-of-microservices-maturity.
csp