为什么是时候从单体架构迁移到微服务了

已发表: 2022-04-07

随着应用程序变得越来越复杂，开发人员和工程师正在寻找构建灵活且可扩展的软件解决方案的方法。在这种情况下，包括 Spotify 和亚马逊等巨头在内的 60% 的科技公司已经转向微服务。

根据这一趋势，任何有远见的科技公司都应该考虑从单体架构转向微服务。

但在开始迁移过程之前，您必须制定明确、可行的策略以确保顺利过渡。在本文中，您将了解迁移到微服务的好处和挑战。

单体和微服务的简要概述

单体架构是一个系统，其中所有操作、数据存储和请求处理都由通用代码库处理。

传统上，单体应用程序包含客户端用户界面、服务器端应用程序和数据库。服务器端应用程序接收和处理请求，执行域逻辑，从数据库返回数据，并在用户界面上将其呈现给请求者（客户端）。

尽管单体生态系统主要存在于遗留应用程序中，但一些开发人员仍将这种架构模型用于简单的软件程序和概念验证应用程序。

相反，微服务是指包含负责特定操作的多个服务的软件架构。微服务架构也称为面向服务的架构（SOA）。

以下是微服务架构的核心属性：

单一责任。每个服务专门处理一个操作。
独立。 尽管与其他微服务协同工作，但每个服务都作为一个单独的实体运行。您可以独立部署、重用和更新它们中的每一个。
智能端点。 每个组成微服务都遵循独特的域逻辑，并通过 HTTP、AMQP 或 TCP 进行通信。
领域驱动设计。这种方法的中心是对一个模型进行编程，该模型对域的过程和规则有丰富的理解。
模块化。 微服务是模块化的，因为它们在生态系统中包含可替换的组件或模块。因此，团队可以独立扩展和更新不同的单元。
失败证明。 微服务的使用消除了系统的单点故障。如果一个模块发生故障，其他微服务将保持正常运行。

迁移到微服务的原因

如果您的企业在迁移到微服务方面犹豫不决，那么您的犹豫是可以理解的。让我们讨论一下为什么过渡到 SOA 是有意义的一些令人信服的理由。

提高可扩展性

单体应用很难扩展，因为对一个模块的更改需要对整个应用程序进行大规模重新部署。但是使用微服务，团队可以在不破坏其他功能的情况下使系统更具可扩展性。

Netflix 从单体架构切换到 SOA 以使其系统更具可扩展性。随着公司用户池的不断扩大，开发人员预测现有的开发生态系统将不再能够处理大量涌入的数据和内容。

为此，Netflix 的工程师开始将视频编码和用户注册等服务分离为独立模块。

增加灵活性

单体架构的僵化和缺乏敏捷性使其难以适应现代平台和技术。相反，微服务为工程师提供了更多尝试和集成新技术的回旋余地。

EBay 采用 RESTful API 作为公司放弃其过时的单体架构的努力的一部分。通过这样做，该公司能够部署一个组件库来支持暗模式等功能。

提高生产力

在使用单体时，工程师只能在核心架构的范围内工作。但是使用微服务，多个团队可以同时处理同一个应用程序。因此，这确保了时间和资源的有效利用，全面提高了生产力。

缩短上市时间

尽管单体应用更容易构建，但它们仅适用于简单的应用程序、概念验证软件 (PoC) 和最小可行产品 (MVP)。

在处理拼车应用程序等复杂应用程序时，单体应用程序可以通过限制工程师可以享受的自由范围来破坏时间线。

或者，使用 SOA 增加了额外的自由度，提高了流程的效率，从而缩短了上市时间。

增强安全性

单体架构中的错误使整个系统容易受到故障和可能的恶意软件攻击（DDOS、SQL 注入等）的影响。但在使用微服务时，这些漏洞并不那么重要。

尽管 SOA 的多个模块引入了多个攻击点，但一个单元的失败并不意味着整个生态系统的厄运。

简化维护操作

调试一个复杂的单体对于开发人员来说是一项艰巨的任务，尤其是在使用旧代码库时。即使团队可以轻松查明故障，他们仍然需要重新部署整个基础架构。

但是，您可以通过迁移到微服务来减少重新部署所花费的精力。您只需要修复和重新部署受影响的模块，而不是整个应用程序架构。

使用 SOA 的一个缺点是您可能很难在复杂的多层系统中发现确切的故障点。但是使用 Netsparker 等现代监控工具，您可以立即跟踪这些缺陷。

促进团队的沟通和成长

当应用程序依赖于单体时，每个团队都必须专注于架构的特定方面，这会导致冗余、官僚主义瓶颈和延长时间框架。

另一方面，微服务依赖 API 进行通信。为了实现这一目标，团队需要生成可在内部和外部工作的功能。

当亚马逊从单体架构转向微服务时，该公司创建了自己的 Web 服务 API 来与世界其他地方进行通信。

大佬们正在这样做

