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

EN

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

HTTP协议是同步的

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

AMQP

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

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

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

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

来自文章：

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

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

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