微服务是否可以结合 REST 和消息传递？

Question

我们拥有基于微服务架构的应用程序的第一个版本。我们使用 REST 进行外部和内部通信。

现在我们要从 CP（CAP 定理）* 切换到 AP，并使用消息总线进行微服务之间的通信。 有很多关于如何基于Kafka、RabbitMQ等创建事件总线的资料。 但是我找不到 REST 和消息传递组合的任何最佳实践。 例如，您创建了一个汽车服务，您需要添加不同的汽车组件。为此，将 REST 与 POST 请求一起使用会更有意义。另一方面，预订汽车的服务对于基于事件的方法来说将是一项很好的任务。

当您拥有不同的字典和业务逻辑功能时，您是否有类似的方法？你如何将它们结合起来？只是分别支持这两种方法？还是用一种方法统一它们？

* 对于第一个版本，我们同意选择一致性和分区容差。但现在可用性对我们来说变得更加重要。

Answer 1

前面的底线：您正在寻找Command Query Responsibility Segregation；它定义了一种架构模式，用于分解从查询数据到请求运行流程的职责。简短的回答是您不想在查询或进程中以阻塞方式混合两者。这个答案的其余部分将详细说明原因，以及您可以做您想做的事情的三种不同方式。

这个答案是我在微服务方面的经验的简短形式。我的诚意：我从头开始创建了微服务拓扑（并且知识几乎为零），正如他们所说，在下降的过程中触及了每个分支。

从零知识开始的一个好处是，我创建的第一个拓扑混合使用了服务内同步和阻塞 (HTTP) 通信（从持有它的服务检索操作所需的数据），和消息队列 + 异步事件来运行操作（对于命令）。

我将定义这两个术语：

命令：告诉服务做某事。例如，“运行 ETL 批处理作业”。你期望有一个输出；但这必然是一个您无法可靠等待的过程。命令有副作用。由于此操作，某些事情会发生变化（如果没有发生任何事情并且没有任何变化，那么您什么都没有做）。

查询：向服务询问其持有的数据。由于给出了命令，这些数据可能已经存在，但要求数据不应该有副作用。由于收到了查询，因此不应需要运行任何命令操作。

不管怎样，回到拓扑。

级别 1：混合 HTTP 和事件

对于第一个拓扑，我们将同步查询与发出的异步事件混合在一起。这是……有问题的。

消息总线本质上是可观察的。 RabbitMQ 中的一项设置，或者一个事件源，您可以观察系统中的所有事件。这有一些很好的副作用，因为当过程中发生某些事情时，您通常可以找出导致该状态的事件（如果您遵循事件驱动的范例 + 状态机）。

如果不检查网络流量或记录这些请求，就无法观察到 HTTP 调用（这本身就有问题，所以我们将从正常操作中的“不可行”开始）。因此，如果您将基于消息的进程和 HTTP 调用混合在一起，您将有无法判断发生了什么的漏洞。由于网络错误，您的 HTTP 调用没有返回数据，您的服务因此没有继续该过程。您还需要为您的 HTTP 调用连接 Retry/Circuit Breaker 模式，以确保它们至少尝试几次，但是您必须区分“因为它关闭而未启动”和“因为它暂时繁忙而未启动” ”。

简而言之，将这两种方法混合用于命令驱动进程并不是很有弹性。

级别 2：事件定义数据的 RPC/内部请求/响应；查询是外部的

在此成熟度模型的第二步中，您将命令和查询分开。命令应该使用事件驱动系统，查询应该通过 HTTP 进行。如果您需要命令查询的结果，那么您可以发出一条消息并在您的消息总线上使用请求/响应模式。

这既有好处也有问题。

在好处方面，您的整个命令现在是可观察的，即使它通过多个服务跳跃。您还可以通过重新运行事件来重放系统中的进程，这对于跟踪问题很有用。

问题方面，现在您的一些事件看起来很像查询；现在，您正在为消息重新创建 HTTP 中可用的漂亮 HTTP 和 REST 语义；这不是非常有趣或有用。例如，404 告诉您 REST 中没有数据。对于基于消息的事件，您必须重新创建这些语义（有一个关于这个主题的很好的 Youtube 会议演讲我找不到，但是一个团队试图这样做很痛苦）。

但是，您的事件现在是异步且非阻塞的，并且每个服务都可以重构为响应给定事件的状态机。需要注意的是，这些事件应该包含操作所需的所有数据（这会导致消息在整个过程中不断增长）。

您的查询仍然可以使用 HTTP 进行外部通信；但对于内部命令/进程，您将使用消息总线。

我也不推荐这种方法（尽管它比第一种方法更先进）。我不推荐它，因为您的事件开始产生杂质，并且在微服务系统中，整个系统的合约相同是很重要的。

级别 3：数据的生产者将数据作为事件发出。消费者记录数据以供使用。

成熟度模型的第三步（当我离开该项目时，我们正朝着那个范式迈进）是为产生数据的服务在产生数据时发出事件。然后，监听这些事件的服务会记下这些数据，这些服务将使用这些（可能是？）陈旧的数据来执行它们的操作。外部客户仍然使用 HTTP；但是在内部，当产生新数据时，您会发出事件，并且每个关心该数据的服务都会将其存储起来，以便在需要时使用。这是 Michael Bryzek 谈话Designing Microservices Architecture the Right way 的关键。 Michael Bryzek 是Flow.io 的首席技术官，这是一家白标电子商务公司。

如果您想获得更深入的答案以及其他问题，我会告诉您my blog post on the subject。