网关

充当本地设备之间，以及设备和云之间的中介的设备。

挑战

IoT 解决方案中的端点通常不具备直接连接互联网的能力，或者是运行在无法直接访问互联网的网络中。即使存在这些限制，从端点获取数据并与这些端点进行交互需要有相应的连通机制

解决方案

IoT 解决方案使用"网关"设计来克服端点通常遇到的限制。通过这样的设计网关可以实现与端点的可靠及安全的通信

如下图所示的"网关"设计可以提供这样的功能。图中服务器(Server)是运行在云中。网关(Gateway)则运行在设备可以访问的网络中

Gateway Design (PPTx)

上图中的两个设计均提供一个网关端点，其使用与服务器相同类型的协议端点(Protocol Endpoint)。在上行和下行网关设计图中，网关是连接到服务器的

上行网关(即"北向")

  1. “上行"网关设计是用来复制上行消息;在这个设计图中，telemetry/deviceID主题上的消息是来自于设备，这些消息会被复制到服务器同样的主题里
  2. 设备发布包含测量值的消息，通过传输协议来到网关提供的本地协议端口
  3. 网关接收到消息
  4. 网关将消息发布到服务器中同样的主题
  • 如果网关无法成功将消息发送至服务器，则会以上行消息方法对处理该消息
  1. 服务器接收到消息

下行网关(即"南向”)

  1. 下行网关是用来监听服务器并复制下行的消息; 在设计图中，来自服务器的消息在commands/deviceID主题并且会被复制到监听同样主题的设备
  2. 服务器通过传输协议端点向网关发布消息
  3. 网关接收到消息
  4. 网关向监听同样主题的服务发布消息
  • 如果网关无法成功将消息发送到设备，则消息会以下行消息方法处理该消息
  1. 设备接收消息

考虑点

当实现这个设计时，需要考虑如下问题：

为什么网关在某个方向上应该只显式的复制特定的主题？

待答

在与设备间的网络不可用时，网关该如何处理数据？

简单的回答是网关需要一种下行消息处理方法，将数据保存在网关上直至他们可以被发送给设备。不幸的是，简单的答案掩盖了更为复杂的现实。需要确定的一个关键事情是正确的方法在网络不可用时处理下行消息

在与服务器的网络不可用时，网关该如何处理数据？

简单的回答是网关需要一种上行消息处理方法，将数据保存在网关上直至他们可以被发送给服务器。不幸的是，简单的答案掩盖了更为复杂的现实。需要确定的一个关键事情是正确的方法在网络不可用时处理上行消息

应该使用什么方法来存储后续需要发送的消息？

通常来说，网关上消息的本地存储和处理将遵循先进先出（即 FIFO）方法。话虽如此，但答案可能会有所不同，这具体取决于消息中实际包含的数据。在这种情况下，通过确定网关日志记录方法对实际报告数据的影响，可以帮助我们避免以后出现的问题。

如下图所示，通常考虑三种类型的方法：先进先出(FIFO), 剔除(Culling) 和 聚合(Aggregate)。

Message Processing Algorithms

先进先出(FIFO) – 这种方法通常实现起来比较直接，在多种场景下都很有用。在这种方法的消息处理图中可以看到，数据从左侧到达，当本地存储空间满后，数据从右侧离开。具体数据的例子包括：维护测量数据和通用的遥测数据

剔除(Culling) - 这种方法对于在丢失曲线细节时保留绝对点值非常有用。在消息处理图中，此方法的数据从左侧到达。一旦本地存储中已存放超过剔除点的数据，则一些清除逻辑会移除出其他所有样本（或每N个样本）。具体数据的例子包括: 千瓦(kW), 安培(Amperage), 伏特(Voltage), etc

聚合(Aggregate) – 当曲线的详细形状不如一段时间内的最小值，最大值，平均值和总和值那么重要时，此方法很有用。在消息处理图中，此方法的数据从左侧到达。一旦本地存储存放超过聚合点数据时，一些清除逻辑就对存储的值执行聚合。数据的例子包括: 千瓦时(kWh), 日照时间, 流, CPU 时间, 温度, 风速等等.

示例

<tbd written scenario>