一个微服务可以同时有listener和point吗?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (34)
  1. 一种侦听RabbitMQ和处理消息的侦听器方法。
  2. 休眠端点,可用于在需要时发布相同的消息,并且剩余处理相同。

选项1:我的想法是拥有两个不同的应用程序,一个只监听来自的消息RabbitMQ,另一个只接收来自使用REST端点的其他客户端应用程序的消息。

选项2:一个具有两个功能的应用程序 - 可以监听消息并可以根据REST请求接收消息。

请帮助我总结出哪种方法是正确的。

提问于
用户回答回答于

来自文章

我的另一条方法是从一些粗粒度的服务开始,大于你期望的最终服务。使用这些粗粒度服务来习惯于使用多种服务,同时享受这种粗粒度可以减少您必须执行的服务间重构的事实。然后随着边界稳定,分解成更细粒度的服务

也许在早期,消息结构仍然不稳定并且定期更改。如果将功能部署为单独的应用程序,则无论如何都必须重新部署这两个应用程序。因此,请将功能保留在同一个应用中。

最终,事情稳定下来,最终确定了v1消息结构。消息量是多少?是否存在性能问题?是否仍然在同一个应用程序中的功能?

用户回答回答于

“如果需要可以用来发布相同消息并且剩余处理相同的休息端点”,我不同意这一点,并且会破坏微服务的目的。您应该只使用消息队列。我在下面解释一下。

HTTP协议是同步的

有一种非常广泛的误解,即HTTP是异步的。Http是同步协议,但您的客户端可以将其处理为异步。例如,当您使用http调用任何服务时,您的http客户端将调度在后端线程(异步)上。然而,http呼叫将等待,直到它的超时或响应返回,在这段时间内,http呼叫链正在等待同步。您的线程忙,直到您的http端点完成并处理请求并回复。

AMQP

在微服务架构中,我们更喜欢AMQP(高级消息队列协议)。这意味着该服务将消息丢弃在队列中并忘记它。这是真正的异步传输协议,因为一旦将消息放入队列中就完成了服务,感兴趣的服务将选择这些服务。

您的微服务负责通过将消息放入队列来通知其他微观事件。但它不应该负责处理它的其他微服务。在上述通过http调用的情况下,您不仅要删除消息,还要等待它被处理,这使得这种系统难以扩展。

AMQP类型的协议是首选,因为即使其他服务已关闭,您也可以毫无顾虑地进行扩展,因为它们最终会获得消息/事件/数据。

这就是为什么HTTP不是共享消息/数据的首选方式。

扫码关注云+社区

领取腾讯云代金券