azure - Azure上的云架构，用于物联网

Question

我正在开发一个服务器体系结构，用于从远程嵌入式设备发送/接收消息，该设备将托管在WindowsAzure上。前端服务器将与这些设备保持持久的TCP连接，我需要一种在后端与它们通信的方法。
问题事实：
设备：~10000
设备向服务器发送消息的频率：1/min
来自服务器端的消息频率（例如来自用户操作、预定触发器等）：100/天
消息负载的平均大小：64字节
向上沟通
这些设备经常发送信息（传感器读数）。由于我们可以批量收集/插入这些传感器读数，并且它们不需要顺序保证，因此对这些数据的约束不是很强。我认为处理它们的最佳方法是将它们放入存储队列中，让工作进程每隔一段时间轮询队列并转储数据。当然，我必须注意确保工作进程足够频繁地执行此操作，这样队列就不会无限地备份。azure存储队列的最大批处理大小是32，但我考虑的可能不止这些：比如每隔1000次读取或30秒（以先到者为准）发布到数据存储。
下行通信
服务器发送更新和通知的频率要低得多。这是一个稍微难一点的问题，我可以在这里看到两个可行的范例（其中有些是混合的）。可以：
为每个设备创建一个服务总线队列（或一个具有数千个订阅的队列-限制为队列数为10000）
在数据库中有一个状态表，其中包含设备将发送给它们的特定消息类型的最新“状态”
有了选项1，应用服务器只需将消息以一种火上浇油的方式排队。然而，在前端服务器上，有很多事情必须发生。我看到的问题包括：
监视10000个队列（或队列中的多个订阅）
显然，Azure SDK会重用订阅的连接
队列）
连接管理
如果设备断开连接，则不再监视队列。
如果设备长时间断开连接，则需要使消息过期（这样队列就不会备份）
需要启用某种类型的“刷新”机制，以便在设备重新联机时更新其完整状态。
好消息是，服务总线队列是持久的，通过会话可以安排消息以先进先出的方式发送。
使用选项2，DB将存储一个表，该表将维护所有设备的状态。前台服务器（每隔几秒钟左右）将定期检查此表，以查看应用程序服务器是否对其进行了状态更改。然后，面向前端的服务器将发送到设备。这消除了对FIFO排队的要求，理由是该消息包含最新状态，并且不必与其他发送给同一设备的消息竞争。消息是短暂的：如果失败，那么当设备重新连接并请求刷新时，或者在前向服务器的下一个检查间隔时，将重新发送消息。
在这种情况下，对队列的需求似乎被消除了，但是数据库在这里成为了瓶颈，我担心它的可扩展性不够。
这两种方法都是可行的，我觉得这个问题已经变得太大了（尽管我可以在必要时提供更多的描述）。只是想感受一下什么是可能的，什么是通常会做的，如果我缺少一些基本的东西，我可以利用云中的什么东西来不重新发明轮子。

Answer 1

如果您可以通过设备发送的消息来识别设备（可能是设备ID/IMEI/MAC地址），那么您可以将队列数从10000减少到1个队列，并且也不需要10000个订阅。这也有助于您向下通信，因为您将能够识别设备并将消息发送到适当的套接字。
正如您所提到的连接持续时间更长，您可以将命令传递到已连接的设备，并决定如何处理未连接的设备的命令。
希望有帮助