微服务架构松耦合的复杂性

Question

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

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

问题/示例

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

我了解可以使用多种排队系统将数据从一项服务传递到另一项服务，但在我看来，它们主要用于插入、删除或更新。

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

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

我们将不胜感激。

Answer 1

你不应该照原样遵守每条规则。

这条规则有很多例外，许多系统的实践证明它并非对每个案例或系统都是正确的。

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

微服务之间的通信：

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

1. 事件（使用队列）

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

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

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

一般情况

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

我给你举个例子为什么：

示例：

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

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

另一方面，如果您的系统在生产中运行了一段时间。在某个时间点后，您开发“微服务 C”并决定 将其部署到生产中。原来你需要一些“微服务A”产生的数据。您需要“微服务 C”上的数据 作为与“微服务 B”类似的外部数据。你如何获得这些数据？ 你消费来自“微服务 A”的所有事件？在理想世界中，您将永远将所有事件保存在 Kafka 中。在这种情况下，你会 只需订阅事件并应用所有事件即可将所需的所有数据保存在“微​​服务 C”中。 实际上，您需要为您的 Kafka 设置一些 Retention Period 让我们说 5 天。如果您的系统运行时间超过 5 天，则无法从事件中重新创建数据。

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

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

总结：

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