Skip to content

Architecture

Jump to bottom
MarkChai edited this page Jul 16, 2026 · 5 revisions

架构设计

yes-core 是一个极度纯粹的微内核。它的核心设计哲学是：“内核只管调度与生命周期，其余一切皆插件”。 在 yes-core 的视角中，没有任何模块拥有特殊的层级地位。无论是提供配置的 plugin-config、提供抽象的 adapter-manager，还是具体的 adapter-onebot，甚至是你的业务插件，它们在内核眼里都只是实现了 Plugin 接口的普通结构体。它们通过内核提供的事件总线和依赖注入机制协同工作。

架构流向图

graph TD
    subgraph 微内核
        G[yes-core]
    end

    subgraph 平级插件生态
        D[adapter-manager]
        E[adapter-onebot]
        F[plugin-config]
        A[业务插件 A: 群管]
        B[业务插件 B: AI 对话]
        C[业务插件 C: 自定义渲染器]
    end

    H(QQ / NapCat / Telegram...)

    %% 内核管理所有插件的生命周期
    G ---|管理生命周期 & 事件总线| D
    G ---|管理生命周期 & 事件总线| E
    G ---|管理生命周期 & 事件总线| F
    G ---|管理生命周期 & 事件总线| A
    G ---|管理生命周期 & 事件总线| B
    G ---|管理生命周期 & 事件总线| C

    %% 插件间的依赖与协作 (通过 DependsOn 和 Registry)
    A -.->|依赖注入| D
    B -.->|依赖注入| D
    C -.->|重载渲染器| D
    
    D -->|事件订阅 / 调用接口| E
    E -->|WebSocket/HTTP| H

    F -.->|提供配置读取| E
Loading

模块协作关系

虽然在内核眼中大家都是平级的，但为了实现一个完整的机器人系统，这些插件通过 DependsOn 声明依赖，自然形成了一套默契的协作关系：

  1. 微内核 (yes-core) 极度纯粹，不包含任何业务逻辑。提供 Init, Start, Stop 生命周期管理，Publish/Subscribe 事件总线，以及基于 DependsOn 的依赖注入机制。它负责按拓扑顺序启动所有插件。
  2. 生态支撑插件 (adapter-manager, plugin-config)
    • plugin-config：作为一个基础工具插件，为其他插件提供统一的配置反序列化能力。
    • adapter-manager：作为一个中间件插件，监听底层适配器抛出的原始事件，将其打磨成强类型的 MessageEvent，并注入便捷闭包。它定义了“什么是消息”、“什么是适配器”。
  3. 协议适配插件 (adapter-onebot 等) 实现了 adapter-manager 规定的 Adapter 接口。负责连接底层协议端（如 NapCat），将原始报文解析为内存对象抛给总线，并将内核的主动调用编码为协议端能识别的格式。
  4. 业务插件 (my-plugin 等) 专注于实现机器人功能。只依赖 adapter-manager 抽象层，通过事件总线订阅标准化消息。代码极度清爽，实现跨平台兼容。 这种设计带来的最大好处是可替换性：如果有一天不需要 plugin-config 了，写一个新的 plugin-viper 替换它即可；如果不想用 adapter-manager 的抽象，甚至可以直接写一个业务插件去监听 adapter-onebot 的最底层事件。一切权利归于插件开发者。

Clone this wiki locally