对于所提供的用例，微服务和单一方法之间有啥区别

Posted 2023-02-26

【中文标题】对于所提供的用例，微服务和单一方法之间有啥区别

【英文标题】：What is the difference between Microservices and Monolythical approach for the provided use-case对于所提供的用例，微服务和单一方法之间有什么区别

【发布时间】：2019-05-03 09:22:51

【问题描述】：

所以我开始阅读一些关于不同软件架构的东西，并且不可避免地遇到了微服务架构。然而，我想知道这些架构彼此不同的方式。在单一的方法中，我会例如修改POM.XML 以获取我的不同层并将它们打包到一个应用程序中以进行部署。我想说这甚至可能是设置简单应用程序的最常用方法。

现在我理解了微服务，您将每个服务彼此分开并让它们独立运行。对我来说，这意味着每个服务都是独立部署的（所以你基本上有一个 tomcat 运行，上面有很多 .war 文件。但我想我错过了与单一应用程序的区别。

我将尝试设置一个（相当常见的）示例：

您有一个前端（例如Angular）和一个Spring-Boot 后端通过REST-Services 进行通信。现在我采取POM.XML 并执行以下步骤：

构建前端应用程序 在我的 Spring-Application 中包含必要的 JS 文件 从项目中创建WAR-file

因此，我得到了一个可以部署的 WAR-文件，但包含两个服务：后端和前端。然而，我认为这是一种单一的方法。

现在，当我将Angular-Application 包含到我的tomcat 中并部署我的Spring-Boot 应用程序部分的WAR-文件时（没有集成前端）。这样，我将在同一台服务器上运行两个已部署的服务，它们相互交互，可以在不相互接触的情况下进行替换。根据定义，我不会将其称为单一方法（相同的代码，不同的部署），而是一种微服务架构，对吧？但事实并非如此，因为实际上我读过的每一篇文章都告诉我架构的相同优点和缺点，除了交换前端和后端的可能性（我在两种情况下都有，但在一个情况下我会在第一种情况下需要重新部署完整的应用程序）。

【问题讨论】：

区别不在于代码的模块化，而在于运行时组件的粒度。因此，您仍然可以从相同的代码库构建微服务并部署不同的组件（在我看来，您甚至可以将所有微服务构建为同一个工件，但在运行时以不同方式调用二进制文件）。

“你基本上得到了一个运行着相当多的 .war 文件的 tomcat。”。使用微服务，您将能够（一旦这在规模上有意义）而不是让许多 tomcat 在许多服务器上运行，每个服务器都有一个 war 文件。或者用不同的实现替换这些服务之一（可能是非常不同的、不同的语言，甚至是外部提供的 Saas）。使用单体，不可能轻易地拉出单个部分。

“包括两个服务：后端和前端。”使用微服务，您将拥有许多共同构成后端的部分。 （我认为您仍然可以将它们部署在一起，但从概念上讲它们是独立的部分）。

@Thilo 让我赶上你所说的关于后端的最后一件事：这意味着例如我调用了 20 个不同的 API 来从中获取数据（例如，用于书籍、汽车、用户等）。在 MS 方法中，每个 API 都有一个独立的部分，这样我就可以用另一个“Books”-Module 替换我的“Books”-Module。但是当我将它构建为单一的时，我仍然会为我可以请求的每个 API 使用不同的模型，这些模型彼此独立以保持模块化，对吗？

@Rüdiger 有关单体和微服务的真实示例，您可以访问此项目：jhipster.tech。尝试制作这两种类型的应用程序并为它们提供午餐。

【参考方案1】：

微服务只是一组指导方针，讨论如何设计您的应用程序，使其具有可扩展性、可管理性并适应快速的开发速度。这不仅仅是关于如何部署应用程序。

