GitHub user Alanxtl created a discussion: [gsoc1] Dubbo-Go 轻量化运行时探索与插件化机制实现
# GSoC 题目：**Dubbo-Go 轻量化运行时探索与插件化机制实现** --- ## 项目背景与问题描述 Dubbo-Go 已发展为一个功能丰富的 RPC 框架，拥有覆盖服务注册、服务发现、协议实现、治理能力等在内的庞大扩展生态系统。当前框架在设计上追求“开箱即用”，大多数扩展组件在编译期或运行期**默认启用**，无需显式声明即可参与框架初始化流程。 然而，这种设计在实际使用中逐渐暴露出若干问题： * **所有插件默认启用，缺乏显式的启停控制机制**。 用户无法明确关闭不需要的扩展组件，即使这些组件在当前使用场景下并不必要。 * **运行时依赖复杂、启动路径冗长**。 即便是仅使用基础 RPC 能力的场景，也会隐式引入注册中心、治理、配置等多个子系统的初始化逻辑。 * **核心运行时与可选能力耦合度高**。 许多扩展实现长期存在于 Dubbo-Go 主仓库中，导致核心代码与扩展逻辑边界模糊，增加维护与演进成本。 在此前的重构过程中，一些使用频率较低的扩展（例如 Consul 注册中心）被从核心仓库中移除。但由于缺乏统一的插件化框架、SPI 边界定义以及标准化的加载与启停机制，这些扩展难以以“可选组件”的形式重新引入和独立维护。 因此，当前 Dubbo-Go 面临的核心问题已不仅是“是否插件化”，而是： > **如何在保证向后兼容的前提下，引入可控、可裁剪的插件机制，使 Dubbo-Go 支持轻量化运行时模式。** 相关issue: https://github.com/apache/dubbo-go/issues/2326 https://github.com/apache/dubbo-go/issues/1981 --- ## 项目目标 本项目旨在探索 **Dubbo-Go 的轻量化运行时模式**，并通过插件化机制实现对扩展组件的**显式加载与控制**，而不改变现有用户的配置方式与使用习惯。 具体目标包括： 1. **设计并实现可控的插件化机制**，支持插件的显式启用与禁用，而非默认全部加载。 2. **分析并重构 Dubbo-Go 的启动流程**，明确哪些能力属于最小运行时，哪些应作为可选插件加载。 3. **定义并稳定 SPI（Service Provider Interface）层**，为核心与扩展之间建立清晰、可维护的边界。 4. **建立独立的扩展仓库 `dubbo-go-extensions`**，承载非核心运行时能力。 5. **适配多个具有代表性的扩展（不少于 5 个）**，验证插件化与轻量运行时设计的可行性。 6. **在保证兼容性的前提下**，为未来的运行时裁剪、按需加载与部署优化奠定基础。 --- ## 关键技术挑战 ### 1. 插件加载顺序、启停控制与初始化机制 当前 Dubbo-Go 中，大多数扩展通过空白导入和 `init()` 函数自动注册，且默认参与启动流程。本项目将系统性分析并解决以下问题： * 插件是如何被发现和注册的（例如通过 `init()` + 全局注册表）。 * 不同类型插件（注册中心、解析器、协议、治理组件等）的初始化顺序。 * 插件加载与配置解析之间的关系。 * **如何引入插件的显式启用 / 禁用机制**，避免所有插件默认生效。 * 如何避免 Go 包初始化顺序带来的非确定性行为。 目标是建立一个**可预测、可裁剪、可文档化的插件加载与控制模型**。 --- ### 2. SPI 层设计与边界稳定性 SPI 层是实现插件化与轻量运行时的关键基础，其设计目标包括： * 集中、明确地定义扩展点（接口、扩展名、工厂函数等）。 * 减少插件对 Dubbo-Go 内部运行时结构的依赖。 * 支持插件在不修改核心代码的情况下独立演进。 * 为插件启停、按需加载以及未来运行时裁剪提供稳定接口基础。 SPI 是以**独立模块**形式存在，还是作为 Dubbo-Go 仓库内**边界清晰的子包**存在，将作为设计探索的一部分，而非预设结论。 --- ### 3. 扩展仓库与可选能力拆分 项目将建立新的 `dubbo-go-extensions` 仓库，用于承载非核心能力的插件实现： * 不同扩展以独立 Go Module 形式存在（如 `registry/consul`、`registry/polaris`）。 * 扩展通过 SPI 与核心运行时集成。 * 用户可通过显式引入与配置选择性启用插件，而非默认加载全部能力。 --- ### 4. 扩展适配与迁移验证 为验证插件化机制与轻量化运行时设计的可行性与通用性，本项目将选择并适配多种具有代表性的 Dubbo-Go 扩展，包括： * 若干当前仍在使用的扩展（如不同类型的注册中心、解析器或协议实现），用于验证插件的显式启停能力、加载顺序控制以及与轻量运行时的兼容性。 * 至少一个历史上曾被移除的扩展（如 Consul 注册中心），用于验证在核心演进背景下，旧扩展通过 SPI 与插件化机制重新引入的可行性。 针对历史移除扩展，将完成以下工作： * 修复与当前 Dubbo-Go 核心之间的兼容性问题。 * 基于新的 SPI 接口进行重构与注册。 * 在插件可控启用的运行模式下进行功能验证。 该过程将沉淀可复用的扩展适配与迁移经验，并形成指导文档，为后续更多扩展的插件化提供参考。 --- ### 5. 轻量化运行时模式探索 基于对启动流程和插件依赖的分析，项目将探索： * Dubbo-Go 最小可运行核心的能力边界（如仅支持基础 RPC）。 * 治理、注册、配置等能力作为插件按需加载的可行性。 * 为容器化、边缘计算或资源受限场景提供更轻量的运行时形态。 --- ## 预期成果 1. 一套支持插件显式启停的 Dubbo-Go 插件化机制。 2. 清晰、稳定的 SPI 层定义。 3. 一个 `dubbo-go-extensions` 扩展仓库。 4. 多个成功适配的新插件化扩展（不少于 5 个），其中至少包含一个历史移除扩展（如 Consul）。 5. Dubbo-Go 启动流程与运行时依赖的完整文档。 6. 示例项目，展示轻量运行时与插件按需启用方式。 --- ## 难度与工作量 * **难度**：中等偏高 * **项目规模**：Large（350 小时） --- # 预期 12-Week Milestones > **Community Bonding（编码前）** > （通常 2–3 周，不计入 12 周 coding period） ## Community Bonding（编码前准备） **目标**：统一认知，避免学生一上来就改代码 * 熟悉 Dubbo-Go 代码结构与启动流程 * 阅读现有 extension / SPI 机制（如 `common/extension`） * 梳理当前插件的注册、初始化、启用方式 * 与导师确认： * 轻量运行时的目标范围 * 插件启停的设计约束（向后兼容） **交付物**： * 一份《Dubbo-Go 启动流程与插件机制初步分析》文档 --- ## Coding Period（12 周） --- ## Week 1：Dubbo-Go 启动流程与插件现状分析 **目标**：搞清楚“现在到底是怎么跑起来的” * 梳理 Dubbo-Go 启动主路径（入口 → runtime → extension） * 识别： * 哪些插件是“默认必加载” * 哪些插件是“配置触发” * 分析插件注册方式（`init()`、全局 registry） **交付物**： * 启动流程时序图（或文字版） * 插件加载与注册机制分析文档 --- ## Week 2：最小运行时能力边界定义 **目标**：明确什么是“轻量运行时” * 定义 **Minimal Runtime** 能力集合（如基础 RPC） * 明确哪些能力应视为“可选插件”： * 注册中心 * 配置中心 * 治理能力 * 标注当前代码中的强耦合点 **交付物**： * 《Dubbo-Go 轻量运行时能力划分说明》 * 插件分类清单（core vs optional） --- ## Week 3：插件启停模型与加载顺序设计 **目标**：先设计，再动代码 * 设计插件生命周期模型： * 发现 * 注册 * 启用 / 禁用 * 初始化 * 明确插件加载顺序与依赖关系 * 讨论并确定： * 配置驱动 vs 显式声明 * 默认行为与兼容策略 **交付物**： * 插件启停与加载顺序设计文档 * 初步 API / 接口草案 --- ## Week 4：SPI 层边界设计与稳定化 **目标**：把“核心”和“插件”真正隔开 * 梳理现有 SPI 使用情况 * 设计稳定的 SPI 接口集合 * 明确： * 哪些接口对插件开放 * 哪些内部结构应隐藏 **交付物**： * SPI 接口定义文档 * SPI 包结构设计说明 --- ## Week 5：插件管理与启停机制实现（核心） **目标**：真正让插件“可以关掉” * 实现插件管理基础设施： * 插件注册表 * 启用 / 禁用状态 * 支持插件在初始化阶段被跳过 * 保证不破坏现有默认行为 **交付物**： * 插件管理核心代码 * 示例：禁用某类插件仍可正常启动 --- ## Week 6：加载顺序与确定性初始化保障 **目标**：解决 Go `init()` 的不确定性问题 * 控制插件初始化顺序 * 消除对包初始化顺序的隐式依赖 * 确保配置加载与插件启用顺序一致 **交付物**： * 确定性插件初始化机制 * 对应技术文档与示例 --- ## Midterm Evaluation（中期评估） **应达到状态**： * 插件可以被显式启用 / 禁用 * 轻量运行时可以在无部分插件情况下启动 * SPI 边界清晰、代码可维护 --- ## Week 7：建立 `dubbo-go-extensions` 仓库 **目标**：验证插件真正可以“离开核心仓库” * 创建 `dubbo-go-extensions` * 拆出第一个扩展到独立仓库 * 通过 SPI 完成注册 **交付物**： * 新 extensions 仓库 * 至少一个独立插件模块 --- ## Week 8：适配多个现有扩展（不少于 3 个） **目标**：验证机制通用性 * 选择多个现有扩展进行适配 * 验证： * 启停控制 * 加载顺序 * 轻量运行时兼容性 **交付物**： * 至少 3 个插件完成适配 * 测试与验证说明 --- ## Week 9：恢复历史移除扩展（如 Consul） **目标**：解决“历史包袱”问题 * 恢复一个历史移除扩展 * 修复 API / 配置兼容问题 * 通过新插件机制启用 **交付物**： * 成功运行的历史扩展插件 * 迁移与适配说明文档 --- ## Week 10：完善插件文档与示例工程 **目标**：让用户和开发者“能用、会用” * 编写插件开发指南 * 编写插件启停说明 * 提供最小运行时示例项目 **交付物**： * 插件开发与使用文档 * 示例项目代码 --- ## Week 11：测试、稳定性与向后兼容性验证 **目标**：避免“能跑但不敢合” * 回归测试现有使用场景 * 验证默认行为未被破坏 * 修复发现的问题 **交付物**： * 测试报告 * 兼容性说明 --- ## Week 12：最终整理与成果交付 **目标**：让社区愿意合并 * 整理所有文档 * 提交 PR / RFC * 汇总设计决策与未来工作方向 **交付物**： * 最终技术总结文档 * 可合并的代码与 PR * 后续演进建议 GitHub link: https://github.com/apache/dubbo-go/discussions/3205 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
