技术随笔

Telegraf 是一个开源的指标收集代理，用于从各种数据源收集、处理和传输指标数据。它是由InfluxData（现在称为InfluxDB）开发的一款工具，旨在帮助用户轻松地收集系统、应用程序和服务的性能指标数据，并将其发送到不同的目标数据存储、监控系统或时间序列数据库中，以便后续的分析和可视化。只有当安装第二个或以后更多的节点时，才需要输入已有集群中任何一个可用节点的 FQDN，支持该新节点加入集群。Grafana 是一个开源的数据可视化和监控平台，用于创建、查看和分享各种数据源的实时图表和仪表盘。

一个协议包可能有多个DeviceMessageCodec（根据协议包解析的网络协议来的，比如需要解析TCP、MQTT两种那就添加两个DeviceMessageCodec），每个DeviceMessageCodec都实现了上行消息解析、下行消息解析两个功能。针对这一场景，以加载jar包的形式来实现，指定标准的接口，只要在jar包中实现对应的接口，做标准的协议解析方法就可以了（这里要注意，要支持设备上下行消息解析）。定义协议解析包对象应具有的功能。

定义网关接口，规定网关需要实现的方法。/*** 设备网关/*** @return 网关ID/*** @return 网关端口/*** @return 支持的传输协议/*** 启动网关* @return 启动结果/*** 关闭网关* @return 关闭结果/*** 网关状态* @return 网关状态。

这里使用@ConditionalOnProperty来修饰该实现类，这样目的是让redis stream作为消息总线的默认实现，如果后续添加别的实现，可以在配置文件中便利的配置。这里生产者处理逻辑比较简单，当设备消息或者其他业务的消息产生的时候，调用生产者实现的发布方法将消息推送至消息总线。EventBus实体，主要负责三个功能，发布、订阅的入口，以及管理维护MessageAdapter。首先，像这种平台的功能，一定要做好抽象设计，预留好功能扩展的接口。订阅者组内多播处理抽象类。

传统的 BIO，是线程将数据写入 Connection 之后，当前线程进入 Block 状态，直到响应返回，之后接着做响应返回后的动作。NIO 则是线程将数据写入 Connection 之后，将响应返回后需要做的事情以及参数缓存到一个地方之后，直接返回。在有响应返回后，NIO 的 Selector 的 Read 事件会是 Ready 状态，扫描 Selector 事件的线程，会告诉你的线程池数据好了，然后线程池中的某个线程，拿出刚刚缓存的要做的事情还有参数，继续处理。

针对消息体我们应该支持自由的解析方式，这里我打算采用自定义解析jar的方式，针对每一个新的设备，开发出不同的解析jar然后上传到服务器上，消息到来之后我们调用对应的jar来解析消息。采用spring loud全家桶（使用若依微服务版，若依就挺好的这一块就不重复造轮子了），各个服务之间的调用摒弃掉feign调用的方式，针对物联网项目的特点，准备采用发布订阅模式，将各个业务转化为一个个不同的流或者说是时间，流的起点以及终点分别的设备消息的到来与入库，其他上层业务订阅这些不同的流来达成扩展。