单体架构和微服务是构建应用程序的两种基本方法。有些人认为它们分别是传统和现代的。但这并不完全正确。在它们之间进行选择是一个非常复杂的问题，两者都有其优点和缺点。 大多数新应用程序不需要从一开始就采用微服务。从单体开始，然后如果发现有益，再切换到微服务，这样会更快、更简单、更便宜。 随着时间的推移，单体应用变得越来越难以维护，一些团队决定解决问题的唯一方法是通过将应用拆分为微服务来开始重构。其他团队做出这一决定只是因为“微服务很酷”。这个过程需要花费大量时间，有时甚至会带来更多的维护开销。在开始之前，务必仔细考虑所有利弊，并确保已达到当前单体架构的限制。请记住，拆分比构建更容易。 在本文中，我们不会将单体架构与微服务进行比较。相反，我们将讨论可帮助您实现以下目标的注意事项、模式和原则： 充分利用当前的整体架构并做好潜在分解为微服务的准备； 提供从整体到微服务的无缝迁移； 了解微服务迁移还可能带来哪些变化。 模块化整体式 您应该做的第一件事是查看您的项目结构。如果您没有模块，我强烈建议您考虑它们。它们不会让您将架构更改为微服务（这很好，因为我们希望避免所有相应的维护），但可以从中获得许多优势。 根据项目构建自动化工具（例如 maven、gradle 或其他），您可以将项目拆分为单独的独立模块。某些模块可能与其他模块通用，而其他模块可能封装特定领域或特定于功能，从而为您的应用程序带来独立的功能。 它将给您带来以下好处： 分离应用程序的各个部分。 功能可以独立开发，从而最大限度地减少冲突。 新人入职变得更加容易，因为他们不需要深入整个项目；相反，他们可以从孤立的部分开始。 改进测试，因为现在您可以单独测试每个模块。 如果您最终需要迁移到微服务，那么您已经拥有非常坚实的基础。 如您所见，模块化单体是两全其美的方法。这就像在单个单体内运行独立的微服务，但避免了附带的微服务开销。您可能遇到的限制之一就是无法独立扩展不同的模块。您将拥有与负载最大的模块所需的单体实例数量一样多的实例，这可能会导致过度的资源消耗。另一个缺点是使用不同技术的局限性。例如，您不能在模块化单体中混合使用 Java、Golang 和 Python，因此您只能坚持使用一种技术（通常这不是问题）。 绞杀榕图案 想想 Strangler Fig 模式。它的名字来自一棵环绕并最终取代其宿主的树。同样，该模式建议您将旧应用程序的各个部分逐一替换为新服务，从而在不造成重大中断的情况下对旧系统进行现代化改造。 您无需尝试一次性进行风险较大的全面改造，而是逐步更新系统。这种方法在处理大型、复杂的整体系统时非常有用，因为这些系统过于笨重，无法一次性更换。通过采用 Strangler Fig 模式，团队可以逐步淘汰旧系统，同时促进新系统的发展，最大限度地降低风险，并确保持续交付价值。 要实现 Strangler Fig 模式，需要遵循三个步骤： 在这里，您要确定从整体架构中提取哪些部分并将其实现为单独的微服务。使用现代技术重写此部分并解决以前实现的问题。抓住机会做得更好。 转型。 当新的微服务准备好投入生产时，您可以在基础架构中运行它，同时保留旧实现。您可以按一定比例分配流量，逐渐将越来越多的流量转移到新实现，但您始终可以使用以前的版本作为回滚。 共存。 一段时间后，当您认为新的微服务足够可靠时，将所有流量移至新的微服务并删除遗留的微服务。 消除。 通过这三个步骤，您将逐渐将整体式架构分解为微服务。 使用 Strangler Fig 图案的主要好处包括： 此模式允许您逐步过渡，而不是大费周章地开始耗时、繁重且风险很大的完整系统改造。您可以慢慢更新系统，并将此转换与功能开发计划同步。例如，您可以找到某个功能开发将严重影响整体系统的一部分，并将其选为微服务迁移的候选。 逐步迁移。 此好处来自前面的陈述。现代化过程不会阻止您的团队持续交付新功能。当一个团队开发新功能时，另一个团队重构独立模块。 持续交付。 Fig 模式可帮助团队专注于系统的特定部分。这种专注使团队能够更加关注特定领域的细节，尽早发现潜在问题，并最大限度地减少对应用程序的整体影响。 风险缓解。Strangler 问题和注意事项 在应用 Strangler Fig 模式时，您应该仔细规划迁移策略。其中包括确定首先要替换哪些组件、确保新旧部件之间的正确集成以及保持一致的数据模型。团队还应建立清晰的沟通渠道和监控系统，以跟踪每次替换的进度和影响。 微服务迁移的影响 正如我们之前所讨论的，过渡到微服务带来了好处。然而，它也使许多其他事情变得更加困难和昂贵。 例如，QA 和开发团队可能会面临无法再在本地机器上进行测试的情况，因为在本地运行多个微服务的能力有限。或者您的日志可能变得不那么有洞察力，因为现在不是由一个服务处理单个流程，而是由多个服务处理它。因此，要查看完整的日志序列，您需要实施适当的检测和跟踪。 让我们讨论一下在微服务转型开始之前您应该考虑和计划的一些关键方面。 部署和基础设施 整体式架构和微服务具有不同的最低基础设施要求。 运行单体应用程序时，通常可以维护更简单的基础架构。虚拟机或 PaaS 解决方案（例如 AWS EC2）等选项就足够了。此外，您可以手动或使用简单的工具处理大部分扩展、配置、升级和监控。因此，您可以避免复杂的基础架构设置，并依靠开发人员或支持工程师，而无需广泛的 DevOps 专业知识。 然而，采用微服务架构改变了这种动态。随着服务数量的增长，手动、动手的方法很快就会变得不切实际。为了有效地编排、扩展和管理多个服务，您需要像 Kubernetes 这样的专用平台，或者至少需要托管容器服务，这会引入新的复杂性和运营需求。 平台层 维护单体应用程序相对简单。如果出现 CVE，您可以在一个位置更新受影响的依赖项。需要标准化外部服务通信？实现单个包装器并在整个代码库中重复使用它。 在微服务环境中，这些简单的任务变得更加复杂。以前很简单的事情现在涉及协调多个独立服务之间的变更，每个服务都有其生命周期和依赖关系。增加的复杂性增加了时间和资源成本。当您拥有许多团队和许多不同的服务时，情况会变得更糟。 因此，许多组织引入了专用的平台层，通常由平台团队管理。目标是创建所有微服务都可以继承的基础：管理常见依赖项、实现标准化模式以及提供现成的包装器。通过在平台级别统一这些元素，您可以显著简化维护并促进整个系统的一致性。 结论 将整体式架构拆分为微服务是一项重大的架构转型，需要仔细考虑和规划。 在本文中，我们讨论了您可以采取哪些步骤来为此做好准备并顺利完成该过程。坚持 Strangler Fig 模式将为您提供增量过程并确保整个转换过程中的系统稳定性。此外，模块化单体不仅可以作为有用的准备步骤，还可以带来好处，可能促使您重新考虑微服务转换决策并避免相应的操作复杂性。
