29 lines
2.0 KiB
Markdown
29 lines
2.0 KiB
Markdown
## 整体架构
|
||
整个系统可以理解为对微服务的部署管理和数据收集，每个微服务在全局拥有一个全局唯一的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. 取消对数据上传中数据格式的限制，整个数据链路中对数据的约束为二进制格式；这样可以兼容所有的数据类型(efka，iot其实不关心数据负载；只负责转发和路由)
|
||
4. todo 微服务启动的时候通过 register方法建立到efka的关联；返回的时候直接将 config_json 返回；避免服务启动时需要手动获取
|
||
## 新增加
|
||
1. pub/sub机制，微服务可以通过topic监听自己关注的消息(将一对一和一对多的消息机制统一)
|
||
2. 增加了endpoint，支持将数据路由到http|kafka|mqtt; 增加路由机制，数据上报的时候通过route_key路由到对应的endpoint
|
||
3. 新增远程调用
|
||
|
||
## 新增微服务日志的收集平台, efka基于udp协议 |