本文将基于氦氪长期的实践经验，来讲述 IoTOS 搭配 tio 解决存量设备接入的具体思路和方法。
概述
目前包括 BAT、华为等主流物联网云服务都内置自己的标准数据格式，均面临存量物联网设备接入的难题。氦氪 IoTOS 作为一款对标各大品牌的物联网数据中台私有化产品，也面临同样的问题。
tio（点击访问） 国内著名的网络开发框架。
本文将基于氦氪长期的实践经验，来讲述 IoTOS 搭配 tio 解决存量设备接入的具体思路和方法。
注：通过边缘网关接入的情况不属于本次讨论范畴，若关注这方面的内容，可翻看之前的博客文章《网关采集 ModBus 温度传感器数据传输到 IoTOS 实例》。本次讨论的部分只限于如下图红框处：
为什么存量设备接入是难题？
协议栈复杂
首先，“协议”这个词个人认为现在已经被使用地过于泛滥，好像所有协议都处于同一个层面，而实际上并非如此。参考下图，大家能看出来物联网协议栈其实非常复杂。
从下到上依次为：
- 通信方式：Wi-Fi、GPRS、5G等
- 网络协议：IPV4、IPV6等
- 传输协议：TCP、UDP
- 应用协议：MQTT、CoAP、LwM2M、HTTP等
- 数据格式：ALink（阿里云）、HLink（华为）、KLink（氦氪）、私有 JSON、私有 HEX、私有 XML、……
相对来说，通信方式和网络协议好处理，因为物联网平台本来就对网络透明。当然有个别特殊情况，比如 Wi-Fi涉及到设备发现这个环节，略微复杂，但设备发现成功之后设备跟平台的交互处理几乎是一致的。
真正比较难处理的是传输协议和数据格式这两层。
传输协议
相信大家都清楚，在 MQTT 成为当下主流物联网协议之前，大部分传统设备生产厂家几乎都使用 TCP 或 UDP 来直接包装业务数据，比如宏电协议等。熟悉网络编程的朋友们知道，TCP 存在半包、粘包问题，因此必须使用特殊字符（如 \n、\r\n 等）或者特殊格式（如 head+len+data+checksum）等方式来告诉 Server 端如何拆包（也可以叫做解码），把 data 正确取出。
包括 Netty 在内的若干网络框架，都很难实现免编译、动态插件化地解码，而且即使实现也可能影响处理性能、提高学习使用门槛（关于这点，可以参考 JMeter。即使 JMeter 的插件化能力已经非常强了，但依然不能实现热加载）。
数据格式
这里的数据格式就是上面提到的 data。对不同产品的 data，我们的理想当然也是免编译对接。好在目前有不少开发语言都能充当胶合的角色，比如 Python、JavaScript、Groovy、Lua。
难点在于：
- 平台开发语言和动态语言的集成，双方是否可共享上下文 Context？
- 执行效率。动态语言难免在性能上有所损失，因此也要看实际项目场景。
- 编写门槛。好在像 Python、JavaScript 开发群体众多，门槛较低。
- ……
存量设备的信息缺失
信息缺失并非是设备厂家主观行为故意导致，而是存量设备在设计时可能还没有类似所谓的通用物联网平台。
比如，像 BAT 的 IoT 平台、华为 OC、氦氪 IoTOS，要连接每一个设备，都得预先在平台上先创建产品，平台会自动给产品分配productKey，否则设备接上来，平台就不知道它到底是什么品类（对应物模型）、什么型号（对应协议栈里的各层信息），后续任何交互也无从谈起。而且更要注意到，这个问题跟上一个问题实际上是耦合的。
但存量设备里很少预存类似 productKey，怎么办？
设备认证
目前主流平台均使用三元组来实现设备认证。实话讲，确实比仅仅单纯靠 IMEI 或者 ID 匹配安全太多。但存量设备有三元组吗？😭😭😭
解决办法
先确定标准接入流程
如下图是氦氪 IoTOS 的标准接入流程：
基于标准流程，不仅可以解决新增设备的接入，也能部分解决存量设备的接入，即创建产品时选择自定义模式，开启数据解析插件功能。
IoTOS 对 MQTT、CoAP、LwM2M、NB（运营商转发）接入的产品均支持数据解析插件功能，对不统一的数据格式提供了一种统一的解决办法。
基于 tio 定制连接通道
tio 是国内著名的网络开发框架，特点是极轻量化、性能强悍、简单易用、门槛低，开发者可以很快上手。正因为如此，tio 很适合作为 IoTOS 定制通道的开发组件。
tio 定制通道和 IoTOS 的协作关系如下图：
tio 负责对私有协议的编解码，其他功能（如：设备认证、规则引擎、数据存储和聚合分析等）由 IoTOS 实现，相得益彰！
注：考虑到 IoTOS 是私有化产品，因此暂时直接开放消息队列接口。基于超轻量的考虑，IoTOS 使用了 Redis 5.x 的新特性 Stream 作为消息队列。
TCP 通道定制
目前，IoTOS 基于 tio 已经完成部分特殊 TCP 通道 ，包括：
- KLink-TCP
- \n 作为分割符的私有协议
- \r\n 作为分隔符的私有协议
- 其他在计划中 ……
UDP 通道定制
- KLink-UDP
- 其他在计划中 ……
工作量评估
若熟悉 tio 的代码结构，我们评估开发一个定制通道的时间基本按小时计算。是不是很香？😆
总结
坦率地说，IoTOS 并不能解决所有存量物联网设备的接入，这也并非是我们在开发 IoTOS 之初的设想。
解决大部分环节的标准化，把定制化的部分尽量压缩在一个很小的范围内，由轻量级的组件或者合作伙伴来配合完成，可能才是正确的选择！