背景介绍
物联网场景中，终端设备的生产者和销售者往往并不是同一个，而产品的最终使用地点也可能因为销售路径的不同而有差异。为了在全球区域提供相同的使用体验，设备应该能够根据其所在的区域进行自发性的连接选择，并通过这种方式提供更低的网络时延。作为 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 两种认证方式。下表给出了几种接入方式的对比：
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 定制自己的身份认证过程。
在本文中，我们假定设备出厂时已经预置了设备证书和 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 的连接地址。
7. 设备向云端发起设备注册请求，云端调用 RegisterThing API 注册设备，并返回注册结果。(标注3)
设备在发起请求时，上传 ThingName 和设备证书，ThingName 这里取设备的 MAC 地址。云端在调用 API 时传入的参数如下：
template-body:
{
"Parameters" : {
"ThingName" : {
"Type" : "String"
},
"DevicePem" : {
"Type" : "String"
},
"CaPem": {
"Type" : "String"
}
},
"Resources" : {
"thing" : {
"Type" : "AWS::IoT::Thing",
"Properties" : {
"ThingName" : {"Ref" : "ThingName"}
}
},
"certificate" : {
"Type" : "AWS::IoT::Certificate",
"Properties" : {
"CACertificatePem": {"Ref" : "CaPem"},
"CertificatePem" : {"Ref" : "DevicePem"}
}
},
"policy" : {
"Type" : "AWS::IoT::Policy",
"Properties" : {
"PolicyDocument" : "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\":[\"iot:Publish\"], \"Resource\": [\"arn:aws:iot:us-east-1:123456789012:topic/foo/bar\"] }] }"
}
}
}
}
parameters:
{
"ThingName": "<MAC address>",
"DevicePem": "<Device Certificate String>",
"CaPem": "<CA Certificate String>"
}
这里，设备并没有上传 CA 证书，是因为在出厂时所有的设备均使用同一个 CA 签发的设备证书。
Tips: 相同的 CA 证书上传到不同的 AWS region, 返回的 CA ID 相同，方便使用 CloudFormation 部署。
8. 设备在获得成功注册的返回值后，通过 MQTT 连接至 AWS IoT（标注4）
9. APP 向云端查询设备是否注册成功，如果已经注册成功，则在数据库中建立用户和设备的绑定关系。（标注5）
10. APP 向云端发起请求，申请接入 AWS IoT 的临时授权 （标注6）
步骤3处 Lambda 先查询用户和设备的绑定关系，然后再向 STS 申请临时授权。
11. APP 获得临时授权之后，连接到 AWS IoT Device Gateway, 初始化完成（标注7）
总结
我们在设备初始化的过程中，使用设备的位置作为参数向云端申请属于该地区的配置信息，然后根据配置信息连接到不同的 AWS region。在此基础上，我们再通过 CloudFormation，将服务部署到不同的 AWS region。
此外，在全球范围内，我们只需要维护一个服务配置 Endpoint 来提供配信信息。我们只需要修改该 Endpoint 的代码来增加或修改配置参数。
AWS技术峰会 2018将于8月9日在北京国家会议中心隆重拉开帷幕。在13:00 – 17:30于一层多功能厅C将会有物联网分论坛，在本论坛中，您将了解 AWS 的 IoT 服务，及聆听 AWS 用户分享基于 AWS 的智能家居、全球智能化物联网及工业互联方面的经验和实践。
想和我们一起#所建不凡#？快来注册#AWS技术峰会2018，前20名注册的小伙伴将可获得 $50亚马逊优惠券，抓住机会，赶快注册吧！https://awssummit.cn?tc=1s016B2uQi
共同学习，写下你的评论
评论加载中...
作者其他优质文章
