「产品矩阵平台」可扩展的服务框架

第六章 可扩展的服务框架

可扩展服务框架的核心目标，是让平台不断加入新业务、新能力、新插件时，系统复杂度不要线性爆炸。

一个好的框架应做到：

1. 新模块可以按标准目录接入；
2. 模块依赖显式声明；
3. 启动、关闭、迁移、路由、事件都有生命周期；
4. 扩展点清晰，不能靠修改核心代码接需求；
5. 未来拆成微服务时，模块边界仍然有效。

6.1 模块化架构设计

推荐目录形态：

app/
  modules/
    user/
      module.go
      service.go
      repository.go
      routes.go
      events.go
    commerce/
      module.go
      service.go
      repository.go
      routes.go

每个模块实现统一接口：

type Module interface {
    Name() string
    Register(container Container) error
    Boot(ctx context.Context) error
    Routes(router Router)
    Shutdown(ctx context.Context) error
}

这里 Register 只注册依赖，Boot 执行启动逻辑，不能混在一起。否则启动顺序一复杂，就很难定位循环依赖。

6.2 组件注册与生命周期管理

平台应有一个明确的启动序列：

graph TD
    A[Load Config] --> B[Init Container]
    B --> C[Register Modules]
    C --> D[Resolve Dependencies]
    D --> E[Boot Modules]
    E --> F[Register Routes and Workers]
    F --> G[Ready]

生命周期钩子：

6.3 插件系统

插件和模块的区别在于：模块是平台核心业务的一部分，插件是可选能力。

插件清单建议记录版本、兼容范围和权限：

插件不能默认拥有全局权限。一个短信插件不应该能读取订单明细，一个主题插件也不应该能访问支付密钥。

6.4 内核与模块通信机制

模块间通信有三种方式：

同步调用适合“必须立即知道结果”的场景，例如下单前查询会员价格。事件适合“发生后通知别人”的场景，例如订单支付成功后发通知、写分析。

6.5 扩展点设计模式

扩展点要具体，不能泛化成“传一个函数进来”。常见模式：

例如订单创建可以暴露 Pipeline：

ValidateCart -> CalculatePrice -> LockInventory -> CreateOrder -> EmitEvent

营销插件只应插入 CalculatePrice，不应该修改库存步骤。

6.6 模块模板与 CLI 代码生成

当平台模块超过五个，手写重复结构会让一致性变差。CLI 可以生成模块骨架：

plume make:module content
plume make:service content ArticleService
plume make:event order.created

生成内容包括：

CLI 的价值不是少敲几行代码，而是让团队遵循同一套边界。

6.7 热加载与热插拔

Go 原生动态插件在生产环境使用要谨慎，因为 ABI、构建环境和平台兼容性都可能带来风险。更实用的热插拔方式通常是：

热插拔要有回滚路径。启用插件失败时，平台应自动恢复旧版本，而不是让主进程启动失败。

6.8 可扩展性验收标准

可扩展不是“什么都能改”，而是“该扩展的地方容易扩展，不该碰的地方有边界”。