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

Question

我正在研究服务器架构，用于从远程嵌入式设备发送/接收消息，这些设备将托管在Windows Azure上。前置服务器将维护与这些设备的持久TCP连接，我需要一种在后端与它们通信的方法。

问题事实：

• 设备：~10,000
• 设备向服务器发送的消息频率：1 / min
• 发起服务器端的消息的频率（例如来自用户操作，预定触发器等）：100 /天
• 消息有效负载的平均大小：64字节

向上沟通

设备非常频繁地发送消息（传感器读数）。由于我们可以以批量方式聚合/插入这些传感器读数，并且他们不需要有序保证，因此对该数据的约束不是很强。我认为处理它们的最佳方法是将它们放入存储队列，并让工作进程定期轮询队列并转储该数据。当然，我必须要小心确保工作进程足够频繁地执行此操作，以便队列不会无限备份。 Azure存储队列的最大批量大小为32，但我认为可能会提供更多的内容：例如，每1,000个读数或30秒发布到数据存储，以先到者为准。

向下沟通

服务器更不频繁地发送更新和通知。这是一个稍微难以解决的问题，因为我可以在这里看到两个可行的范例（两者之间有一些混合）。可以：

1. 为每个设备创建一个服务总线队列（或一个包含数千个订阅的队列 - 限制队列数为10,000）
2. 将状态表放在包含最新＆＃34;状态＆＃34;的数据库中。将设备发送给他们的特定消息类型

使用选项1，应用程序服务器只是以一种“一劳永逸”的方式将消息排入队列。然而，在前端服务器上，必须发生相当多的事情。我能看到的担忧包括：

• 监控10k队列（或队列中的许多订阅 - Azure SDK显然会重用连接以进行订阅 队列）
• 连接管理
  • 如果设备断开连接，则不再监控队列。
  • 如果设备长时间断开连接，则需要使邮件过期（以便不备份队列）
  • 需要启用某种类型的＆＃34;刷新＆＃34;更新设备重新联机时的完整状态的机制

好消息是服务总线队列是持久的，并且会话可以安排消息以FIFO方式进行。

使用选项2，数据库将容纳一个表，该表将维护所有设备的状态。前台服务器会定期检查此表（每隔几秒左右），以便应用程序服务器向其写入状态更改。然后，面向前方的服务器将分派给设备。这消除了对FIFO排队的要求，其原因是该消息包含最新状态，并且不必与发往同一设备的其他消息竞争。消息是短暂的：如果它失败，那么当设备重新连接并请求刷新时，或者在前置服务器的下一个检查间隔时，它将被重新发送。

在这种情况下，队列的需求似乎被删除了，但是数据库成为了瓶颈，我担心它不具备可扩展性。

这些都是可行的方法，我觉得这个问题已经变得太大了（尽管我可以在必要时提供更多描述）。只是想了解可能的事情，通常做了什么，如果有什么基本的东西我不知道，我可以利用云中的哪些东西来利用重新发明轮子。

Answer 1

如果您可以通过它发送的消息识别设备（可能是设备ID / IMEI / Mac地址），那么您可以将队列数从10,000减少到1个队列，也不会有10000个订阅。这也可以帮助您进行向下通信，因为您将能够识别设备并将消息发送到适当的套接字。

正如您所提到的连接持续时间更长，您可以将命令传递给已连接的设备，并决定如何处理未连接设备的命令。

希望有所帮助