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