微服务架构近年来作为开发复杂应用的手段已获得广泛关注。这种架构风格将软件组织为小型、模块化且独立部署的服务，每个服务在独立进程中运行，并通过轻量级、明确定义的机制进行通信以实现业务目标。尽管文献中已识别出诸多优势，但 MSA 的采用仍被视为重大挑战，无论是在开发新系统还是软件现代化方面。
关于软件现代化问题，研究表明，组织对采用 MSA 持抵触态度。这种抵触主要归因于两个因素：
- 该架构风格被视为单纯的"炒作"；
- 缺乏对其系统实施该架构风格后现代化过程复杂性和优势的认知。
还有研究表明，向微服务架构的转型绝非单纯的技术决策，必须与系统最初设计的业务目标保持一致。因此，仓促的技术决策可能导致过度拆分，这种做法虽然有利于实现自主性，却往往忽视了业务层面的影响，而这种影响通常具有负面效应。
传统系统进行微服务架构的转型存在技术与业务双重挑战。技术层面的难题包括系统耦合与维护成本，而业务层面的痛点则体现在发布周期过长和生产力低下。这些问题的根源在于传统系统采用的计算资源已严重过时，复杂度急剧攀升，导致其修改、扩展和维护难度倍增，无法适应当今的计算环境。
@Article{asi8040086,
AUTHOR = {Fávero, Lucas Fernando and Almeida, Nathalia Rodrigues de and Affonso, Frank José},
TITLE = {A Systematic Mapping Study on the Modernization of Legacy Systems to Microservice Architecture},
JOURNAL = {Applied System Innovation},
VOLUME = {8},
YEAR = {2025},
NUMBER = {4},
ARTICLE-NUMBER = {86},
URL = {https://www.mdpi.com/2571-5577/8/4/86},
ISSN = {2571-5577},
ABSTRACT = {Microservice architecture (MSA) has garnered attention in various software communities because of its significant advantages. Organizations have also prioritized migrating their legacy systems to MSA, seeking to gather the intrinsic advantages of this architectural style. Despite the importance of this architectural style, there is a lack of comprehensive studies in the literature on the modernization of legacy systems to MSA. Thus, the principal objective of this article is to present a comprehensive overview of this research theme through a mixed-method investigation composed of a systematic mapping study based on 43 studies and an empirical evaluation by industry practitioners. From these, a taxonomy for the initiatives identified in the literature is established, along with the application domain for which such initiatives were designed, the methods used to evaluate these initiatives, the main quality attributes identified in our investigation, and the main activities employed in the design of such initiatives. As a result, this article delineates a process of modernization based on six macro-activities, designed to facilitate the transition from legacy systems to microservice-based ones. Finally, this article presents a discussion of the results based on the evidence gathered during our investigation, which may serve as a source of inspiration for the design of new initiatives to support software modernization.},
DOI = {10.3390/asi8040086}
}背景和相关工作
"微服务架构"（Microservice Architecture，简称 MSA）这一术语被用来指代一种将软件应用设计为独立可部署服务集合的特定方法。简而言之，这是一种将单一应用开发为多个小型服务集合的开发方式，每项服务均运行在独立进程并通过轻量级机制（通常为 HTTP 资源 API）进行通信。这些服务围绕业务功能构建，可通过全自动部署工具独立部署。其核心特征是采用极简化的集中式管理，服务可使用不同编程语言编写并采用多样化数据存储技术。
软件现代化可定义为一种系统转型过程，通过调整或重构软件系统以满足新用户需求并适应新兴市场技术。在此过程中，微服务架构（MSA）展现出多项优势，包括维护便利性、更快的上市周期以及高可扩展性。尽管存在多种现代化方法，但基于微服务从零开发应用的可行性仍存疑，这主要受限于成本和时间因素。虽然已有相关研究尝试，但由于缺乏涵盖整个流程的完整指南，将系统分解为微服务仍是一项挑战。究其原因，需要通过多次迭代才能确定合适的微服务规模。
迁移并非混沌------一个由六个宏观活动组成的清晰路线图
这项研究最重要的成果，莫过于在综合了 43 项独立研究后，提炼出了一个连贯的、由六个宏观活动组成的现代化流程。研究指出，在此之前，行业内普遍存在"方法论理解的匮乏"，而这个流程框架的出现，恰好填补了这一空白。
这个清晰的路线图包括以下六个核心活动：
- 规划 (Planning) 此阶段不仅是定义目标和资源，更是确立迁移的商业价值主张。它为整个项目奠定战略基础，确保技术努力与业务成果挂钩。
说白了，规划就是制定实现目标所需的战略、资源和方案，而本案例的目标正是系统现代化。调研数据显示，当规划现代化项目时，如果能预判潜在挑战并确保在既定时间表和资源范围内达成目标，组织和开发团队更容易取得成功。从组织层面来看，证据表明必须采用合适的方法论和基础设施来推进现代化实践。在开发方面，调研结果建议团队应建立开发文化（例如单元测试）。从这个角度看，培训可以成为有效手段，既能协调组织利益与开发实践，又能推动基于微服务的应用开发与现代化进程。
- 分析 (Analysis) 在此阶段，团队需要像考古学家一样深入研究遗留系统的构件------源代码、文档、数据库和隐晦的业务逻辑，以构建一幅完整的现状图。
分析活动可被视为现代化的初始阶段，因为正是在此过程中，开发团队将深入了解遗留系统的各类组件，包括二进制系统、源代码仓库和文档资料，这些均可作为信息来源。因此，预计将积累足够数量的信息，以帮助确定分解流程的合适起点。这包括识别遗留系统的不同组件及其功能、理解其业务领域边界，以及分析上述组件之间的依赖关系。总之，这一步骤对遗留系统成功迁移到微服务架构至关重要，因为它为该架构风格的设计与实施奠定了基础。
- 分解 (Decomposition) 这是最具深远影响的架构步骤。在这里，你将划定服务边界，而这些边界将在未来数年内定义团队的沟通模式和认知负荷。划分失误所引入的复杂性，可能比你试图摆脱的单体系统还要糟糕。
证据显示与该活动相关的主要挑战在于确定微服务的最佳规模。这是因为遗留系统必须被划分为更小的单元，这些单元需具备低耦合和高内聚性。换言之，每个微服务必须负责一个限定的上下文，提供一组具有明确范围且高度协调的功能，以满足特定的业务需求。尽管可以采用（半）自动化技术辅助微服务分解，但首要建议是优先处理对遗留系统向现代系统过渡影响最小或风险最低的功能。本质上，这一过程涉及识别具有最大价值且外部依赖性最小的潜在微服务。尽管微服务分解不存在单一方法论，但领域驱动设计（DDD）是一种广泛采用的方法，用于促进遗留系统向微服务架构（MSA）的转型。
- 开发 (Development) 在确定了微服务的划分后，开发团队开始构建、实现并测试各个独立的微服务，将理论上的架构蓝图转化为可运行的代码。
在全面理解旧系统架构并制定初步解决方案后，开发团队即可着手微服务开发。就开发方式而言，将旧系统迁移到微服务架构主要有两种路径：一是从零开始重构旧系统，二是从旧源代码中提取微服务（即功能模块）。我们的映射分析表明，对于包含高价值遗留代码的旧系统，第二种方案是最推荐的解决方案。与此同时，必须强调的是，在微服务开发过程中，必须终止旧系统的前一版本，以避免因功能模块分散在不同位置而引发的维护问题。此外，这些发现还表明，微服务开发应遵循"每个团队专注一个微服务"的原则，确保每个微服务解决单一特定问题。因此，完成该活动后，基于微服务的系统必须具备完整功能并做好发布准备。
- 集成 (Integration) 此阶段需要将新开发的各个微服务通过定义良好的 API 组合并同步起来，形成一个功能完整、有凝聚力的应用，确保它们能像一个交响乐团一样协同工作。
在集成活动中，微服务需要被组合并同步，以形成功能完整且协调一致的应用程序。在此过程中，微服务通过API或其他通信机制建立连接，确保系统整体运行所需的数据和信息交换。此外，该活动还可能涉及将现代化系统（即微服务）与其他外部系统或组件进行集成。微服务的集成能够验证微服务间的交互，并获取与外部系统通信的参数。在此阶段，任何不兼容或不一致的问题都能被识别并修正，确保集成后的应用程序稳定可靠。集成还可能涉及建立持续部署管道和流程自动化，以促进微服务在开发、测试和生产等不同环境中的分发。完成此活动后，现代化软件将准备好部署并可供最终用户使用。
- 监控 (Monitoring) 由于微服务天然的分布式特性，监控被视为"一等公民"任务。它不再是事后附加的功能，而是新架构的"中枢神经系统"，对于保障系统的健康、性能和可靠性至关重要。
在微服务架构（MSA）下，这类系统的分布式架构和复杂特性要求必须做到全面掌控。考虑到多个微服务之间的交互及其在不同环境中的部署，必须对每个组件的状态及其与其他微服务的交互保持全面可见性。因此，微服务环境中的监控通常涉及收集和分析性能相关指标，包括响应时间、错误率、资源利用率（如CPU、内存和网络）以及可用性。这些指标会实时监测，并可通过仪表板和报告查看，从而为系统健康状况提供有价值的洞察，帮助识别瓶颈、故障和优化机会。此外，监控还能检测并预警异常和潜在问题，使运维和开发团队能够及时采取纠正措施，最大限度减少对终端用户的影响。在微服务环境中实施有效的监控系统时，必须采用专门用于收集、存储和分析监控数据的工具与平台，以及旨在使系统在出现问题时更易理解与诊断的可观测性实践。
对于技术负责人和架构师而言，这份路线图远不止是一个理论模型，更是一个强大的沟通工具。你可以用它来构建你的迁移提案，为从分析到监控的每个阶段申请资源提供正当理由，并与那些可能低估了其中复杂性的业务方设定清晰的期望。
惊人的盲点------近半数研究忽视了关键质量属性
如果说迁移是一项业务决策，那么业务成功的衡量标准往往直接与可用性、可伸缩性等质量属性挂钩。但令人震惊的是，这篇论文研究发现在被分析的 43 项研究中，有 19 项（占 44.19%）没有提供任何在其方案中采纳质量属性的证据。
监测通常通过定期对监控系统管理的每个微服务进行健康检查来实现。因此，有必要根据各应用领域的需求，制定一套用于评估现代化软件中每个微服务健康状况的参数标准。在现代化系统（即微服务架构）中可监测的指标中，性能、可靠性、响应时间和可用性被确定为可通过仪表板监控的质量属性。通过运用监控系统评估各微服务的质量水平，该系统不仅能对微服务进行排序，还能提供符合用户需求或需要扩展的潜在微服务清单。
Grafana（https://grafana.com）和 Wavefront (https://github.com/wavefrontHQ/wavefront-spring-boot）是可行的解决方案，不仅能监测上述属性，还能实现基于微服务应用的全面可观测性。通过采用上述解决方案，基于微服务的应用可实现更敏捷的问题检测、现代化监控、瓶颈识别及发布敏捷性等优势。
这一发现是一记关键的警钟。启动一个没有预先定义质量属性和健壮监控体系的微服务架构，就如同发射一枚没有导航系统的火箭。初期的升空或许看起来很成功，但灾难性的失败将不再是"是否"会发生的问题，而是"何时"发生的问题。这些属性是不可协商的先决条件，而不是上线后的增强功能。
结论：带着新见解前行
这篇论文为我们拨开了围绕微服务迁移的重重迷雾，提供了基于证据的清晰洞察。总而言之，三个非显而易见的真理浮出水面，应当能指引每一个未来的迁移项目：
- 一个清晰的、由六个步骤组成的迁移路线图是存在的，可以作为我们行动的指南。
- 迁移必须由业务战略驱动，而不仅仅是技术潮流。
- 忽视关键的质量属性是一个普遍存在且极其危险的陷阱。