订阅队列的 Web Api 应用程序。这是个好主意吗？

Question

我们正在使用微服务架构设计一个报告系统。所有服务都应该是事件总线的订阅者，它们通过引发事件进行通信。我们还决定使用 REST api 公开我们的每个服务。现在的问题是，将我们的服务创建为也是事件总线订阅者的 Web api [RESTful] 应用程序是否是个好主意？所以基本上每个服务都有 2 个入口点 - api 和事件。我有一种感觉，我们应该把这两个分开，因为这是两个不同的问题。有任何想法吗？

Answer 1

由于微服务架构是无主见的软件设计。所以你可能会在这个问题上得到不同的答案。 是的，REST 和基于事件是两个不同的东西，但有时两者结合起来可以提供更好的设计灵活性。

回答您的问题，如果 REST API 也订阅队列，我认为没有任何危害，只要您可以同时维护它们，即消息的更改不会对 API 产生任何影响并且您有适当的后备和Eventual consistency 机制。你可以查看discussion。已经有少数项目尝试过，如nakadi和ponte。

因此，在 REST API 和基于事件的设计或两者之间进行选择完全取决于您的服务的通信行为。

您所做的是根据您的要求选择REST API，您可以在其中看到服务之间的同步行为 并使用 基于事件的设计，您会发现服务需要 异步行为，两者结合也没有坏处。

理想情况下，对于进程间通信协议，最好使用消息传递，而对于客户端服务，REST API 最适合。 查看microservices.io中的沟通方式

基于 REST 的架构

• 优势

  1. 当您需要同步环境时，请求/响应非常简单且最合适。

  2. 系统更简单，因为没有中间代理

  3. 促进编排，即服务可以根据其他服务的响应采取行动。

• 缺点

  1. 服务需要发现服务实例的位置。

  2. 服务之间的一对一映射。

  3. Rest 使用 HTTP，它是建立在 TCP/IP 之上的通用协议，在使用它来传递消息时会增加大量开销。

事件驱动架构

• 优势

  1. 事件驱动的架构对 API 开发人员很有吸引力，因为它们在异步环境中运行良好。

  2. 松耦合，因为它将服务解耦，因为在一次服务的事件中，多个服务可以根据应用程序要求采取行动。将任何新的消费者插入生产者都很容易。

  3. 提高了可用性，因为消息代理会缓冲消息，直到消费者能够处理它们。

• 缺点

  1. 消息代理的额外复杂性，必须具有高可用性
  2. 调试事件请求并不容易。