多年来，我们了解到，当您尝试将一个大型应用程序构建为单体应用程序时，最初它会为您提供节奏，您的单体应用程序中的不同模块具有完全的相互可见性，并且可以访问事物，根据需要调整事物，即使是应该影响一个模块的一项更改也可能会迁移到不应该出现的其他类中。虽然它可以帮助您进行原型设计，但代码变得越来越难以维护。你当然可以努力确保你的代码保持干净，但随着应用程序的增长，这种努力也会增加。

另外，作为开发人员，您需要了解整个产品，很难在孤岛中工作，而不担心整个架构，这使得新人难以加入和进行更改。

接下来，当您部署时，特别是现在，规模很重要，您需要适应流量。您的所有模块都不会期望 24/7 的高流量。但是，如果您有单体应用，即使一个模块被 100 个用户使用，您的应用程序也必须针对 100 个用户进行扩展。

微服务只是从中提取信息，并定义一些准则

您应该根据 biz 域细分您的应用程序。每个服务只负责一个方面。他们通过合同（API 或事件）与其他人交谈，只要合同成立，您就可以在您的服务中做您想做的事。新开发者只需学习一项服务即可。

扩展变得容易，因为如果您在一项服务上有负载，那么只有它才会扩展。独立部署的其他模块可以根据特定于它们的负载进行扩展。

通过保持较小，您可以快速构建，快速进行更改。没有共享数据库，请确保您就要保存的内容、要如何保存以及要如何更改进行通话。

对于您的情况，只需按照您认为最好的方式部署它。但是，如果您开始成长，您将拥有大约 50 多个服务（或那个规模的项目），您将看到分而治之的好处。

【讨论】：

所以这些架构很可能是基于我的代码的模块化，而不是我运行了一个、两个还是二十个不同的服务？例如。当我有 5 个可以相互独立运行（但可能共享同一个数据库）并且只与前端和数据库服务器通信的模块时，你不会称它为单体吗？虽然它部署在一个大型 WAR 文件中？

这与您如何称呼他们无关。微服务是指导方针，如果你违反了一个指导方针，你可能会遇到麻烦，例如，如果他们共享数据库、用户数据库，最初看起来可能很好，因为订单可以直接获取用户数据，但随后你也存储了密码的哈希值，并且现在每个人都可以看到它，如果订单服务更新了它，或者在用户数据中添加了一个新列。现在你的用户服务需要去弄清楚为什么添加它，有什么影响，有什么验证等等。这会让生活变得很困难。明天，所以服务应该是独立的，不能共享。

好的，这似乎是一个好方法，感谢您的澄清！您还对那里的数据库有所了解，因此创建一个“更大”的服务可能比我猜想共享同一个数据库的两个服务更有用。

是的，但是决定服务边界的基本上是您对域的理解以及它们如何相互交互。这有点困难。您可以从较大的服务开始，如果它运作良好，否则您将其拆分，反之亦然。微服务可让您快速发展。

【参考方案2】：

从后端拆分前端并不是微服务部署的最佳/规范示例；这相当于在一个整体中具有层。关于如何将单体按（子）域拆分为模块，每个模块都有前端和后端职责，这更好；然后如果需要，每个模块都可以成为一个微服务。

基于 Web 的应用程序的规范 MS 架构是一个网关，它组装（并行！）来自不同 MS 的 html 响应。因此，单个 MS 将使用 HTML、CSS 和 JS 来响应，而不是 JSON 或其他不完整的数据形式。这是应用于 MS 的Tell Don't Ask 原则。这为您提供了一个真正的 MS，您可以在其中非常轻松地将一个 MS 替换为另一个。

如果网关因为相互依赖而无法并行组装各个响应，则拆分是错误的，您需要重构。

模块化单体和微服务之间最大的显着区别是微服务在不同的进程中运行。

如果您使用位置 transparency 创建您的单体应用程序，那么您可以将组件部署为微服务，而无需接触其他人的组件代码。例如，如果您使用 CQRS，您可以将 Readmodel 部署为微服务，只需在代码上使用剪切/粘贴，从单体应用到微服务。