你需要知道的单体架构与微服务架构对比

在开始构建应用程序之前，您需要做出的重要选择之一是要使用的结构架构。微服务和单体架构设计是用于创建 Web 应用程序的两种最流行的模型。然而，现在大多数大规模运行的 Web 应用程序都使用微服务架构。

在其他一些用例中，选择微服务架构比单体架构更有意义。在今天的文章中，我们将讨论您需要了解的关于微服务的所有主要内容，包括其工作原理、优缺点、最佳用例等等。让我们开始吧！

什么是微服务？

微服务是一种架构设计，通过构建小型的自主服务来开发大型应用程序，这些服务协同工作以执行应用程序的各种功能。例如，一个电商Web应用程序可能针对各种功能（包括注册、订单管理、愿望清单、搜索等）使用不同的微服务。

这些微服务各自独立运行，因此其中一个微服务出现故障不会影响其他微服务的运行。在单体架构下，应用程序某个部分的错误将会影响整个应用程序的功能。一些采用微服务架构的热门平台包括：Netflix、亚马逊、Uber、eBay 等等。

微服务如何工作？

微服务的工作方式取决于应用程序的大小和规模。然而，所有使用此架构构建的应用程序都包含四个主要模块。它们包括 API 网关、微服务、数据库和微服务间通信。让我详细解释一下这四个模块。

• API 网关： API 网关是应用程序最终用户的入口点。应用程序的用户将请求发送到 API，然后 API 将其转发到专门用于处理该任务的微服务。例如，当您点击某个 Web 应用程序上的注册按钮时，该请求将被发送到注册微服务。

• 数据库：应用开发者可以选择为所有微服务使用同一个数据库。但是，如果希望所有服务完全独立运行，则最好为每个微服务都配置一个数据库。

• 微服务：这些是执行独立任务（例如支付、注册、搜索、订单管理等）的小型服务。微服务的数量有时取决于应用程序的规模或开发人员如何拆分服务。例如，Netflix 拥有超过 1000 个微服务。

• 微服务间通信：微服务使用不同类型的协议（例如 REST 和消息传递）进行通信。这些协议使应用程序的不同微服务能够在需要时进行通信。

使用微服务架构的优势

• 轻松隔离故障：使用微服务架构，在应用程序其他部分正常运行的情况下，隔离某项服务变得非常容易。如果故障足够严重，类似的故障可能会导致单体应用程序宕机。
• 更快、更有效地开发应用程序：不同的团队可以处理各种微服务，而不必等待另一个团队完成应用程序的特定部分。
• 应用程序更具可扩展性：添加新功能和管理海量流量变得更加容易。微服务架构下，每个小服务都是独立构建的，因此新功能的添加速度更快。
• 更容易使用不同的技术：使用微服务，您可以为每项服务使用不同的编程语言，而不会影响应用程序的整体运行。在单体应用程序中，为不同部分使用不同的语言的过程更为复杂。
• 更容易理解：如果某个微服务需要修复或更改，那么执行此类任务会更加容易。这是因为各个微服务的代码量很小，因此即使负责该服务的团队规模较小，也可以更快地完成更改。
• 更容易实现连续性：对于新团队成员来说，理解微服务的功能和代码比理解整个应用程序要容易得多。这使得连续性变得更加容易。
• 用户感觉应用程序运行速度更快：采用这种架构的应用程序往往能更快地加载各个部分。这提升了应用程序的整体用户体验。

微服务架构的局限性

• 部署更复杂：由于单个应用程序包含多个微服务，因此在 Web 上部署比单体应用程序困难得多。不同服务之间的通信基础设施也非常复杂，因此应用程序的部署更加复杂。
• 需要更多资源：由于不同服务之间的通信需要复杂的网络，使用微服务架构构建的应用程序往往比单片应用程序占用更多的计算资源。这是应用程序开发人员需要处理的额外开销。
• 全局测试和调试更加困难：测试和检测单个微服务的错误可能更容易。然而，在这种架构下，测试整个应用程序的功能要困难得多。
• 不适合小型应用：微服务架构只适合那些预计每天有数千甚至数百万用户的大型应用。对于规模较小的应用，最好选择单体架构。

何时选择微服务而不是单体架构

是的，使用微服务架构构建的应用比使用单体架构构建的应用具有诸多优势。然而，这种架构在某些情况下才是理想的，您在做出选择之前可能需要了解一些情况。以下是其中一些场景。

• 当您的主要目标是构建一个可能吸引数百万用户的大型应用程序时，如果您要部署一个在组织内部使用的应用程序，则最好使用单片架构。
• 如果您的应用程序后端的不同功能必须使用不同的语言编写。正如我们之前讨论过的，使用微服务方法的好处之一是，它可以更轻松地使用不同的编程语言编写每个服务的后端。
• 如果可扩展性是您应用程序的关键，那么微服务架构非常适合那些需要不断修订和扩展用户容量的应用程序。
• 当你打算构建的应用程序具有多种功能和用户体验时，最好使用微服务架构进行开发。例如，一个具有多个独立业务模块的应用程序应该使用微服务架构进行构建。

如何处理微服务对其他微服务的请求

影响使用微服务架构构建的任何 Web 应用性能的关键因素之一是它们的通信方式。不同的微服务必须有效地通信才能执行特定的业务任务。微服务之间使用三种消息传递模式进行通信，包括同步、异步和混合。让我们详细解释一下。

同步通信
：数据以阻塞迭代的方式在端点之间移动。这意味着调用者必须等待接收者的响应才能继续下一步。因此，如果微服务 A 向微服务 B 发送请求，它必须等待接收者的响应才能发送任何其他请求。

异步
使用此通信协议，微服务可以发送消息，而无需等待接收方的响应。

混合
型微服务支持两种通信协议。大多数微服务应用都使用这两种协议。因此，选择使用哪一种协议取决于给定应用程序的不同微服务之间进行的通信类型。

如何在微服务上处理数据库事务

对于单体应用来说，所有数据都存储在一个数据库中，因此更容易在各个数据库事务中实现一致性。然而，对于微服务应用来说，不同的微服务拥有独立的数据库，因此数据库事务是分布式的。这使得在网络中所有数据库之间实现一致性变得更加困难。

单体应用数据库处理 ACID 事务，以执行“全有或全无”事务，同时确保一致性。ACID 代表：

• 原子性：所有请求都成功执行或者都失败。
• 一致性：数据库中的所有数据都按照数据库规则保持有效状态。
• 隔离性：分离的事务不会互相干扰。
• 持久性：事务完成后，所有更改都会被永久存储。

你可能已经猜到了，ACID 事务方法不适用于微服务应用，因为不同的微服务数据库分布在网络上。处理微服务数据库事务主要面临两大挑战：

1. 如何保持交易的原子性以及
2. 如何处理并发事务

解决这两个挑战的解决方案如下：

• 两阶段提交：包括准备阶段和提交阶段。在准备阶段，给定事务的所有相关微服务都会通知协调器它们已准备好执行该事务。在提交阶段，协调器会发出提交或回滚命令。
• 最终一致性和补偿：通过这种方法，所有微服务在其数据发生变化时都会发布事件。其余服务订阅此事件并更新其数据库以确保一致性。