利用AWS IoT规则与替换模板构建高效物联网架构

本文深入探讨AWS IoT规则中替换模板的强大功能,通过实际案例展示如何简化物联网数据路由、实现智能负载平衡和条件消息分发,帮助构建更高效、可扩展且成本优化的服务器less物联网解决方案。

利用AWS IoT规则替换模板的强大功能

AWS IoT Core是一项托管服务,可帮助您安全地将数十亿物联网设备连接到AWS云。AWS IoT规则引擎是AWS IoT Core的一个组件,提供类似SQL的功能来过滤、转换和解码物联网设备数据。您可以使用AWS IoT规则通过规则操作将数据路由到20多个AWS服务和HTTP端点。替换模板是IoT规则中的一项功能,可在触发规则且AWS IoT执行操作时增强返回的JSON数据。本文探讨了带有替换模板的AWS IoT规则操作如何解锁更简单、更强大的物联网架构。您将学习经过验证的方法来降低成本并增强可扩展性。通过消息路由和负载平衡的实际示例,实现更智能、更高效的物联网解决方案。

理解基本组件

每个AWS IoT规则都建立在三个基本组件之上:处理消息过滤和转换的类似SQL的语句、运行并将数据路由到不同AWS和第三方服务的一个或多个IoT规则操作,以及可在SQL语句和规则操作中使用的可选函数。

以下是AWS IoT规则及其组件的示例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
   "sql": "SELECT *, get_mqtt_property(name) FROM 'devices/+/telemetry'", 
   "actions":[
    {
      "s3":{  
        "roleArn": "arn:aws:iam::123456789012:role/aws_iot_s3",
        "bucketname": "MyBucket",
        "key" : "MyS3Key"
      }
    }
   ]
}

SQL语句是规则处理的门户,根据特定的主题模式和条件确定应处理哪些MQTT消息。该规则采用类似SQL的结构,支持SELECT、FROM和WHERE子句。在此结构中,FROM子句定义MQTT主题过滤器,SELECT和WHERE子句指定应从传入消息中提取或转换哪些数据元素。

函数对SQL语句和IoT规则操作至关重要。AWS IoT规则提供了广泛的内部函数,用于转换数据类型、操作字符串、执行数学计算、处理时间戳等。此外,AWS IoT规则提供了一组外部函数,可帮助您从AWS服务检索数据并将其嵌入消息负载中。这些函数支持在规则处理管道内直接进行复杂的数据转换,无需外部处理。

规则操作决定了处理后数据的目的地和处理方式。AWS IoT规则支持一系列内置规则操作,可将数据传输到AWS服务,如AWS Lambda、Amazon Simple Storage Service、Amazon DynamoDB和Amazon Simple Queue Service。这些规则操作还可以将数据传输到第三方服务。每个规则操作都可以配置特定参数,以控制目标服务应如何传递或处理数据。

替换模板:隐藏的瑰宝

您可以在AWS IoT规则的SELECT和WHERE语句中实现函数,以转换和准备消息负载。但是,如果过于频繁地应用这种方法,您可能会忽略使用替换模板并在IoT规则操作中直接执行转换的强大选项。

替换模板支持使用${expression}语法将动态插入的值和规则函数插入规则操作的JSON中。这些模板支持许多SQL语句函数,例如时间戳操作、编码/解码操作、字符串处理和主题提取。当您在AWS IoT规则操作中使用替换模板时,可以实现复杂的路由,显著降低其他架构层的复杂性,从而创建更高效和可维护的AWS IoT解决方案。

实际实施模式

让我们深入探讨一些实际示例,展示在AWS IoT规则操作中使用替换模板的多功能性和强大功能。这些示例将演示此功能如何简化您的物联网数据处理管道,并解锁物联网应用中的新功能。

示例1:使用AWS IoT注册表属性进行条件消息分发

考虑一个常见的物联网场景,其中平台将设备消息分发给不同的业务合作伙伴,每个合作伙伴都有自己的消息处理SQS队列。车队中的不同设备由不同合作伙伴拥有,他们的关系在注册表中作为事物属性partnerId维护。

