2025-09-10 10:47:49 +08:00

1.9 KiB
Raw Blame History

整体架构

整个系统可以理解为对微服务的部署管理和数据收集每个微服务在全局拥有一个全局唯一的uuid作为service_id

通讯模式的修改

1. 微服务(tcp|websocket + json) => efka(ssl + protobuf) => iot (efka与iot之间之间是使用的json格式服务器端解析压力过大)
2. ssl的加解密通过nginx反向代理实现, 利用nginx提交数据的加解密效率(已完成)

已完成

1. 微服务的部署/启动/停止功能, 要求微服务要以前台运行的方式启动
2. 微服务和efka之间基于tcp的通讯逻辑规范已经形成
3. 云服务离线的时候efka对微服务产生的文件的缓存逻辑已经实现
4. 微服务部署的日志相关的逻辑管理后台可以通过taskId获取部署的所有相关日志

待完成

1. 微服务和efka之间增加基于websocket的通讯 + json的格式 => 基于文档可以不用为微服务提供sdk
2. 场景编排
3. 多租户(后台也要配合)

实现修改

1. 将配置项目和采集项目合并成一个配置项目并通过json格式管理
2. 数据传输中需要对通过aes加密修改为在链接层面全部数据加密传输(efka端基于ssl云端基于nginx反向代理)
3. 取消对数据上传中数据格式的限制,整个数据链路中对数据的约束为二进制格式;这样可以兼容所有的数据类型(efkaiot其实不关心数据负载只负责转发和路由) 
4. todo 微服务启动的时候通过 register方法建立到efka的关联返回的时候直接将 config_json 返回;避免服务启动时需要手动获取

新增加

1. pub/sub机制微服务可以通过topic监听自己关注的消息(将一对一和一对多的消息机制统一)
2. 增加了endpoint支持将数据路由到http|kafka|mqtt; 增加路由机制数据上报的时候通过route_key路由到对应的endpoint
3. 新增远程调用