亚马逊AWS官方博客
物联网设备全球部署架构方案
AWS IoT 物联网系列博客
当前物联网环境中,设备类型多种多样,连接方式不一而足。为了帮助读者更好的理解并运用 AWS IoT 相关服务,我们提供了一个完整的 IoT 起步指南,包含设备的注册及上线、设备管理、用户身份及权限管理以及成本控制,通过这一系列的起步指南,也可以快速了解到 AWS IoT 服务如何与 Amazon Alexa 语音助手进行集成。AWS IoT 物联网系列共8篇,本篇是该系列的第一篇,其他篇链接请在本文结尾处查看。
背景介绍
物联网场景中,终端设备的生产者和销售者往往并不是同一个,而产品的最终使用地点也可能因为销售路径的不同而有差异。为了在全球区域提供相同的使用体验,设备应该能够根据其所在的区域进行自发性的连接选择,并通过这种方式提供更低的网络时延。作为 IoT 服务提供者,需要设计部署一套跨区域的合理架构从而满足这样的需求。
本文将根据以上的场景,探讨如何利用 AWS 的服务进行架构设计和业务逻辑设计。
必备知识
这篇文章将着重于架构和业务逻辑的设计,整个方案会使用到如下 AWS 的相关服务,建议读者先了解其相关功能,便于理解整个方案。
- IoT Core: 用于设备连接,设备管理,设备认证,消息转发。
- Lambda: 提供设备配置信息,调用 AWS IoT Core API, DynamoDB API。
- API Gateway: 管理维护 Restful API,并且触发 Lambda。
- DynamoDB: 存放用户和设备的绑定关系。
- STS: 获得 AWS 临时授权,用于设备连接至 IoT Core。
- CloudFormation: 帮助用户在不同地区快速部署相同的架构、服务。
应用场景业务逻辑分析
在常见的 IoT 场景中,用户通常使用手机 APP 来对设备进行初始化操作,在初始化的过程中设备决定连接到哪个地区的 AWS。下面是一套常见的设备初始化业务流程:
- 启动设备, 并进入 WIFI Hotspot 状态
- 手机连接设备 WIFI,启动 App, 并进入配置状态
- 用户在配置页面输入家庭 WIFI 的 SSID、密码
- 用户在配置页面手动或自动选择设备所在的地区(重要)
- 用户点击配置完成,设备自动连接至家庭 WIFI
- 手机切换连接至家庭 WIFI
- 手机端显示配置完成
这里值得注意的是:
- 在上述步骤2中,手机连接的是设备 WIFI。这样才能使得 APP 和设备处于同一个网络中,才能把家庭 WIFI 的配置信息下发给设备。
- 在步骤4中,用户在配置的过程中可以手动选择设备所在地区,如所在国家、所在省、州(以下称为 region code)。当然,我们也可以通过判断设备 IP 地址所在地区或者手机 GPS 等方式获取所在地区的信息,但这样的方式也存在弊端。譬如通过 IP 地址查询的方式依赖于其查询的数据源是否准确;通过手机 GPS 的方式可能在室内并不精准。在本文中,我们将使用手动选择的地区的方式进行配置。
业务逻辑解决方案
上一章节中,我们了解了用户的使用场景,那么设备又如何连接到云端呢?云端又如何做身份识别的呢?
AWS IoT 提供了 MQTT, MQTT over WebSocket, HTTP 三种接入方式,以及 X.509 设备证书和 HTTP SigV4 两种认证方式。下表给出了几种接入方式的对比:
接入协议 | 认证方式 | 推荐场景 | SDK | SDK 支持语言/平台 |
MQTT | 设备证书 | 设备接入 | AWS IoT Device SDKs | C, C++, Java, JavaScript, Python |
MQTT over WebSocket | SigV4 | Web 接入 移动端接入 |
AWS IoT Device SDKs | JavaScript(node.js) iOS Android |
HTTP | 设备证书 SigV4 |
REST API 接入 | AWS SDKs | Java, .NET, Node.js, PHP, Python, Ruby, Browser(JavaScript), Go, C++ |
AWS IoT 接入的方法有很多,用户可以根据自己的业务场景,选择适合的接入协议和认证方式。这里需要注意的是 MQTT 或 MQTT over WebSocket 支持云端主动向客户端发送消息,而 HTTP 则不能。
在本文中,设备端通过 MQTT + 设备证书 的方式接入,手机端通过 MQTT over WebSocket + SigV4 的方式接入。那么设备的证书又如何下方给设备呢?
AWS 提供了多种证书下发的方式,如果使用您自己的 CA 签发的设备证书,您可以通过 JITR(Just-In-Time-Registration) 或 JITP(Just-In-Time-Provision) 的方式将设备连接至云端并指定相关控制策略;如果使用 AWS IoT Core 签发的设备证书,您可以通过 CVM(Certificate Vendor Machine) 的方式将设备连接至云端并控制相关控制策略;当然,用户也可以根据自己的需求使用 AWS IOT API 定制自己的身份认证过程。
证书下发方式 | Root 证书 | 出厂时预置设备证书 |
JITR | 用户 CA | Yes |
JITP | 用户 CA | Yes |
CVM | AWS CA | No |
在本文中,我们假定设备出厂时已经预置了设备证书和 CA 证书。
当用户首次拿到一台设备的时候,需要对设备进行初始化配网设置,在配网过程中,我们使用 AWS IoT API Programmatic Provisioning 自定义证书的激活流程。结合在配网过程中,用户的实际操作流程,每一步的具体技术实现细节如下:
在上图中,实现步骤可以参考如下说明:
- 将设备变成 WIFI 热点模式,设备设置为静态 IP 地址,并监听配置命令
- 手机连接至设备 WIFI(非家庭 WIFI)
- 进入 APP, 输入家庭 WIFI 的 SSID, password,并选择地区信息(标注1)
- APP 将配置信息发送到设备的静态 IP,设备返回 MAC 地址
- 设备退出 WIFI 热点模式,连接至家庭 WIFI, 并且进入初始化状态
- 设备从服务配置 Endpoint 获得该地区的配置信息,并存储到本地。此时需要将地区信息作为参数传给服务配置 Endpoint. 服务配置 Endpoint 全球只需部署一份(标注2)上图中的 country 和 state 组成了服务端所需的地区信息。服务端收到地区信息后返回该地区对应的配置信息。配置信息中至少包含两个地址,一个是证书激活的地址,另外一个是 AWS IoT 的连接地址。
- 设备向云端发起设备注册请求,云端调用 RegisterThing API 注册设备,并返回注册结果。(标注3)设备在发起请求时,上传 ThingName 和设备证书,ThingName 这里取设备的 MAC 地址。云端在调用 API 时传入的参数如下:
template-body:
parameters:
这里,设备并没有上传 CA 证书,是因为在出厂时所有的设备均使用同一个 CA 签发的设备证书。
Tips: 相同的 CA 证书上传到不同的 AWS region, 返回的 CA ID 相同,方便使用 CloudFormation 部署。 - 设备在获得成功注册的返回值后,通过 MQTT 连接至 AWS IoT(标注4)
- APP 向云端查询设备是否注册成功,如果已经注册成功,则在数据库中建立用户和设备的绑定关系。(标注5)
- APP 向云端发起请求,申请接入 AWS IoT 的临时授权 (标注6)步骤3处 Lambda 先查询用户和设备的绑定关系,然后再向 STS 申请临时授权。
- APP 获得临时授权之后,连接到 AWS IoT Device Gateway, 初始化完成(标注7)
总结
我们在设备初始化的过程中,使用设备的位置作为参数向云端申请属于该地区的配置信息,然后根据配置信息连接到不同的 AWS region。在此基础上,我们再通过 CloudFormation,将服务部署到不同的 AWS region。
此外,在全球范围内,我们只需要维护一个服务配置 Endpoint 来提供配信信息。我们只需要修改该 Endpoint 的代码来增加或修改配置参数。