目录

1. 前言

1.1 项目简要说明

1.2 任务概述

1.3 术语定义

2 需求分析

3 原理概述

3.1 协议分析

4. 系统架构描述

4.1 架构设计

4.2 模块结构

4.3 接口流程图

5. 任务（或进程/线程）设计

5.1 原理

5.2 流程设计

6.  数据库设计

6.1 选型

6.2 数据库表结构设计

7 接口概要设计 

1. 前言

1.1 项目简要说明

        此项目是TP-LINK公司所属的一个项目，在此只做技术分享，不为任务商业用途。IFTTT 在全球 IoT 生态中占有一席之地，囊括了众多同类竞品的设备，可帮助用户实现跨品牌多设备之间的联动控制。根据 Action、Query 和 Trigger 业务场景设计，TP-LINK公司的Tapo 设备 如 Tapo Plug 和 Tapo Bulb 需要支持在 IFTTT 创建规则的情况下被连接和控制，同时 IFTTT 也需要接收来自 Tapo 设备的事件。所以此次项目实现 IFTTT-Iot Adapter 服务， 提供接口供 IFTTT 调用，内部对接 IoT-App Server，实现负责 IFTTT 和 IoT-App Server 之间消息的协议转换和转发。

1.2 任务概述

        新增一个 IFTTT-IOT Adapter 服务，支持配置开发 IFTTT service，具备新增如下功能：提供 Action 、Query 和 Trigger 接口供 IFTTT 调用；根据服务名分发请求到具体的服务；各个服务实现协议转换，调用自己的云端服务，如 Tapo 通过 gRPC 客户端调用 IoT[1]App Server 服务；新增处理设备状态更改事件的 kafka 消费者任务，消费事件，调用 IFTTT 的 http 实时 接口进行通知；对接 soho poller（事件分发模块），接收账号注销请求，清理用户数据。

        开发前需要仔细阅读官方开发文档，根据开发文档的指引和规范，设计好自己要实现的服务，明确接口的请求必要参数和相应数据格式以及请求流程。Ifttt要求开发者的服务暴露的接口需要满足开发文档的要求，主要有三类接口，分别是Action、Query和Trigger，另外都有其对应的field接口即获取字段属性。不同类型的请求接口有不同的请求参数和相应数据格式的要求。另外服务需要支持ifttt系统测试用例，要求服务实现一个testsetup接口完成测试准备工作并返回测试数据，服务内部需要区别测试模型下的请求并做对应的处理。服务在产生事件并需要上报的时候，调用ifttt的实时通知接口https://realtime.ifttt.com/v1/notifications ，之后ifttt会调用trigger获取事件消息。具体细节请查阅官方文档 Service API requirements - IFTTT。开发完服务并部署之后就可以在ifttt网站上创建service，完善必要的文案信息和接口细节，通过系统的自带测试用例过后，便可以创建小程序进行If This Then That的测试了。

       此项目使用springboot技术开发。

1.3 术语定义

2 需求分析
 

3 原理概述

        由于 IFTTT 可以对接多个不同的服务，计划在实现的 IFTTT-Iot Adapter 中增加支持多个 服务的功能，与 IFTTT 对接的接口将请求根据服务名称分发到具体的服务，各个服务再根 据自己的业务具体处理 Action、Query、Trigger 的请求；各个服务实现自己的事件上报 接口，一旦有事件上报，实时通知 IFTTT。

3.1 协议分析

        1、对 第三方平台IFTTT 提供接口：HTTPS 协议；

        2、内部调用 IoT-App Server 接口： gRPC 协议；

        3、服务之间异步调用：通过 kafka，在 Trigger 场景下是 iot-subsubscription 给 IFTTT-Iot         Adapter 发送异步消息。

4. 系统架构描述

4.1 架构设计

总体完成功能：

1. IFTTT-Iot Adapter 与周边服务构成总体系统结构图如上，IFTTT 发起 Action、Query 和 Trigger 请求，IFTTT-Iot Adapter 接收之后内部对请求做协议转换，通过 gRPC 请求调用 IoT-App Server 接口查询、控制设备（不包括在基础云维持长连接的旧固件的 Tapo Plug）；

2. 设备端通过短连接的方式上报设备影子数据更改事件到二级订阅，二级订阅将事件写入 iot.ifttt.event.v2 主题队列，IFTTT-Iot Adapter 的消费者程序从中消费， 调用 IFTTT 实时通知接口。

4.2 模块结构

IFTTT-Iot Adapter 的实现如下结构图，主要分成 Controller、Service、Dao、gRPC api 和 Consumer 几个模块：

4.3 接口流程图

        IFTTT 调用 Actions 和 Queries 请求的流程, 你的服务需要实现的是图中的IFTTT Adaper，转换协议后转发请求到你后台的服务：

        IFTTT 调用 Trigger 请求的流程，你的服务需要存储ifttt上创建的trigger信息和事件数据，相应Trigger请求的时候获取相应的数据：

5. 任务（或进程/线程）设计

        IFTTT-IOT Adapter 需要新增 kafka 消费者任务，持续消费来自主题 iot.ifttt.event.v2 的 消息。这一部分是设备事件异步上报的一个流程，因为ifttt需要接受来自设备的作为触发场景的事件，adapter服务需要有一个上报事件的进程，这里是一个kafka消费者进程。

5.1 原理

        IFTTT Adapter 需要接收 Tapo Plug 和 Tapo Bulb 的设备事件，二级订阅通过将设备上报 的事件消息写入特定主题队列来转发消息。

5.2 流程设计

        IFTTT Adapter 内部 kafka 消费者线程处理流程，这个是事件上报的一个流程，你的平台上产生消息推送到IFTTT Adapter模块，你的模块根据储存的trigger信息过滤掉多余的消息，调用ifttt的实时通知接口告知ifttt接下来需要执行哪些trigger的poll请求:

 说明：

1、步骤 6 实时通知的时候可以传 trigger_identity，可以区分一个 tilinkid 被多个 ifttt 用户账号使用的场景；如果调用超时，重试一次；

2、步骤 5 获取事件消息之后，根据 reportedChangedPropList 字段判断更改的属性， 然后根据 trigger 类型和用户 id 获取 trigger 信息，再包装 trigger event 数据，写入 数据库 写入的时候判断 trigger event 的数量是否超过 trigger event 的最大 数量，是的话删除存储时间最久的一条数据，再写入；

3、步骤 4 根据用户 trigger 配置过滤的时候先过滤对应 trigger 的，再按用户（包括 Owner 用户和分享用户）过滤。 

6.  数据库设计

        选用 mysql 数据库作为存储。

6.1 选型

        选用 mysql 原因：此应用主要用于存储用户数据、trigger 数据和事件消息，mysql 是 轻量级数据库，性能高，能够满足要求。

6.2 数据库表结构设计

        Adaper服务实现的效果大同小异，主要存储trigger、event和用户信息，以下数据库表的设计可以作为参考。

        trigger_events（存储设备事件数据）

triggers（存储 trigger 信息包括和用户之间的关联关系）

ingredients（存储 trig event 的配料信息） 

users（存储用户信息）

7 接口概要设计 

此部分应该列出模块最终实现的接口列表，包括接口路径和定义

另外需要一个事件消费任务