QUICK REVIEW
[论文解读] Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems
Alessandra Levcovitz, Ricardo Terra|arXiv (Cornell University)|May 10, 2016
Software System Performance and Reliability参考文献 6被引用 94
一句话总结
本文提出了一种技术,通过分析数据库表依赖关系、依赖图以及外观表访问路径,识别单体企业系统中的微服务候选。在750 KLOC的银行系统上应用该方法,成功将5个子系统中的4个识别为可行的微服务候选,实现了具有独立部署和技术创新灵活性的增量迁移。
ABSTRACT
The idea behind microservices architecture is to develop a single large, complex application as a suite of small, cohesive, independent services. On the other way, monolithic systems get larger over the time, deviating from the intended architecture, and becoming risky and expensive to evolve. This paper describes a technique to identify and define microservices on monolithic enterprise systems. As the major contribution, our evaluation shows that our approach was able to identify relevant candidates to become microservices on a 750 KLOC banking system.
研究动机与目标
- 为解决大型单体企业系统随时间推移变得难以维护和扩展的挑战。
- 为现有单体架构中识别可行的微服务候选提供系统化方法。
- 在不进行整体架构重构的前提下,实现微服务的增量迁移。
- 支持各服务的独立开发、部署和技术选型。
- 评估在实际企业系统中提取微服务的可行性与实际效益。
提出的方法
- 根据业务领域将数据库表映射到子系统,其中特别设立一个控制子系统用于非业务表。
- 构建依赖图,顶点包括外观、业务功能和数据库表,边表示调用和数据访问关系。
- 通过依赖图中的路径识别所有(外观,表)对,以追踪数据流和控制流。
- 按子系统对这些对进行分组,以隔离各业务领域的微服务候选。
- 根据访问模式、通信模式以及独立部署潜力评估每个候选。
- 排除跨子系统共享表的候选,或耦合度高的候选,以避免复杂重构。
实验结果
研究问题
- RQ1是否能够通过系统化技术在大型单体企业系统中识别出可行的微服务候选?
- RQ2所提出的方法在从单体代码库中隔离出高内聚、可独立部署的服务方面有多高效?
- RQ3在将特定子系统迁移至微服务时,面临哪些实际挑战和权衡?
- RQ4在不进行完整系统重构的前提下,微服务迁移能在多大程度上实现增量进行?
- RQ5由于架构约束,哪些子系统不适合进行微服务迁移?
主要发现
- 该技术在750 KLOC的银行系统中成功识别出5个子系统中的4个为适合迁移至微服务的候选。
- 依赖图分析有助于清晰识别服务边界和数据访问模式。
- 服务费、支票和短信渠道等子系统被视为良好候选,因其具有高内聚性和清晰的接口边界。
- 客户子系统未被推荐迁移,因其与超过50个API网关高度耦合,且收益与投入比过低。
- 共享数据库表的子系统被排除,因存在数据不一致风险和复杂重构问题。
- 该方法支持增量迁移,允许单体架构与微服务架构在生产系统中并存。
更好的研究,从现在开始
从论文设计到论文写作,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。