跳到主要内容

主要讨论一下各部分组件之间通讯和数据交换的方式

议题1：各部分组件之间通讯和数据交换的方式

目的：​

系统各个组件之间和高效、稳定的通讯

所有数据发送到Genapsed并由Genapsed路由

要考虑稳定性、速度、安全性（权限管理）、数据多样性

要能够传输文本（控制指令、事件等）、图像（监控抓图、识别结果等）、视频（录像片段等）、二进制文件（用户上传的文件、更新包、压缩包等）

eg：下图红色部分都需要互相通讯

方案选择​

1. 方案​

  • MQTT
  • Python 内部传参
  • HTTP / RESTful API (配合 WebSocket/SSE)
    • 描述：最通用的 Web 标准。插件作为 Server 或 Client。
    • 适用：获取配置、上传大文件、视频流拉取、WebSocket 做实时推送。
  • gRPC (Google Remote Procedure Call)
    • 描述：基于 HTTP/2 和 Protobuf 的高性能 RPC 框架。
    • 适用：内部微服务之间的高频、结构化数据调用（如 LLM 频繁调用工具）。
  • ZeroMQ (ØMQ)
    • 描述：高性能消息队列库，无需中间 Broker，直接点对点或发布订阅。
    • 适用：极高吞吐量的本地进程间通讯，比 MQTT 更快，资源占用更低。
  • 共享内存 / 本地文件系统 (Shared Memory / Local FS)
    • 描述：不通过网络，直接读写内存块或磁盘文件。
    • 适用：超大文件（视频片段） 的交换。

2. 方案优缺点对比​

方案优点缺点适用场景
MQTT1. 标准 IoT 协议，解耦（发布/订阅）
2. 极轻量，带宽占用低
3. 支持 QoS（消息质量保证）		1.不适合传大文件（阻塞 Broker）
2. 实时性略低于 ZeroMQ		控制指令、事件通知、小文本、传感器数据。
HTTP / REST1. 通用，调试方便
2. 支持大文件（流式）
3. 防火墙友好		1. 主要是“请求-响应”模式，实时推送需配合 WebSocket
2. 头部开销比 MQTT 大		配置管理、文件上传下载、视频流回放、LLM 交互。
Python 传参1. 速度最快（内存访问，无额外开销）1.耦合度极高
2. 一个插件崩溃可能导致主程序崩溃
3. 难以实现热插拔/独立重启		仅限核心库内部调用，严禁用于插件间通讯。
gRPC1. 性能极高（二进制 Protobuf）
2. 强类型约束，接口定义清晰		1. 开发门槛稍高（需写 .proto 文件）
2. 不如 JSON/HTTP 直观		高频、低延迟的内部服务调用（如 LVM 推理结果回传）。
本地文件/共享内存1. 便于传输大文件
2. 无额外开销		1. 仅限单机
2. 需要管理文件生命周期（清理旧文件）		视频录像片段、大图片、模型文件。

3. 最终推荐方案：混合架构 (Hybrid Architecture)​

鉴于你的需求是“所有数据发送到 Genapsed 并路由”，且数据包含视频，绝对不能让视频二进制流直接穿过 Genapsed 的消息总线，否则 Genapsed 会瞬间成为性能瓶颈甚至内存溢出。

推荐采用“控制面与数据面分离”的策略：

A. 控制面 (Control Plane) -> 使用 MQTT 或 ZeroMQ​

  • 用途：传输指令、事件描述(JSON)、小图片(Base64)、状态心跳。
  • 流程：
    • 插件 A 检测到事件，发送 JSON 消息到 MQTT Topic (everpast/genapsed/event/high)。
    • Genapsed 订阅该 Topic，收到消息。
    • Genapsed 根据规则，将消息路由（Publish）到插件 B 的 Topic。
  • 优点：解耦、快速、Genapsed 负载低。

B. 数据面 (Data Plane) -> 使用“引用传递” + 本地存储/HTTP​

  • 用途：传输视频片段、大图片、二进制包。

  • 核心机制：Pass-by-Reference (传引用，不传值)

    • 写入：插件 A 将视频片段写入本地磁盘（如 /data/recordings/20260303_1200.mp4）或 内置 HTTP Server。
    • 发送：插件 A 通过 MQTT 发送一条轻量级消息给 Genapsed：
    {
      "event": "motion_detected",
      "video_path": "/data/recordings/20260303_1200.mp4", 
      // 或者 "video_url": "http://localhost:8080/stream/123"
      "timestamp": 1741000000
    }
    • 路由：chronosd 收到这条文本消息，路由给插件 B。
    • 读取：插件 B 收到消息，解析出 video_path，自己去读取文件或请求 HTTP 下载。

总结方案架构图示：​

为什么选这个？

  1. 稳定性：Genapsed 只处理文本 JSON，永远不会因为传输 500MB 的视频而卡死。
  2. 速度：MQTT 处理文本极快；本地文件读取速度远快于网络传输。
  3. 多样性：文本走 MQTT，文件走磁盘/HTTP，各取所长。
  4. 符合需求：确实实现了“所有数据（的元数据/索引）都经过 Genapsed路由”。

议题二：术语解释中组件命名

参考：

https://chat.qwen.ai/c/ec510ba9-ed02-4dbc-a9ff-4ee174d93c54

结论​

最终由 @Archeroy 提出，共同统一使用Genapsed /dʒɛˈnæps-d/

Genesis (创世/首发启动) + Synapse (突触：神经元之间传递通讯信号的底层结构)

https://applink.feishu.cn/client/message/link/open?token=AmlGRyrUk4vNaamOooFATNo%3D