微服务架构松耦合并发症

Question

我对整个微服务潮流还很陌生。我一直在研究良好的微服务环境背后的架构和原则。

定义微服务的主要内容之一应该是每个服务的松散耦合特性。微服务 A永远不应该直接调用微服务 B，否则您正在有效地创建一个失去架构模式提供的可扩展性的单体系统。

问题/例子

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

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

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

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

对此有所澄清将不胜感激。

Answer 1

你不应该遵循每一条规则。

这条规则有很多例外，许多系统的实践证明它并不适用于每个案例或系统。

我不同意微服务 A 永远不应该调用微服务 B 作为一般规则的限制，因为它不适用于所有情况。我曾使用微服务与多个系统合作过，但我们没有遵循这一点。

微服务之间的通信：

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

1. 事件（使用队列）

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

3. 查询 - 通过 API 直接调用另一个微服务（例如获取 GUID 的示例）。再次有人会说这也是一个命令。使用 Query as term 经常与使用CQRS结合使用。

4. 共享数据库（大多数在线资源会出于多种原因告诉您不要这样做）通常不推荐这种方法。

一般来说

您应该根据您的需要使用您的系统，而不是基于像“微服务 A 不应调用微服务 B”这样的固定规则。

我给你举个例子，为什么：

例子：

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

假设您有一个灾难场景，其中您的数据库和来自“微服务 B”的所有数据都被破坏或损坏。为了解决这个问题，你可以只恢复你的备份并应用最新的事件，比如你的“微服务 B”关闭的最后 1 小时并解决问题（如果你的事件处理被实现为幂等）。在这种情况下一切都很好。

另一方面，如果您的系统在生产中运行了一段时间。在某个时间点之后，您开发了“微服务 C”并决定将其部署到生产环境中。事实证明，您需要一些“微服务 A”产生的数据。您需要“微服务 C”上的数据作为外部数据，类似于“微服务 B”中的数据。你如何获得这些数据？你消费了“微服务A”的所有事件？在理想的世界中，您将永远将所有事件保存在 Kafka 中。在这种情况下，您只需订阅事件并应用所有事件以将您需要的所有数据保存在“微​​服务 C”中。实际上，您需要为您的 Kafka设置一些保留期，比如说 5 天。

在这种情况下，您需要直接使用 Command/Query 调用服务并填充“微服务 C”数据库。

这只是您需要直接调用的一个边缘案例示例。

概括：

还有许多其他例子表明这种方法也有效。很多时候，例如，您需要同步调用另一个微服务，并且您需要等待响应（取决于您的业务场景）。最好的方法是直接使用命令/查询调用另一个微服务。