订阅队列的 Web API 应用程序.这是个好主意吗?

Question

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

Answer 1

由于微服务架构是非固执己见的软件设计。因此，您可能会在这些问题上得到不同的答案。 是的，REST和基于事件是两个不同的东西，但有时两者结合起来可以提供设计以实现更好的灵活性。

回答您的疑虑，我认为如果REST API 也订阅队列，只要您可以同时维护它们，即对消息的更改不会对 API 产生任何影响，并且您有适当的回退和最终一致性机制到位。 你可以检查讨论。已经很少有项目尝试过，例如纳卡迪和庞特。

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

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

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

基于 REST 的架构

• 优势

  1. 当您需要同步环境时，请求/响应很容易且最适合。

  2. 更简单的系统，因为没有中间经纪人

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

• 缺点

  服务

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

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

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

事件驱动架构

• 优势

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

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

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

• 缺点

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