传统方法包括:

  • 选项1 – 在设备上维护合作伙伴路由逻辑。多个AWS IoT规则依赖WHERE条件输入负载:
    • 要求设备知道其合作伙伴的ID。
    • 增加设备复杂性和维护。
    • 暴露合作伙伴标识符带来安全问题。
    • 使合作伙伴变更难以管理。
  • 选项2 – 使用中间Lambda函数从AWS IoT注册表检索与设备关联的合作伙伴ID值,然后将消息传播到特定合作伙伴的SQS队列:
    • 增加不必要的计算和注册表查询成本。
    • 可能增加消息延迟。
    • 创建额外的故障点。
    • 需要维护路由逻辑。
    • 可能面临Lambda并发限制。

以下是使用替换模板和新的AWS IoT传播属性功能的更优雅解决方案和流程:

  • 将合作伙伴ID作为属性插入AWS IoT注册表。
  • 使用传播属性功能丰富您的MQTTv5用户属性,并使用设备的partnerId动态构建Amazon SQS队列URL。请参阅以下示例:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
{
    "ruleArn": "arn:aws:iot:us-east-1:123456789012:rule/partnerMessageRouting",
    "rule": {
        "ruleName": "partnerMessageRouting",
        "sql": "SELECT * FROM 'devices/+/telemetry'",
        "actions": [{
            "sqs": {
                "queueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/partner-queue-${get(get_user_properties('partnerId'),0}}",
                "roleArn": "arn:aws:iam::123456789012:role/service-role/iotRuleSQSRole",
                "useBase64": false
            }
        }],
        "ruleDisabled": false,
        "awsIotSqlVersion": "2016-03-23"
    }
}

使用此解决方案,具有partnerId="partner123"的设备发布消息。该消息自动路由到"partner-queue-partner123" SQS队列。

此解决方案的优势: 使用替换模板显著简化了架构,并为特定合作伙伴的消息分发提供了可扩展且可维护的解决方案。该解决方案:

  • 消除了对额外计算资源的需求。
  • 无需增加延迟即可提供即时路由。
  • 通过更新AWS IoT事物注册表简化合作伙伴关系管理。
  • 通过不向设备暴露队列信息来维护安全性。

示例2:使用Amazon Kinesis Data Firehose进行智能负载平衡

考虑一个场景,数百万设备向同一主题发布遥测数据。还需要将这些高容量数据分布在多个Amazon Data Firehose流中,以避免在将数据缓冲到Amazon S3时出现限制问题。

传统方法包括:

  • 设备端负载平衡
    • 实施配置管理以在不同设备间提供不同的流ID。
    • 要求设备在其消息中包含流目标。
    • 创建多个AWS IoT规则以匹配特定的流ID。
  • 基于AWS Lambda的路由
    • 部署Lambda函数以在流之间分发消息。
    • 实施自定义负载平衡逻辑。

传统方法表现出与前述示例相似的负面影响。此外,它们在高容量场景中呈现特定挑战,例如限制风险增加和复杂的流管理。

通过利用AWS IoT规则替换模板,您可以实施一个简化的、无服务器的负载平衡解决方案,通过以下方式动态将消息分配给不同的Firehose交付流:

  • 使用rand()*100000生成0-100000之间的随机数。
  • 将此随机数转换为整数。
  • 使用模运算获取除以8后的余数。
  • 将此余数附加到基本名称"firehose_stream_“后。

结果是消息随机分布在八个不同的Amazon Data Firehose流中。请参阅以下示例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
{ 
  "ruleArn": 
    "arn:aws:iot:us-east-1:123456789012:rule/testFirehoseBalancing", 
  "rule": { 
    "ruleName": "testFirehoseBalancing", 
    "sql": "SELECT * FROM 'devices/+/telemetry'", 
    "description": "", 
    "createdAt": "2025-04-11T11:09:02+00:00", 
    "actions": [ 
        { "firehose": { 
            "roleArn": "arn:aws:iam::123456789012:role/service-role/firebaseDistributionRoleDemo", 
            "deliveryStreamName": "firehose_stream_${mod(cast((rand()*100000) as Int),8)}", 
            "separator": ",",
            "batchMode": false 
        } 
     } 
    ], 
  "ruleDisabled": false, 
  "awsIotSqlVersion": "2016-03-23" 
  }
}

