我正在研究服务器架构，用于从远程嵌入式设备发送/接收消息，这些设备将托管在Windows Azure上。前置服务器将维护与这些设备的持久TCP连接，我需要一种在后端与它们通信的方法。
问题事实：
向上沟通
设备非常频繁地发送消息（传感器读数）。由于我们可以以批量方式聚合/插入这些传感器读数，并且他们不需要有序保证，因此对该数据的约束不是很强。我认为处理它们的最佳方法是将它们放入存储队列，并让工作进程定期轮询队列并转储该数据。当然，我必须要小心确保工作进程足够频繁地执行此操作，以便队列不会无限备份。 Azure存储队列的最大批量大小为32，但我认为可能会提供更多的内容：例如，每1,000个读数或30秒发布到数据存储，以先到者为准。
向下沟通
服务器更不频繁地发送更新和通知。这是一个稍微难以解决的问题，因为我可以在这里看到两个可行的范例（两者之间有一些混合）。可以：
使用选项1，应用程序服务器只是以一种“一劳永逸”的方式将消息排入队列。然而，在前端服务器上，必须发生相当多的事情。我能看到的担忧包括：
好消息是服务总线队列是持久的，并且会话可以安排消息以FIFO方式进行。
使用选项2，数据库将容纳一个表，该表将维护所有设备的状态。前台服务器会定期检查此表（每隔几秒左右），以便应用程序服务器向其写入状态更改。然后，面向前方的服务器将分派给设备。这消除了对FIFO排队的要求，其原因是该消息包含最新状态，并且不必与发往同一设备的其他消息竞争。消息是短暂的：如果它失败，那么当设备重新连接并请求刷新时，或者在前置服务器的下一个检查间隔时，它将被重新发送。
在这种情况下，队列的需求似乎被删除了，但是数据库成为了瓶颈，我担心它不具备可扩展性。
这些都是可行的方法，我觉得这个问题已经变得太大了（尽管我可以在必要时提供更多描述）。只是想了解可能的事情，通常做了什么，如果有什么基本的东西我不知道，我可以利用云中的哪些东西来利用重新发明轮子。
答案 0 :(得分：0)
如果您可以通过它发送的消息识别设备（可能是设备ID / IMEI / Mac地址），那么您可以将队列数从10,000减少到1个队列，也不会有10000个订阅。这也可以帮助您进行向下通信，因为您将能够识别设备并将消息发送到适当的套接字。
正如您所提到的连接持续时间更长，您可以将命令传递给已连接的设备，并决定如何处理未连接设备的命令。
希望有所帮助