微服务：API 调用与消息传递。何时使用？答案

【问题标题】：Microservices: API Call Vs Messaging. When to Use?微服务：API 调用与消息传递。何时使用？
【发布时间】：2019-12-08 01:04:00
【问题描述】：

我知道消息传递系统是非阻塞和可扩展的，应该在微服务环境中使用。

我质疑的用例是：

假设有一个管理仪表板客户端负责发送 API 请求以创建 Item 对象。有一个微服务提供 API 端点，该端点使用 MySQL 数据库来存储项目。还有另一个微服务使用弹性搜索来进行文本搜索。

这个管理仪表板客户端应该：

A.发送 2 个 API 调用； 1 调用 MySQL 服务和另一个 elasticsearch 服务

或

B.向主题发送消息以供 MySQL 服务和 elasticsearch 服务使用？

考虑 A 或 B 的优缺点是什么？

我认为当只有 2 个微服务在使用这个主题时，这有点矫枉过正。此外，管理员创建 Item 对象的频率非常小。

【问题讨论】：

选择第二种方法，因为队列有自己的专业人士，而且它们具有容错性，因此您的消息不会丢失。
选项 C：您可以将事务写入数据库，然后使用 CDC 将事件读取到 Kafka 主题，然后写入 Elasticsearch
@robot_alien 方法 A，两个服务都需要启动，并且发布新项目将在 mysql 和 es 中同步。因此，方法 A 也不会丢失任何消息，但我知道它将服务紧密耦合在一起......这听起来很糟糕，但我认为它适合这种情况？
@cricket_007 我也考虑到了这一点，我查找了一个名为 monstache 的工具，它可以在 mongodb 和 elasticsearch 中同步数据，但我不知道，与仅向每个人发送一个 post api 调用相比，它似乎有点矫枉过正女士？
在这种情况下没有对错，但更好的方法。你已经回答了你的问题。方法 B 是可扩展的和非阻塞的，并且将来可以添加更多服务。方法 A 只是更好的单体。但是在（任何）服务失败的情况下，方法 B 将不起作用。真的取决于你。 .在方法 A 如果您的任何依赖服务出现故障，您将推迟请求并最终超时。方法 A 存在依赖关系，因此我们不能称它们为真正的微服务

标签： rest apache-kafka microservices message-queue messaging

【解决方案1】：

就像软件架构中的许多事情一样，这取决于。您的要求、SLA 和业务需求应该更清楚。

正如您所指出的，消息传递系统不是阻塞式的并且更具可扩展性，但是，API 通信也有它的优点。

通常，REST API 最适合客户端应用程序通过 HTTP 向 API 后端发送请求的请求/响应交互。

消息流最适合在出现您可能想要采取行动的新数据或事件时发出通知。

在您的具体情况下，我会使用更具可扩展性和非阻塞性的消息传递系统。

【讨论】：

【解决方案2】：

您的 A 方法是将“路由”逻辑耦合到您的应用程序中。假设您需要执行 API 调用来审核您的请求，那么您将需要更改代码并向您的应用程序逻辑添加另一个调用。正如您所说，该方法是同步的，除非您不提供线程逻辑，否则您的调用将排队并且不会扩展，即调用 mysql --> 等待响应，然后调用弹性搜索 --> 等待响应， ... 在任何情况下，如果您需要立即保持一致性，例如，一个动作的结果调用提供第二个动作，您都可以更喜欢这种方法。

B 方法将路由逻辑解耦，因此，对事件感兴趣的任何其他服务都可以订阅主题并执行预期的操作。完全异步且可扩展。在这里，您将获得最终的一致性，并且您必须恢复任何可能的故障。

【讨论】：

是的，所以我实际上是因为用例而问这个问题：每天只有一百个请求，并且方法 B 只有 2 个消费者。鉴于这种情况，打破惯例是否明智去方法A？
正如另一条评论指出的那样，没有好的或坏的方法，它只取决于上下文，你是知道它的人。从技术上讲，使用方法 A 会增加更多依赖项，但您可以继续使用该架构并在有其他要求时立即进行更改。