单个微服务是否应该监听单个 azure bus 主题/队列？

Question

我们有一个 Azure 服务结构微服务，它监听多个 Azure 服务总线主题（主题 A、主题 B）。

主题 A 的消息流量是主题 B 的 10 倍以上。为了处理服务的可扩展性，我们将创建多个服务实例。

1. 我的第一个问题是，在大部分服务实例中都不会收到Topic B中的消息，因为Topic B流量少，会不会浪费资源？

2 为 Topic A 和 Topic B 的监听器创建不同的微服务，创建 10x 个微服务实例来监听主题 A 和 x 个主题 B 监听器服务的实例是不是更好？

1. 是否在 Azure 服务总线中创建消息侦听器，每次都继续拉消息？表示不断寻找/检查消息，消息是否存在。

感谢大家的支持。

Answer 1

1. 如果一项服务接收来自 2 个主题的消息，则几乎不会浪费资源。侦听消息不是一个非常耗费资源的过程。
2. 这取决于您的应用要求。
3. 这取决于您是使用 SBMP / SOAP（默认）还是 AMQP 作为通信协议。 AMQP 是基于连接的。 SBMP 进行（长）轮询。

Answer 2

微服务提倡松耦合服务的理念，每个微服务将处理自己的领域。

遵循微服务方法，如果您了解必须创建两个不同的主题来发布消息，可能是因为它们具有不同的范围\域，需要自己的微服务。

在您的描述中，很难确定TopicA和TopicB的领域是否相关，因此我们无法提供好的建议。

在任何情况下，如果一个服务同时监听两个主题，我们假设 TopicA 每秒处理 1000 条消息，而 TopicB 每秒处理 100 条消息。 如果您必须发布应用程序的新版本来处理 TopicB 消息的更改，则必须停止处理 TopicA，这不是必需的。所以你正在耦合服务，一开始应该是两个独立的服务，或者两个主题应该作为一个单独的主题来处理。

关于您的问题：

1 我的第一个问题是，在大多数服务实例中都不会得到 Topic B中的消息，由于Topic B流量少，所以会这样 浪费资源？

资源浪费与您设计应用程序的方式有关，如果您的服务同时侦听队列\主题并处理它，并且使用过多的内存来一直运行，则可能是这样。在这种情况下，将它们拆分并制作一个 Queue\Topic Listener 和其他 Message Handler 将接收要处理的消息，如果它保持太久而没有处理你关闭它的消息，只留下监听器。您也可以使用演员而不是服务。

2 为主题 A 和创建不同的微服务是否更好？ 主题 B 监听器，并创建 10x 的微服务实例 监听主题 A 和主题 B 监听服务的 x 实例？

对服务来说是的，关于实例的数量，它应该由队列的大小来驱动，否则你的监听器会太多，而且会浪费资源，如果你按照服务拆分的方式，你会需要一个侦听器从队列\主题接收消息，并将消息传递给多个消息处理程序（服务实例\参与者），队列\主题侦听器同时控制运行实例的数量。

3 在 Azure 服务总线中创建一个消息监听器，继续拉 每次都发消息？意味着不断寻找/检查消息， 消息是否存在。

不是唯一的方法，但它是正确的。