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. 其余使用的HTTP是建立在TCP / IP之上的通用协议，在使用它传递消息时会增加大量的开销。

事件驱动架构

• 优势

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

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

  3. 由于消息代理缓冲消息直到消费者能够处理消息，因此提高了可用性。

• 缺点

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