Art*_*nko 6 rest messagebroker event-bus cap-theorem microservices
我们拥有基于微服务架构的应用程序的第一个版本。我们使用 REST 进行外部和内部通信。
现在我们要从CP（CAP定理）*切换到AP，使用消息总线进行微服务之间的通信。关于如何基于 Kafka、RabbitMQ 等创建事件总线的信息有很多，但我找不到任何 REST 和消息传递组合的最佳实践。例如，您创建了一个汽车服务，您需要添加不同的汽车组件。为此，将 REST 与 POST 请求一起使用会更有意义。另一方面，预订汽车的服务对于基于事件的方法来说是一项很好的任务。
当您拥有不同的字典和业务逻辑功能时，您是否有类似的方法？你如何结合它们？只是分别支持这两种方法？或者用一种方法统一它们？
* 对于第一个版本，我们同意选择一致性和分区容错性。但是现在可用性对我们来说变得更加重要。
Geo*_*ker 13
前面的底线：您正在寻找Command Query Responsibility Segregation；它定义了一种架构模式，用于分解从查询数据到请求运行流程的职责。简短的回答是，您不希望以阻塞方式在查询或进程中混合使用这两者。这个答案的其余部分将详细说明原因，以及您可以做的事情的三种不同方式。
这个答案是我在微服务方面的经验的简短形式。我的诚意：我从头开始创建了微服务拓扑（几乎零知识），并且正如他们所说的那样在下降的过程中击中每个分支。
从零知识开始的好处之一是，我创建的第一个拓扑混合使用了服务内同步和阻塞 (HTTP) 通信（从持有它的服务中检索操作所需的数据）和消息队列+ 运行操作的异步事件（用于命令）。
我将定义这两个术语：
命令：告诉服务做某事。例如，“运行 ETL 批处理作业”。您希望由此产生输出；但这必然是一个您无法可靠等待的过程。命令有副作用。由于此操作，某些事情会发生变化（如果什么都没有发生并且没有任何变化，那么您还没有做任何事情）。
查询：向服务询问它持有的数据。由于给出的命令，这些数据可能已经存在，但要求数据不应有副作用。由于收到查询，不需要运行任何命令操作。
无论如何，回到拓扑。
对于第一个拓扑，我们将同步查询与正在发出的异步事件混合在一起。这……有问题。
消息总线本质上是可观察的。RabbitMQ中的一个设置，或者一个Event Source，你就可以观察到系统中的所有事件。这有一些好的副作用，因为当过程中发生某些事情时，您通常可以找出导致该状态的事件（如果您遵循事件驱动范式 + 状态机）。
如果不检查网络流量或记录这些请求（这本身有问题，所以我们将从正常操作中的“不可行”开始），则无法观察 HTTP 调用。因此，如果您混合使用基于消息的进程和 HTTP 调用，则会出现无法判断发生了什么的漏洞。您会发现由于网络错误，您的 HTTP 调用没有返回数据，并且您的服务因此没有继续该过程。您还需要为您的 HTTP 调用连接重试/断路器模式，以确保它们至少尝试几次，但是您必须区分“因为它关闭而未启动”和“因为它暂时很忙而未启动” ”。
简而言之，将这两种方法混合用于命令驱动过程并不是很有弹性。
在此成熟度模型的第二步中，您将命令和查询分开。命令应该使用事件驱动系统，查询应该通过 HTTP 发生。如果您需要命令查询的结果，那么您可以发出一条消息并在您的消息总线上使用请求/响应模式。
这也有好处也有问题。
优势方面，您的整个 Command 现在都可以观察到，即使它在多个服务间跳跃。您还可以通过重新运行事件来重放系统中的进程，这对于跟踪问题很有用。
问题方面，现在你的一些事件看起来很像查询；现在您正在为消息重新创建 HTTP 中可用的漂亮的 HTTP 和 REST 语义；这不是非常有趣或有用。例如，404 告诉您 REST 中没有数据。对于基于消息的事件，您必须重新创建这些语义（关于这个主题的 Youtube 会议上有一个很好的演讲，我找不到，但一个团队试图非常痛苦地做到这一点）。
但是，您的事件现在是异步和非阻塞的，并且每个服务都可以重构为响应给定事件的状态机。一些警告是那些事件应该包含操作所需的所有数据（这会导致消息在流程中不断增长）。
您的查询仍然可以使用 HTTP 进行外部通信；但是对于内部命令/进程，您将使用消息总线。
我也不推荐这种方法（尽管它比第一种方法更上一层楼）。我不推荐它，因为您的事件开始带有杂质，并且在微服务系统中，在整个系统中具有相同的合同很重要。
成熟度模型的第三步（当我离开该项目时，我们正在走向那个范式）是生成数据的服务在生成数据时发布事件。然后由侦听这些事件的服务记下该数据，这些服务将使用该（可能是？）陈旧数据进行操作。外部客户仍然使用 HTTP；但在内部，您会在产生新数据时发出事件，并且每个关心该数据的服务都会存储它以在需要时使用。这是 Michael Bryzek 演讲的关键，以正确的方式设计微服务架构。Michael Bryzek 是 Flow.io 的 CTO，这是一家白标电子商务公司。
如果您想要更深入的答案以及其他相关问题，我会为您提供我关于该主题的博客文章。