面向物联网的云体系结构

Question

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

问题事实：

• 设备：~10,000
• 消息设备发送到服务器的频率: 1/min
• 源自服务器端的消息的频率(例如来自用户操作、预定触发器等)：每天100次
• 消息有效负载的平均大小:64个字节

上行通信

这些设备非常频繁地发送信息(传感器读数)。对于这些数据的限制不是很强，因为我们可以批量地聚合/插入这些传感器读数，而且它们不需要有序的保证。我认为处理它们的最好方法是将它们放入存储队列中，并让工作进程每隔一段时间轮询队列并转储数据。当然，我必须小心确保工作进程足够频繁地执行此操作，这样队列就不会无限备份。Azure存储队列的最大批处理大小为32，但我考虑的可能更多:比如每1,000次向数据存储发布一次，或30秒，以第一位为准。

下行通信

服务器发送更新和通知的频率要低得多。这是一个稍微困难的问题，因为我可以在这里看到两个可行的范例(其中有些是混合的)。可以：

1. 为每个设备创建一个服务总线队列(或一个具有数千个订阅的队列-对队列数量的限制是10,000)
2. 将状态表保存在DB中，其中包含设备将发送给它们的特定消息类型的最新“状态”。

使用选项1，应用程序服务器只需以一种即席即忘的方式对消息进行排队。然而，在前端服务器上，有很多事情必须发生。我能看到的关切包括：

• 监视10k队列(或队列中的许多订阅- Azure SDK显然重用对同一个队列的订阅的连接)
• 连接管理
  • 如果设备断开连接，则不再监视队列。
  • 如果设备被断开很长一段时间(因此队列没有备份)，则需要过期消息。
  • 需要启用某种类型的“刷新”机制，以便在设备恢复联机时更新设备的完整状态

​

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

使用选项2，DB将包含一个表，该表将维护所有设备的状态。该表将由前端服务器(每隔几秒钟左右)定期检查由应用服务器写入的状态更改。前面的服务器随后将分派到设备上。这消除了FIFO排队的要求，理由是该消息包含最新的状态，并且不需要与发送给同一设备的其他消息竞争。这条消息是短暂的:如果它失败了，那么当设备重新连接并请求刷新时，或者在前端服务器的下一个检查间隔时，它就会感到不满。

在这个场景中，对队列的需求似乎被删除了，但是DB成为了这里的瓶颈，我担心它没有那么可伸缩。

这两种方法都是可行的，我觉得这个问题已经变得太大了(虽然我可以在必要的时候提供更多的描述)。我只是想感受一下什么是可能的，什么是通常做的，如果我缺少一些基本的东西，以及云中的什么东西，我可以利用它来避免重新发明轮子。

Answer 1

如果您可以通过设备发送的消息来标识设备(可能是设备id/IMEI/Mac地址)，那么您可以将队列数量从10,000条减少到1,000个队列，并且没有10000个订阅。这也可以帮助您向下通信，因为您将能够识别设备并将消息发送到适当的套接字。

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

希望它能帮上忙