此解决方案的优势: 这种灵活的负载平衡模式通过将负载分散到多个流中来帮助处理高消息量。这种方法的主要优势在于其可扩展性。通过修改模函数,被除数可以调整以与所需的流数量相对应。例如:

  • 更改为mod(…, 4)以在4个流之间分布。
  • 更改为mod(…, 16)以在16个流之间分布。

使用此模板可以轻松扩展或缩小架构,而无需更改规则的核心逻辑。

示例3:在替换模板中使用CASE语句构建条件路由逻辑

考虑一个场景,您需要根据特定设备将物联网设备数据路由到基于生产的或开发/测试的Lambda函数。

传统方法包括:

  • 设备端负载平衡
    • 实施配置管理以在不同设备间提供不同的环境ID。
    • 要求设备在其消息中包含环境ID。
    • 创建多个AWS IoT规则以匹配特定的环境ID。
  • 基于AWS Lambda的路由
    • 部署Lambda函数,在根据AWS IoT注册表检查后,将消息分发到不同的环境AWS Lambda函数。

传统方法表现出与前述示例相同的负面影响。

以下是使用替换模板和新的AWS IoT传播属性功能的更优雅解决方案和流程:

  • 将环境ID作为所有设备的属性关联到AWS IoT注册表中。
  • 使用传播属性功能丰富您的MQTTv5用户属性。
  • 利用传播的属性在嵌入AWS IoT规则操作定义中的CASE语句内动态构建AWS Lambda函数ARN。

请参阅以下示例:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{ 
  "ruleArn": 
    "arn:aws:iot:us-east-1:123456789012:rule/ConditionalActions", 
  "rule": { 
    "ruleName": "testLambdaConditions", 
    "sql": "SELECT * FROM 'devices/+/telemetry'", 
    "description": "", 
    "createdAt": "2025-04-11T11:09:02+00:00", 
    "actions": [ 
        { "lambda": { 
            "functionArn": 
                "arn:aws:lambda:us-east-1:123456789012:function:${CASE get(get_user_properties('environment'),0) 
                    WHEN \"PROD\" THEN \"message_handler_PROD\" 
                    WHEN \"DEV\" THEN \"message_handler_DEV\" 
                    WHEN NULL THEN \"message_handler_PROD\" 
                    ELSE \"message_handler_PROD\" END }",  
        } 
     } 
  ], 
  "ruleDisabled": false, 
  "awsIotSqlVersion": "2016-03-23" 
 }
}

此解决方案的优势: 使用替换模板显著简化了架构,并为特定合作伙伴的消息分发提供了可扩展且可维护的解决方案。该解决方案:

  • 消除了为每个条件定义单独的IoT规则和IoT规则操作的要求。
  • 帮助您降低使用IoT规则和IoT规则操作的成本。

结论

本文探讨了AWS IoT规则的替换模板如何将复杂的物联网架构转变为优雅高效的解决方案。示例表明,替换模板不仅仅是一个功能——它们是一个强大的架构工具,利用AWS IoT功能有效解决复杂挑战,而无需引入额外的复杂性或成本。替换模板提供了一种无服务器、可扩展的方法,消除了对额外计算资源或复杂客户端逻辑的需求。这种方法不仅减少了运营开销,还通过移除不必要的计算资源和简化整体架构提供了直接的成本效益。

下次当您设计AWS IoT消息路由模式或面临扩展挑战时,请考虑替换模板如何提供更简单、更高效的解决方案。通过利用这些强大的AWS IoT功能,您可以创建更可维护、成本效益更高且可扩展的物联网解决方案,真正满足您的业务需求。

请记住:最简单的解决方案通常是最优雅的。借助AWS IoT规则替换模板,这种简单性已内置其中。

关于作者

Andrea Sichel是Amazon Web Services的首席物联网解决方案架构师,他帮助客户在物联网领域导航其云采用之旅。在好奇心和客户至上心态的驱动下,他致力于开发创新解决方案,同时保持在云技术的前沿。Andrea喜欢应对复杂挑战,并帮助组织对其物联网转型进行大胆思考。工作之余,Andrea指导他儿子的足球队,并追求他对摄影的热情。当不在相机后或足球场上时,您可以看到他游泳以保持活跃并维持健康的工作与生活平衡。

Avinash Upadhyaya是AWS IoT Core的高级产品经理,负责定义AWS IoT服务内的功能的产品战略、路线图优先级、定价和上市战略。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计