是的，赶上潮流并不总是软件开发的最佳商业方法。但是，正如我们所提到的，像亚马逊这样的创新驱动力正在支持微服务。来自科技巨头的支持使得采用面向服务的架构的想法很有吸引力。

但在从单体架构切换到微服务之前，请根据具体情况权衡每种模型的优缺点。

从单体迁移到微服务的挑战

O'Reilly 的数据显示，大约 62% 的公司在迁移到微服务后取得了一定程度的成功。

然而，像 Shopify 这样的公司仍然维护其单体架构的模块化版本，因为它可以帮助他们最大限度地提高生产力。切换到 SOA 会带来一些障碍，每个团队在迁移之前都必须考虑这些障碍。

以下是将应用程序从单体应用程序迁移到微服务的主要挑战。

使系统更复杂

在现有架构中添加更多模块会使管理变得更加复杂。您现在不必关注单个代码库，而必须担心多个代码库执行不同的操作。不仅如此，随着新模块或微服务进入系统，文档将继续增加。

使测试过程复杂化

使用微服务，您现在必须担心调试多个分布式服务器的代码，而不是只关注一个。这一障碍延长了代码审查工作，并在部署之前延迟了新更改的实施。

需要新的技能组合

添加新模块时，您需要找到可以使用底层编程语言的开发人员和工程师。您的 DevOps 团队将需要升级他们的技能组合或雇用新的团队成员来填补技能差距。

增加开发成本

由于您现在需要添加更多服务、扩大测试工作并提高技能组合，因此迁移的总体成本将会增加。在某些情况下，就像 Spotify 所展示的那样，坚持使用单体架构并进行必要的升级是更具成本效益的选择。

将单体应用迁移到微服务的最佳策略

无论如何，迁移到微服务都不是万无一失的方法。错误和准备不足会破坏应用程序，导致项目被遗弃和资源浪费。

因此，我们收集了最佳实践，以确保顺利迁移到微服务。

组建跨职能团队

大多数公司最常犯的错误是，他们在组建合适的团队之前就投入了迁移工作。

与传统的单体架构不同，使用微服务需要由开发人员、QA 专家和工程师组成的跨职能团队的努力。

考虑在迁移到微服务时创建一个完善的 DevOps 策略来构建、测试和部署应用程序。如果您的团队成员缺乏执行迁移过程的技能，那么这是提升他们技能的最佳时机。

识别依赖组件

有了一个团队，您的工程师就可以开始解构单体架构，特别注意持续交付管道和 API 管理系统。

此外，您的团队应该优先考虑可以解耦的组件，而不会影响依赖单体运行的面向客户端的应用程序。 Sonargraph Explorer 等工具可以帮助您根据已建立的层次结构概述组件依赖关系。

解耦组件

在迁移期间，您不应该一次解耦所有组件。最好的策略是先将边缘服务解耦，然后再深入到现有单体中。

从边缘案例开始，您的团队可以“及早失败”并充实所有运营先决条件，然后再转向关键任务组件。

技术专家 Martin Fowler 提出了经常发生变化的解耦功能，例如零售管理系统中的客户个性化。

为您的远程用户界面使用 API

在迁移期间，用户仍将与您的应用程序进行交互。为确保他们可以访问该软件，请使用 API 来处理所有数据访问案例。此外，统一的 API 应该是向后兼容的。

根据 Eric Evan 的领域驱动设计 (DDD)，API 应该提供一个反腐败层来转换构成单体应用程序和微服务应用程序的子系统之间的请求。

将单体迁移到宏服务，然后再迁移到微服务

将单体架构拆分为过多的微服务会创建一个超复杂的分布式系统，这将是调试的噩梦。

为了避免这种不必要的繁重工作，首先将单体分解成共享相同数据存储库的大块（宏服务），然后将它们拆分成更小的独立单元（微服务）。

例如，如果您有一个食品订购应用程序的单体应用程序，那么宏服务可以处理“订单”，而组成的微服务可以管理分拣、支付和运输等子任务。

您可以使用 Richardson 成熟度模型来解耦基于 REST 的服务。

测试和部署

在每个阶段，始终进行测试以调试应用程序并发现架构中的逻辑缺陷。使用集成测试技术来建立迁移数据与单体中剩余块之间的关系。

您还可以测试访问控制以确保用户没有查看旧数据库中的数据。之后，您可以部署新创建的微服务。

部署微服务的一个很好的方法是进化架构模型。在这种方法下，您的团队可以在核心工程实践中引入增量开发。这种进化模型适用于不断变化的软件开发生态系统。

结论

对于当今的软件开发公司来说，从单体架构迁移到微服务似乎是一件轻而易举的事。但在您将应用程序从单体架构迁移到微服务之前，请努力了解其中的好处和可能面临的挑战。组建合适的团队来处理迁移过程，而不会中断用户体验和内部运营。

最终，始终在部署之前测试新微服务架构中的每个新组件和功能。