这是我现在正在处理的内容的简要总结：
我决定是否可以使用1个主题与需要N个主题以及相关的元数据/过滤器来完成此任务。
我几乎有3件;套接字服务器（辅助角色），该字段中的单元连接到该服务器，Azure Service Bus消息传递，最后是Web应用程序。 用户可以将命令排队通过Web应用程序发送到设备，但我们需要能够将消息保存在队列中，直到设备上线，然后它将获得所有消息。这是我感到困惑的地方......
我最初的工作是在Web应用程序中动态创建1-9999个主题（可以创建10 000个主题的限制，因此使用最后4个串行字符）排队的消息。然后，将在元数据中使设备完全串行。这样，当设备连接到套接字服务器时，我可以创建具有特定规则的N个订阅，并在设备断开连接时将其关闭。
但现在我想知道我是否只能拥有1个主题并将所有逻辑放在元数据中？
我对使用服务总线的SQLFilters非常新，所以任何帮助都会非常感激:)
答案 0 :(得分：2)
好问题！首先，我应该说我会在你的情况下使用IoT Hubs，这是一种针对物联网场景，管理和指挥优化的“队列”式服务。或者事件中心，但它们的命令模式优化程度较低。
1）事件中心
2）物联网中心
第一个是针对更多面向事件的场景。我的意思是 - 从后端实施设备管理对于事件中心来说会更复杂，而对于物联网中心则更简单。
我强烈建议您查看这些服务，因为Service Bus是一项很棒的服务，但列出的服务更多是面向物联网的。
从架构的角度来看，最近Microsoft发布了您可以在此下载的IoT参考架构白皮书。从Microsoft的角度来看，它具有可用于Azure + IoT项目的建议，服务，最佳实践等。
另一个有用的资源可能是http://azureiotsuite.com。它是实现的参考物联网架构。因此，如果单击“创建”，您将在Azure订阅中拥有两种参考体系结构之一（远程监视或预测性维护），并且您将能够查看所有流程。
因此，我建议考虑使用物联网/事件中心而不是SB主题/队列，因为在物联网领域，针对这些工作负载优化的服务应该比最初未优化的服务表现更好。
其次，您没有指定如何将设备连接到辅助角色，因为我看到有一个很好的库，用于执行SuperSocket。
因此，我认为您的解决方案架构可能如下所示：
设备2云：
Devices =＆gt;网关（SuperSocket或其他）|| IoT Hub =＆gt;设备注册表（参见上面指定的链接）
Cloud 2设备：
用户界面=＆gt;具有注册设备的IoT Hub =＆gt;设备
设备注册表比传输ID等更方便地进行物联网流动。实体的动态创建有一些缺点 - 想象一下，如果创建命令将返回超时错误，例如。我相信，最好使用优化服务。
当设备离线时，它不会轮询队列。消息在停止之前有一些保留时间，即内置机制。