IOT平台架构
简介
物联网（ IoT ，Internet of things ）即“万物相连的互联网”，是互联网基础上的延伸和扩展的网络，将各种信息传感设备与互联网结合起来而形成的一个巨大网络，实现在任何时间、任何地点，人、机、物的互联互通
架构设计
此处参考阿里云物联网平台设计
IOT HUB设计
网络模型
)
通用 RPC 框架原理
需要做哪些工作
Protocol
- 协议应该包括哪些必要字段与主要业务负载字段：协议里设计的每个字段都应该被使用到，避免无效字段；
- 需要考虑通信功能特性的支持：比如CRC校验，安全校验，数据压缩机制等；
- 需要考虑协议的可扩展性：充分评估现有业务的需求，设计一个通用，扩展性高的协议，避免经常对协议进行修改；
- 需要考虑协议的升级机制：毕竟是私有协议，没有长期的验证，字段新增或者修改，是有可能发生的，因此升级机制是必须考虑的；
Encoder与 Decoder
- 协议相关的编解码方式：私有协议需要有核心的encode与decode过程，并且针对业务负载能支持不同的序列化与反序列化机制。这部分，不同的私有协议，由于字段的差异，核心encode和decode过程是不一样的，因此需要分开考虑
Heartbeat
- 协议相关的心跳触发与处理：不同的协议对心跳的需求，处理逻辑也可能是不同的。因此心跳的触发逻辑，心跳的处理逻辑，也都需要单独考虑。
Command与 Command Handler
- 可扩展的命令与命令处理器管理
- 负载命令：一般传输的业务的具体数据，比如带着请求参数，响应结果的命令；
- 控制命令：一些功能管理命令，心跳命令等，它们通常完成一些复杂的分布式跨节点的协调功能，以此来保证负载命令通信过程的稳定，是必不可少的一部分。
- 协议的通信过程，会有各种命令定义，逻辑上，我们把传输业务具体负载的请求对象，叫做负载命令（Payload Command），另一种叫做控制命令（Control Command），比如一些功能管理命令，或者心跳命令。
- 定义了通信命令，我们还需要定义命令处理器，用来编写各个命令对应的业务处理逻辑。同时，我们需要保存命令与命令处理器的映射关系，以便在处理阶段，走到正确的处理器。
-
此部分的痛点：
1. 每个厂商的协议、数据编码解码方式、设备控制指令、数据接收处理器都不一样，每对接一个厂家都要做一遍
2. 这个模型和rpc模型很像，分为服务端（被动接收设备数据），客户端（往设备发送数据）
技术选型过程：
1. 设备接收数据处理实现可拓展（类似rpc的server command hanlder）
2. 设备控制指令可实现可拓展（类似rpc的client command）
3. 对象序列化可拓展
4. 应用层通讯协议可拓展（http/modbus/自定义）
5. 表示层和会话层可自由定义(加密方式、校验方式等）
6. 传输层需支持tcp和udp
最后选择了SOFA-RPC ，由于高拓展性
如果想对 SOFARPC 的各个内置扩展点进行功能扩展，可直接实现已有扩展，配置扩展模式文件即可。
目前还在开发中，后续补上代码，最后放上github地址，喜欢去点个赞
https://github.com/99246255/IOT