Azure服务总线-多个主题？

Question

因此，我简要介绍了我目前正在使用的工具：

我正在决定是否可以使用1个主题来进行此操作，而不是需要N个主题，并且都可以使用相关的元数据/过滤器来做到这一点。

我几乎有三件； 一个套接字服务器（工作者角色），在该服务器中，该字段中的单元连接到该服务器，Azure Service Bus消息传递，最后是一个Web应用程序。 用户可以将要通过Web应用程序发送到设备的命令排队，但是我们需要能够将消息保留在队列中，直到设备联机，然后设备将获得所有消息。 这就是我感到困惑的地方...

最初，我是在Web应用程序上针对正在排队的消息动态地创建1-9999个主题（可以创建10,000个主题，因此使用连续的4个字符）。 然后，设备将在元数据中具有完整的序列号。 这样，当设备连接到套接字服务器时，我可以创建具有特定规则的N个订阅，并在设备断开连接时将其关闭。

但是现在我想知道我是否只能拥有1个主题并将所有逻辑放在元数据中？

我对带有服务总线的SQLFilters很陌生，因此任何帮助将不胜感激:)

Answer 1

好问题！ 首先，我要说的是，在您的情况下，我将使用IoT中心，这是针对IoT场景，包括管理和命令而优化的“队列”式服务。 或事件中心，但它们对命令模式的优化较少。

1）活动中心

2）物联网中心

第一个是面向事件的方案。 我的意思是-从后端实施设备管理将通过事件中心变得更加复杂，而通过物联网中心变得更加简单。

我强烈建议您看一下这些服务，因为服务总线是很棒的服务，但是列出的服务更面向物联网。

从体系结构的角度来看，Microsoft最近发布了IoT参考体系结构白皮书，您可以在此处下载。 从Microsoft的角度来看，它具有可用于Azure + IoT项目的建议，服务，最佳实践等。

另一个有用的资源可能是http://azureiotsuite.com 。 这是已实现的参考物联网架构。 因此，如果单击“创建”，则Azure订阅中将具有两种参考体系结构之一（远程监视或预测性维护），并且您将能够查看所有流。

因此，我建议考虑使用IoT /事件中心而不是SB主题/队列，因为在IoT领域，针对这些工作负载进行了优化的服务应比最初未优化的服务表现更好。

其次，您没有指定如何将设备连接到Worker Role，因此我看到有一个很好的库可以称为SuperSocket 。

因此，正如我所见，您的解决方案体系结构可能类似于：

设备2云：

设备=>网关（SuperSocket或其他）|| IoT中心=>设备注册表（请参阅上面指定的链接）

Cloud 2设备：

用户界面=>具有已注册设备的IoT中心=>设备

与传送ID或类似信息相比，设备注册表是进行IoT流程更方便的方法。实体的动态创建有一些缺点-想象一下，例如，如果创建命令将返回超时错误。 我相信最好使用优化的服务。

设备处于脱机状态时，它不会轮询队列。 消息有一定的保留时间，然后才能停止，这是内置机制。