Microservices 微服务体系结构松耦合复杂性

我对整个微服务潮流还相当陌生。我一直在研究好的微服务环境背后的体系结构和原则

定义微服务的主要因素之一应该是每个服务的松散耦合性质。微服务A永远不应该直接调用微服务B，否则您实际上是在创建一个单片系统，从而降低了体系结构模式提供的可伸缩性

问题/示例

如果我开发了一个返回GUID的微服务（例如），那么建议环境中的其他微服务可以在需要GUID服务时直接调用GUID服务是合理的

我知道可以使用各种排队系统将数据从一个服务传递到下一个服务，但在我看来，它们主要用于插入、删除或更新

我无法理解队列如何用于简单读取（如我的GUID示例），以及为什么不直接从另一个微服务调用GUID服务

注意：返回GUID只是一个例子，我知道大多数语言都可以在内部生成GUID

---

如果您能澄清一下，我们将不胜感激。

您不应该按原样遵循每一条规则。

这条规则有许多例外，许多系统的实践证明，它并不适用于所有情况或系统

我不同意这一限制，即微服务A不应将微服务B称为一般规则，因为它并不适用于所有情况。我曾使用 微服务和我们不遵循的地方

微服务之间的通信：

您可以使用多种方式在微服务之间进行通信，如：

事件（使用队列）

命令-通过API直接调用另一个微服务（这是微服务的某种指令），它 需要进行更改（创建、更新、删除）

查询-通过API直接调用另一个微服务（如获取GUID的示例）。 再次有人会说，这也是一个命令。 使用查询作为术语时，通常会结合使用

共享数据库（大多数在线资源会告诉您不要这样做 （由于多种原因） 一般来说，不建议采用这种方法

一般来说

你应该根据你的需要使用你的系统，而不是像这样一成不变的规则 “微服务A不应呼叫微服务B”

我将举一个例子说明原因：

示例：

假设您有“微服务A”和“微服务B”。您的“微服务B”正在使用“微服务A”通过卡夫卡发布的事件。“微服务B”在使用事件时将一些相关的“外部”数据存储在自己的数据库中（复制）。 这是一种常见的方法，每次需要“微服务A”的一些数据时，不调用它。例如，这很常见 如果“微服务A”是具有系统配置设置或类似设置的服务

假设您的数据库和“微服务B”中的所有数据都被破坏或损坏。 为了解决这个问题，您只需恢复备份并应用最近的事件，比如说上一个小时 您的“微服务B”已关闭并解决了问题（如果您的事件处理实现为幂等）。在这种情况下一切都很好

另一方面，如果您的系统在生产环境中运行了一段时间。经过一段时间后，您将开发“微服务C”，并决定 将其部署到生产环境中。事实证明，您需要“微服务A”生成的一些数据。你需要你的“微服务C”上的数据 与“微服务B”中的外部数据类似。你是如何得到这些数据的？ 您使用“微服务A”中的所有事件？在理想的世界里，你将永远保留卡夫卡的所有事件。在这种情况下，你会 只需订阅事件并应用所有事件，即可在“micro service C”中保存所需的所有数据。 事实上，你需要为你的卡夫卡设置一些，比如说5天。如果系统运行时间超过5天，则无法从事件中重新创建数据

在这种情况下，您需要使用命令/查询直接调用服务，并填充“micro service C”数据库

这只是一个边缘情况的例子，你需要有一个直接的电话

摘要：

还有许多其他例子表明这种方法也是有效的。

---

例如，通常您需要同步调用另一个微服务，并且您需要等待响应（取决于您的业务场景）。最好的方法是用命令/查询直接调用另一个微服务。

你想的全错了。队列用于传输事件。事件描述已经发生的事情。给我一个GUID是一个命令，它是对将来发生的事情的指示。在微服务体系结构中，事件消息可用于在单个服务之间同步状态。而不是示例中的GUID。想象一个用户。创建用户时，Users服务将发布UserCreated事件。这允许任何其他服务也使用该数据。因此，不再需要调用用户服务来获取用户。而且，让微服务直接通过http相互调用也不会违反任何规则。任何要求您永远不要这样做的系统设计都是错误的。微服务架构寻求减少耦合，而不是消除耦合。直接调用有时是在服务之间传输状态的最佳方式，甚至是唯一的方式。只是在大多数情况下，增加耦合的成本是不值得的