mirror of
https://github.com/Rain-kl/OpenFlare.git
synced 2026-09-30 06:16:37 +08:00
chore: doc
This commit is contained in:
ryan
@@ -1,332 +0,0 @@
|
||||
# Wavelet Cordis 微内核与全插件化改造实施计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 将 Wavelet 架构重构为基于 Cordis 理念的微内核与全插件化架构，支持一切能力插件化、自包含数据迁移、多运行切面（API/Worker/Schedule/All）与下游极简二开扩展。
|
||||
|
||||
**Architecture:**
|
||||
- **Core (`core/`)**: 纯净微内核，提供 Context 服务总线、泛型 IoC 容器（`Provide/Inject/Using`）、强类型 EventBus、生命周期状态机与 6 大扩展点协议，零外部业务依赖。
|
||||
- **Drivers (`plugins/drivers/`)**: Gin HTTP Server、Asynq Worker、Asynq Scheduler 封装为标准运行时驱动插件。
|
||||
- **Infra Plugins (`plugins/infra/`)**: 数据库（GORM/DBResolver）、三层缓存（RAM/Redis/PubSub）、日志（Zap/Otel）、对象存储插件化。
|
||||
- **Domain Plugins (`plugins/domain/`)**: Auth、User、MessageGateway、RiskControl、Admin 模块拆分为扁平自包含插件，自带独立 Goose 迁移。
|
||||
|
||||
**Tech Stack:** Go 1.25+, Gin, GORM, Asynq, Redis, Zap, OpenTelemetry, Goose, Viper, Cobra.
|
||||
|
||||
## Global Constraints
|
||||
- 保持 `core/` 绝对纯净，禁止 import Gin、GORM、Asynq 或具体业务包。
|
||||
- 插件之间严禁相互跨包 import 具体实现，跨插件交互一律通过 `core/contracts` 接口或 `ctx.Events()` 事件总线。
|
||||
- 严格遵循 Go 单元测试规范，测试临时目录统一使用 `t.TempDir()`，测试覆盖率严格达标。
|
||||
- 完成每个 Task 后必须确保代码能通过 `go build ./...` 与 `go test ./...` 检验并及时提交 Git。
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 微内核基础契约与泛型 Context 服务总线 (`core/`)
|
||||
|
||||
**Files:**
|
||||
- Create: `core/types.go`
|
||||
- Create: `core/manifest.go`
|
||||
- Create: `core/container.go`
|
||||
- Create: `core/context.go`
|
||||
- Test: `core/context_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Produces: `core.Plugin`, `core.Manifest`, `core.Context`, `core.Provide[T]`, `core.Inject[T]`, `core.Using[T]`
|
||||
|
||||
- [ ] **Step 1: 编写 Context 与 IoC 容器的失败测试**
|
||||
|
||||
```go
|
||||
// core/context_test.go
|
||||
package core_test
|
||||
|
||||
import (
|
||||
"context"
|
||||
"testing"
|
||||
"github.com/stretchr/testify/assert"
|
||||
"github.com/stretchr/testify/require"
|
||||
"github.com/Rain-kl/Wavelet/core"
|
||||
)
|
||||
|
||||
type SampleService interface {
|
||||
Greet(name string) string
|
||||
}
|
||||
|
||||
type sampleServiceImpl struct{}
|
||||
|
||||
func (s *sampleServiceImpl) Greet(name string) string {
|
||||
return "Hello, " + name
|
||||
}
|
||||
|
||||
func TestContextProvideAndInject(t *testing.T) {
|
||||
ctx := core.NewContext(context.Background())
|
||||
core.Provide[SampleService](ctx, &sampleServiceImpl{})
|
||||
|
||||
svc, err := core.Inject[SampleService](ctx)
|
||||
require.NoError(t, err)
|
||||
assert.Equal(t, "Hello, Wavelet", svc.Greet("Wavelet"))
|
||||
}
|
||||
|
||||
func TestContextUsing(t *testing.T) {
|
||||
ctx := core.NewContext(context.Background())
|
||||
var called bool
|
||||
|
||||
err := core.Using(ctx, func(s SampleService) {
|
||||
called = true
|
||||
assert.Equal(t, "Hello, Cordis", s.Greet("Cordis"))
|
||||
})
|
||||
assert.Error(t, err, "service not ready yet")
|
||||
assert.False(t, called)
|
||||
|
||||
core.Provide[SampleService](ctx, &sampleServiceImpl{})
|
||||
err = core.Using(ctx, func(s SampleService) {
|
||||
called = true
|
||||
assert.Equal(t, "Hello, Cordis", s.Greet("Cordis"))
|
||||
})
|
||||
assert.NoError(t, err)
|
||||
assert.True(t, called)
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 运行测试验证失败**
|
||||
|
||||
Run: `go test -v ./core`
|
||||
Expected: FAIL with compilation error (package not found).
|
||||
|
||||
- [ ] **Step 3: 实现 Core 核心接口与泛型容器**
|
||||
|
||||
编写 `core/types.go`、`core/manifest.go`、`core/container.go`、`core/context.go`，提供基于反射与类型推导的安全泛型服务存取、Scope 隔离与 Disposer 回调链。
|
||||
|
||||
- [ ] **Step 4: 运行测试验证通过**
|
||||
|
||||
Run: `go test -v ./core`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 5: 提交 Task 1 代码**
|
||||
|
||||
```bash
|
||||
git add core/
|
||||
git commit -m "feat(core): implement context service hub and generic ioc container"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 领域扩展点规范与强类型 EventBus (`core/extpoints/`, `core/events.go`)
|
||||
|
||||
**Files:**
|
||||
- Create: `core/events.go`
|
||||
- Create: `core/extpoints/router.go`
|
||||
- Create: `core/extpoints/migration.go`
|
||||
- Create: `core/extpoints/task.go`
|
||||
- Create: `core/extpoints/schedule.go`
|
||||
- Create: `core/extpoints/setting.go`
|
||||
- Test: `core/events_test.go`
|
||||
- Test: `core/extpoints/extpoints_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Context`
|
||||
- Produces: `core.EventBus`, `core.RouterExtension`, `core.MigrationExtension`, `core.TaskExtension`, `core.ScheduleExtension`, `core.SettingExtension`
|
||||
|
||||
- [ ] **Step 1: 编写 EventBus 与扩展点测试用例**
|
||||
|
||||
```go
|
||||
// core/events_test.go
|
||||
package core_test
|
||||
|
||||
import (
|
||||
"context"
|
||||
"testing"
|
||||
"github.com/stretchr/testify/assert"
|
||||
"github.com/Rain-kl/Wavelet/core"
|
||||
)
|
||||
|
||||
type UserRegisteredEvent struct {
|
||||
UserID string
|
||||
}
|
||||
|
||||
func TestEventBusPublishSubscribe(t *testing.T) {
|
||||
bus := core.NewEventBus()
|
||||
var receivedID string
|
||||
|
||||
bus.On("user:registered", func(ctx context.Context, e UserRegisteredEvent) error {
|
||||
receivedID = e.UserID
|
||||
return nil
|
||||
})
|
||||
|
||||
err := bus.Emit(context.Background(), "user:registered", UserRegisteredEvent{UserID: "u_999"})
|
||||
assert.NoError(t, err)
|
||||
assert.Equal(t, "u_999", receivedID)
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 2: 运行测试验证失败**
|
||||
|
||||
Run: `go test -v ./core/...`
|
||||
Expected: FAIL
|
||||
|
||||
- [ ] **Step 3: 实现 EventBus 与 6 大扩展点适配器**
|
||||
|
||||
编写 `core/events.go` 及 `core/extpoints/` 下各个领域的挂载收集器（Router 注册收集、Goose embed.FS 聚合器、Task/Schedule 声明表、Setting 模式注册表）。
|
||||
|
||||
- [ ] **Step 4: 运行测试验证通过**
|
||||
|
||||
Run: `go test -v ./core/...`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 5: 提交 Task 2 代码**
|
||||
|
||||
```bash
|
||||
git add core/
|
||||
git commit -m "feat(core): add typed eventbus and domain extension points"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 运行时驱动插件下沉 (`plugins/drivers/`)
|
||||
|
||||
**Files:**
|
||||
- Create: `plugins/drivers/driver_http/plugin.go`
|
||||
- Create: `plugins/drivers/driver_asynq_worker/plugin.go`
|
||||
- Create: `plugins/drivers/driver_asynq_cron/plugin.go`
|
||||
- Test: `plugins/drivers/drivers_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Plugin`, `core.Driver`, `core.Context`
|
||||
- Produces: `DriverTypeHTTP`, `DriverTypeWorker`, `DriverTypeScheduler`
|
||||
|
||||
- [ ] **Step 1: 编写 Driver 生命周期测试用例**
|
||||
|
||||
测试驱动在接收到 `Start(ctx)` 和 `Stop(ctx)` 信号时的平滑启动与退出状态。
|
||||
|
||||
- [ ] **Step 2: 编写 Driver 实现**
|
||||
|
||||
将 Gin HTTP Server、Asynq Worker Server、Asynq Scheduler 封装为标准 `core.Driver`，并在 `Apply(ctx)` 时挂载到 Context 驱动树。
|
||||
|
||||
- [ ] **Step 3: 运行驱动单元测试**
|
||||
|
||||
Run: `go test -v ./plugins/drivers/...`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 4: 提交 Task 3 代码**
|
||||
|
||||
```bash
|
||||
git add plugins/drivers/
|
||||
git commit -m "feat(plugins): implement runtime drivers for http, asynq worker, and cron"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 基础设施服务插件化 (`plugins/infra/`)
|
||||
|
||||
**Files:**
|
||||
- Create: `plugins/infra/database/plugin.go` (提供 GORM DBService)
|
||||
- Create: `plugins/infra/cache/plugin.go` (提供 RAM/Redis 三层缓存)
|
||||
- Create: `plugins/infra/logger/plugin.go` (提供 Zap/Otel 结构化日志)
|
||||
- Create: `plugins/infra/storage/plugin.go` (提供统一对象存储)
|
||||
- Test: `plugins/infra/infra_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Produces: `contracts.DBService`, `contracts.CacheService`, `contracts.LoggerService`, `contracts.StorageService`
|
||||
|
||||
- [ ] **Step 1: 编写基础设施插件注入与提取测试**
|
||||
- [ ] **Step 2: 实现 4 大基础设施插件并封装现有 pkg 与 infra 底座**
|
||||
- [ ] **Step 3: 运行基础设施测试验证**
|
||||
|
||||
Run: `go test -v ./plugins/infra/...`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 4: 提交 Task 4 代码**
|
||||
|
||||
```bash
|
||||
git add plugins/infra/
|
||||
git commit -m "feat(plugins): package database, cache, logger, and storage as infra plugins"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 5: 业务领域插件化重构 (`plugins/domain/`)
|
||||
|
||||
**Files:**
|
||||
- Create: `plugins/domain/auth/` (认证、Session、Passkey、专属 migrations)
|
||||
- Create: `plugins/domain/user/` (用户资料、角色权限、专属 migrations)
|
||||
- Create: `plugins/domain/message_gateway/` (Bot网关、推送通道、Worker消费)
|
||||
- Create: `plugins/domain/risk_control/` (IP限流、风控中间件)
|
||||
- Create: `plugins/domain/admin/` (控制台、系统设置)
|
||||
- Test: `plugins/domain/domain_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `contracts.DBService`, `contracts.CacheService`, `contracts.LoggerService`
|
||||
- Produces: `contracts.AuthService`, `contracts.UserService`
|
||||
|
||||
- [ ] **Step 1: 编写 Auth 与 User 插件业务装配与独立迁移测试**
|
||||
- [ ] **Step 2: 将各业务模块迁移为扁平自包含插件，嵌入专属 Goose SQL 迁移**
|
||||
- [ ] **Step 3: 运行业务插件集成测试**
|
||||
|
||||
Run: `go test -v ./plugins/domain/...`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 4: 提交 Task 5 代码**
|
||||
|
||||
```bash
|
||||
git add plugins/domain/
|
||||
git commit -m "feat(plugins): migrate auth, user, message_gateway, risk_control, admin to domain plugins"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 统一装配入口与运行时切面分发器 (`core/app.go`, `cmd/`)
|
||||
|
||||
**Files:**
|
||||
- Create: `core/app.go`
|
||||
- Modify: `internal/cmd/root.go`
|
||||
- Modify: `internal/cmd/api.go`
|
||||
- Modify: `internal/cmd/worker.go`
|
||||
- Modify: `internal/cmd/scheduler.go`
|
||||
- Modify: `internal/cmd/all.go`
|
||||
- Test: `core/app_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.App`, `core.Plugin`, `core.Driver`
|
||||
- Produces: 统一 CLI 启动与优雅停机流程
|
||||
|
||||
- [ ] **Step 1: 编写 App 生命周期与 Profile 调度测试**
|
||||
- [ ] **Step 2: 实现 `core.App` 编排引擎，无缝接入 `wavelet api / worker / schedule / all`**
|
||||
- [ ] **Step 3: 运行启动与角色切面集成验证**
|
||||
|
||||
Run: `go test -v ./core -run TestAppProfileDispatch`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 4: 提交 Task 6 代码**
|
||||
|
||||
```bash
|
||||
git add core/ internal/cmd/
|
||||
git commit -m "feat(core): implement app profile lifecycle dispatcher and wire cli commands"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 7: 下游脚手架、自定义示例插件与端到端验证
|
||||
|
||||
**Files:**
|
||||
- Create: `downstream/custom_plugins/order/plugin.go`
|
||||
- Create: `downstream/main.go`
|
||||
- Create: `downstream/config.yaml`
|
||||
- Test: `downstream/e2e_test.go`
|
||||
|
||||
- [ ] **Step 1: 编写下游自定义业务插件并在下游 `main.go` 组装启动**
|
||||
- [ ] **Step 2: 执行全量 E2E 测试，验证数据迁移、HTTP 路由访问、Worker 任务消费与平滑停机**
|
||||
- [ ] **Step 3: 运行全局质量门禁检查**
|
||||
|
||||
Run:
|
||||
```bash
|
||||
make test
|
||||
make code-check
|
||||
make format
|
||||
```
|
||||
Expected: 全部 PASS，0 lint 报错。
|
||||
|
||||
- [ ] **Step 4: 提交 Task 7 代码**
|
||||
|
||||
```bash
|
||||
git add downstream/
|
||||
git commit -m "feat(downstream): add starter scaffold, example custom plugin, and e2e tests"
|
||||
```
|
||||
|
||||
@@ -1,221 +0,0 @@
|
||||
# Cordis Architecture Alignment & Refactoring Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Implement Cordis spatiotemporal composability (scoped revertible effects and reactive fiber lifecycle state machine) in `backend/core`, and eliminate cross-plugin direct imports in domain repositories.
|
||||
|
||||
**Architecture:**
|
||||
1. Build scoped extension proxies on `core.Context` that automatically attach unregister callbacks to `ctx.OnDispose` in LIFO order upon registration.
|
||||
2. Introduce `core/fiber.go` implementing the Fiber state machine (`PENDING -> LOADING -> ACTIVE -> UNLOADING -> DISPOSED`) with a reactive reconciler in `App`/`Container` ensuring dependency confluence.
|
||||
3. Clean up defensive boundaries in `backend/plugins/domain/user` by removing direct `database.DB(ctx)` imports in favor of `contracts.DBService`.
|
||||
|
||||
**Tech Stack:** Go 1.24+, GORM, Gin, Asynq, Cordis micro-kernel paradigm.
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- Strictly preserve `backend/pkg/util/` purity (no Gin/GORM imports).
|
||||
- Zero physically hardcoded temp directories in tests (use `t.TempDir()`).
|
||||
- All Go error returns and logging must adhere to project standards.
|
||||
- Follow Conventional Commits (`feat(core): ...`, `refactor(user): ...`).
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Scoped Revertible Effects for Core Extpoints
|
||||
|
||||
**Files:**
|
||||
- Create: `backend/core/scoped_extpoints.go`
|
||||
- Modify: `backend/core/context.go`
|
||||
- Modify: `backend/core/extpoints/task.go`
|
||||
- Modify: `backend/core/extpoints/schedule.go`
|
||||
- Modify: `backend/core/extpoints/setting.go`
|
||||
- Test: `backend/core/context_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Context`, `extpoints.RouterExtension`, `extpoints.TaskExtension`, `extpoints.ScheduleExtension`, `extpoints.SettingExtension`, `core.EventBus`
|
||||
- Produces: Scoped extension methods on `Context` that automatically register LIFO disposers when routes, tasks, schedules, settings, and events are registered.
|
||||
|
||||
- [ ] **Step 1: Write the failing test for scoped extpoints automatic teardown**
|
||||
|
||||
In `backend/core/context_test.go`, add test cases verifying that registering routes, tasks, schedules, settings, and event listeners on a child context automatically registers unregister callbacks, and calling `childCtx.Dispose()` completely rolls them back:
|
||||
|
||||
```go
|
||||
func TestContext_ScopedExtpoints_RevertibleEffects(t *testing.T) {
|
||||
root := NewContext(context.Background())
|
||||
child := root.Fork()
|
||||
|
||||
// Register route, task, schedule, setting, event on child
|
||||
rd := child.Router().GET("/test-route", func() {})
|
||||
assert.Equal(t, 1, len(root.Router().Routes()))
|
||||
|
||||
child.Events().On("test:event", func() {})
|
||||
assert.Equal(t, 1, root.Events().Listeners("test:event"))
|
||||
|
||||
// Dispose child
|
||||
err := child.Dispose()
|
||||
assert.NoError(t, err)
|
||||
|
||||
// All child effects should be revoked
|
||||
assert.Equal(t, 0, len(root.Router().Routes()))
|
||||
assert.Equal(t, 0, root.Events().Listeners("test:event"))
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `go test -v ./backend/core -run TestContext_ScopedExtpoints_RevertibleEffects`
|
||||
Expected: FAIL (because current `Router().GET()` does not bind unregistration to `child.OnDispose`).
|
||||
|
||||
- [ ] **Step 3: Implement Scoped Extpoints and Context bindings**
|
||||
|
||||
1. In `backend/core/extpoints/task.go`, ensure `Unregister(taskType string) bool` exists.
|
||||
2. In `backend/core/extpoints/schedule.go`, ensure `Unregister(name string) bool` exists.
|
||||
3. In `backend/core/extpoints/setting.go`, ensure `Unregister(key string) bool` exists.
|
||||
4. In `backend/core/scoped_extpoints.go` (or `context.go`), create scoped wrappers for `RouterExtension`, `TaskExtension`, `ScheduleExtension`, `SettingExtension` and `EventBus` that tie registrations to `ctx.OnDispose`.
|
||||
|
||||
- [ ] **Step 4: Run tests to verify they pass**
|
||||
|
||||
Run: `go test -v ./backend/core -run TestContext_ScopedExtpoints_RevertibleEffects`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/core/
|
||||
git commit -m "feat(core): implement scoped revertible effects for context extpoints"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 2: Plugin Fiber State Machine and Reactive Coeffects (Confluence)
|
||||
|
||||
**Files:**
|
||||
- Create: `backend/core/fiber.go`
|
||||
- Create: `backend/core/fiber_test.go`
|
||||
- Modify: `backend/core/app.go`
|
||||
- Modify: `backend/core/types.go`
|
||||
- Modify: `backend/core/container.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Plugin`, `core.Context`, `core.Container`
|
||||
- Produces: `core.DependentPlugin`, `core.Fiber`, `core.FiberState`, `App.Reconcile()`
|
||||
|
||||
- [ ] **Step 1: Write the failing test for Fiber state machine and out-of-order registration confluence**
|
||||
|
||||
In `backend/core/fiber_test.go`:
|
||||
|
||||
```go
|
||||
func TestFiber_ConfluenceAndReactiveActivation(t *testing.T) {
|
||||
app := NewApp()
|
||||
|
||||
// Plugin B depends on contracts.DBService, but is registered BEFORE DatabasePlugin (Plugin A)
|
||||
pluginB := &mockDependentPlugin{
|
||||
name: "plugin-b",
|
||||
deps: []reflect.Type{reflect.TypeFor[contracts.DBService]()},
|
||||
}
|
||||
pluginA := &mockDBPlugin{name: "database"}
|
||||
|
||||
app.Use(pluginB, pluginA)
|
||||
|
||||
err := app.Start(context.Background())
|
||||
assert.NoError(t, err)
|
||||
|
||||
// Verify both plugins reached FiberActive state and B executed Apply successfully after A provided DBService
|
||||
assert.True(t, pluginB.applied)
|
||||
assert.True(t, pluginA.applied)
|
||||
|
||||
_ = app.Stop()
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `go test -v ./backend/core -run TestFiber_ConfluenceAndReactiveActivation`
|
||||
Expected: FAIL (because current `app.ApplyPlugins()` applies in static slice order without dependency reconciliation).
|
||||
|
||||
- [ ] **Step 3: Implement Fiber State Machine and Reconciler**
|
||||
|
||||
1. In `backend/core/types.go`, declare:
|
||||
```go
|
||||
type DependentPlugin interface {
|
||||
Plugin
|
||||
Inject() []reflect.Type
|
||||
}
|
||||
```
|
||||
2. In `backend/core/fiber.go`, implement `Fiber` with states (`FiberPending`, `FiberLoading`, `FiberActive`, `FiberUnloading`, `FiberDisposed`), child scoped context, and state transition methods.
|
||||
3. In `backend/core/app.go`, integrate Fibers into `App` and implement iterative dependency reconciliation during `ApplyPlugins` and on dynamic `Provide`.
|
||||
|
||||
- [ ] **Step 4: Run tests to verify they pass**
|
||||
|
||||
Run: `go test -v ./backend/core`
|
||||
Expected: ALL PASS
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/core/
|
||||
git commit -m "feat(core): implement plugin fiber state machine and reactive dependency reconciler"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 3: Domain Plugin Isolation & Boundary Enforcement
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/plugins/domain/user/repository.go`
|
||||
- Modify: `backend/plugins/domain/user/service.go`
|
||||
- Modify: `backend/plugins/domain/user/handlers.go`
|
||||
- Modify: `backend/plugins/domain/user/plugin.go`
|
||||
- Test: `backend/plugins/domain/user/plugin_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `contracts.DBService` via `core.Inject` / `ctx.DB()`
|
||||
- Produces: Decoupled User repository without direct `Wavelet/plugins/infra/database` imports.
|
||||
|
||||
- [ ] **Step 1: Write/update test verifying User repository works with injected DBService**
|
||||
|
||||
In `backend/plugins/domain/user/plugin_test.go`, test user CRUD operations resolving `contracts.DBService` through Context.
|
||||
|
||||
- [ ] **Step 2: Run test to verify current state**
|
||||
|
||||
Run: `go test -v ./backend/plugins/domain/user/...`
|
||||
|
||||
- [ ] **Step 3: Refactor user repository to eliminate direct `plugins/infra/database` imports**
|
||||
|
||||
In `backend/plugins/domain/user/repository.go`:
|
||||
- Remove `import "Wavelet/plugins/infra/database"`.
|
||||
- Obtain `*gorm.DB` via `ctx` (e.g. from context using `contracts.DBService` or context value).
|
||||
|
||||
- [ ] **Step 4: Run tests to verify they pass**
|
||||
|
||||
Run: `go test -v ./backend/plugins/domain/user/...`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add backend/plugins/domain/user/
|
||||
git commit -m "refactor(user): decouple repository from direct database infra import"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Task 4: Full Suite Verification & Quality Gate
|
||||
|
||||
**Files:**
|
||||
- Entire repository
|
||||
|
||||
- [ ] **Step 1: Run all backend tests**
|
||||
|
||||
Run: `cd backend && go test -v ./...`
|
||||
Expected: ALL PASS
|
||||
|
||||
- [ ] **Step 2: Run code-check and format**
|
||||
|
||||
Run: `make code-check && make format`
|
||||
Expected: 0 lint errors, clean formatting.
|
||||
|
||||
- [ ] **Step 3: Commit any formatting or lint fixes**
|
||||
|
||||
```bash
|
||||
git commit -am "chore: format and verify code quality"
|
||||
```
|
||||
@@ -1,120 +0,0 @@
|
||||
# Cordis 架构重构实施计划 (Cordis Architecture Refactor Implementation Plan)
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 依据 Cordis 时空可组合性元框架，彻底消除 Wavelet 后端的包级静态单例、`init()` 隐式副作用建连以及跨插件私有实现依赖，实现微内核纯洁化与契约驱动解耦。
|
||||
|
||||
**Architecture:**
|
||||
1. 移除 `backend/core/context.go` 中的特权服务快捷方法（`DB()` / `Cache()`）。
|
||||
2. 将 `infra/database` 与 `infra/cache` 的连接初始化移至 `Plugin.Apply(ctx)`，并在 `ctx.OnDispose` 中注册 LIFO 逆操作（Close）。
|
||||
3. 重构全部 8 个 Domain 业务插件（`auth`、`user`、`admin`、`cap`、`message_gateway`、`risk_control`、`system`、`upload`），彻底斩断对 `infra/database`、`infra/cache` 及其他插件内部包的直接 import，统一面向 `contracts.DBService` / `contracts.CacheService`。
|
||||
4. 清除 `admin` 等插件的包级全局变量。
|
||||
|
||||
**Tech Stack:** Go 1.24+, GORM, Redis (go-redis/v9), Cordis micro-kernel, Goose migration.
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- 严禁任何业务插件跨包 import `Wavelet/plugins/infra/database` 或 `Wavelet/plugins/infra/cache`。
|
||||
- 严禁跨插件 import 私有实现包（如 `admin` import `risk_control/logstore`）。
|
||||
- 保持 `backend/pkg/util/` 绝对纯净，禁止导入 Web/数据库框架。
|
||||
- 重构后必须确保 `go test ./...`、`make code-check` 与 `make format` 全部 0 错误通过。
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 微内核纯洁化 (`backend/core/`)
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/core/context.go:240-260`
|
||||
- Test: `backend/core/context_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Context`, `core.Inject`
|
||||
- Produces: 纯净无特权方法的 `core.Context`
|
||||
|
||||
- [ ] **Step 1: 编写/更新 Context 纯洁性测试**
|
||||
- [ ] **Step 2: 移除 `Context.DB()` 与 `Context.Cache()` 方法**
|
||||
- [ ] **Step 3: 运行 `go test ./backend/core/...` 验证通过**
|
||||
|
||||
---
|
||||
|
||||
### Task 2: 基础设施插件生命周期可逆化 (`backend/plugins/infra/`)
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/plugins/infra/database/postgres.go`
|
||||
- Modify: `backend/plugins/infra/database/plugin.go`
|
||||
- Modify: `backend/plugins/infra/cache/redis.go`
|
||||
- Modify: `backend/plugins/infra/cache/plugin.go`
|
||||
- Test: `backend/plugins/infra/infra_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `core.Plugin`, `contracts.DBService`, `contracts.CacheService`
|
||||
- Produces: `contracts.DBService` 与 `contracts.CacheService`（带 `ctx.OnDispose` 逆操作）
|
||||
|
||||
- [ ] **Step 1: 移除 `infra/database` 中的 `func init()` 及全局 `var db`，在 `Plugin.Apply` 中建连并注册 `ctx.OnDispose(sqlDB.Close)`**
|
||||
- [ ] **Step 2: 移除 `infra/cache` 中的 `func init()` 及全局 `var Redis`，在 `Plugin.Apply` 中建连并注册 `ctx.OnDispose(client.Close)`**
|
||||
- [ ] **Step 3: 运行 `go test ./backend/plugins/infra/...` 验证通过**
|
||||
|
||||
---
|
||||
|
||||
### Task 3: 核心 Domain 插件防线重塑（Auth & User 插件）
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/plugins/domain/auth/*`
|
||||
- Modify: `backend/plugins/domain/user/*`
|
||||
- Test: `backend/plugins/domain/auth/plugin_test.go`
|
||||
- Test: `backend/plugins/domain/user/plugin_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `contracts.DBService`, `contracts.CacheService`
|
||||
- Produces: `contracts.AuthService`, `contracts.UserService`
|
||||
|
||||
- [ ] **Step 1: 移除 `auth` 插件中对 `Wavelet/plugins/infra/database` 和 `cache` 的 import，改用插件持有的 `contracts.DBService` 与 `contracts.CacheService`**
|
||||
- [ ] **Step 2: 移除 `user` 插件中对 `Wavelet/plugins/infra/database` 和 `cache` 的 import，改用 `contracts.DBService` 与 `contracts.CacheService`**
|
||||
- [ ] **Step 3: 运行 `go test ./backend/plugins/domain/auth/... ./backend/plugins/domain/user/...` 验证通过**
|
||||
|
||||
---
|
||||
|
||||
### Task 4: 业务 Domain 插件防线重塑（Cap, MessageGateway, RiskControl, System, Upload）
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/plugins/domain/cap/*`
|
||||
- Modify: `backend/plugins/domain/message_gateway/*`
|
||||
- Modify: `backend/plugins/domain/risk_control/*`
|
||||
- Modify: `backend/plugins/domain/system/*`
|
||||
- Modify: `backend/plugins/domain/upload/*`
|
||||
- Test: `backend/plugins/domain/domain_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `contracts.DBService`, `contracts.CacheService`
|
||||
|
||||
- [ ] **Step 1: 改造 `cap`、`message_gateway`、`risk_control`、`system`、`upload` 插件，移除所有 `infra/database` 和 `infra/cache` 的直接 import**
|
||||
- [ ] **Step 2: 统一各插件内部 Repository / Service 的 DB / Cache 获取途径**
|
||||
- [ ] **Step 3: 运行各插件单测验证通过**
|
||||
|
||||
---
|
||||
|
||||
### Task 5: Admin 插件解耦与包级全局状态清除
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/plugins/domain/admin/*`
|
||||
- Test: `backend/plugins/domain/admin/plugin_test.go`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `contracts.DBService`, `contracts.CacheService`, `contracts.UserService`, `contracts.AuthService`, `ctx.Tasks()`
|
||||
|
||||
- [ ] **Step 1: 移除 `admin` 插件中对 `risk_control/logstore`、`driver_asynq_worker`、`infra/storage/diskcache` 等私有包的直接 import**
|
||||
- [ ] **Step 2: 清除 `admin/plugin.go` 中的 `globalUserSvc`、`globalAuthSvc`、`globalCoreCtx` 等包级变量**
|
||||
- [ ] **Step 3: 运行 `go test ./backend/plugins/domain/admin/...` 验证通过**
|
||||
|
||||
---
|
||||
|
||||
### Task 6: 组装层对齐与全量质量门禁验证
|
||||
|
||||
**Files:**
|
||||
- Modify: `backend/cmd/app.go`
|
||||
- Modify: `backend/cmd/*`
|
||||
|
||||
- [ ] **Step 1: 检查并适配 `cmd/app.go` 及启动指令，确保 Goose 迁移与驱动正确接入新版 `DBService`**
|
||||
- [ ] **Step 2: 运行全局跨包 import 检查：`grep -r "Wavelet/plugins/infra/database" backend/plugins/domain/` 必须为空**
|
||||
- [ ] **Step 3: 运行全量单元测试与基准测试：`go test ./...`**
|
||||
- [ ] **Step 4: 运行质量门禁：`make code-check && make format`**
|
||||
@@ -1,326 +0,0 @@
|
||||
# 迁移脚本拆分执行计划
|
||||
|
||||
## 背景现状
|
||||
|
||||
| 维度 | 实际状态 |
|
||||
|---|---|
|
||||
| 总 SQL 文件 | 26 个全局 (`pkg/migrator/goose/`) + 5 个插件 (`plugins/domain/*/migrations/`) + 1 个 ClickHouse |
|
||||
| 实际运行的迁移 | **仅 26 个全局文件**（通过 `gooseEngine` → `pkg/migrator.Migrate()`） |
|
||||
| 插件注册的迁移 | 3 个 (`auth`, `user`, `message_gateway`) — 注册了但被 `gooseEngine` 丢弃 |
|
||||
| 有迁移文件但未注册的插件 | `admin`（2 个文件，0 个调用） |
|
||||
| 无迁移文件的插件 | `upload`, `risk_control`, `cap`, `driver_asynq_worker`, `driver_asynq_cron` |
|
||||
| ClickHouse 迁移 | 1 个文件 (`w_user_access_logs`)，通过 `pkg/migrator.MigrateClickHouse()` 单独运行 |
|
||||
|
||||
## 表所有者映射
|
||||
|
||||
以下列表基于"单一所有者原则"，每个表精确映射到一个插件：
|
||||
|
||||
| 表名 | 所有者插件 | 涉及全局迁移 |
|
||||
|---|---|---|
|
||||
| `w_users` | `domain/user` | 20260609 (create), 20260614 (seed system user) |
|
||||
| `w_access_tokens` | `domain/auth` | 20260609 (create), 20260610 (is_admin), 20260611 (rm last_used_at) |
|
||||
| `w_auth_sources` | `domain/auth` | 20260609 (create) |
|
||||
| `w_external_accounts` | `domain/auth` | 20260609 (create) |
|
||||
| `w_system_configs` | `domain/admin` | 20260609→20260611 (rename+seeds×7), 20260613 (TEXT), 20260816 (log_db) |
|
||||
| `w_templates` | `domain/admin` | 20260609→20260611 (rename) |
|
||||
| `w_schedules` | `driver_asynq_cron` | 20260610 (create), 20260611 (identity), 20260614 (update cleanup) |
|
||||
| `w_task_executions` | `driver_asynq_worker` | 20260609→20260611 (rename) |
|
||||
| `w_uploads` | `domain/upload` | 20260609→20260611 (rename), 20260613 (access_mode), 20260617 (indexes), 20260618 (drop storage_driver) |
|
||||
| `w_upload_stats` | `domain/upload` | 20260617 (create+backfill) |
|
||||
| `w_push_events` | `domain/message_gateway` | 20260614 (create), 20260615 (task_type), 20260616 (cleanup) |
|
||||
| `w_push_histories` | `domain/message_gateway` | 20260614 (create) |
|
||||
| `w_push_channels` | `domain/message_gateway` | 20260614 (create) |
|
||||
| `w_message_channels` | `domain/message_gateway` | 20260816 (create) |
|
||||
| `w_message_bindings` | `domain/message_gateway` | 20260816 (create) |
|
||||
| `w_message_pairing_codes` | `domain/message_gateway` | 20260816 (create) |
|
||||
| `w_user_access_logs` | `domain/risk_control` | 20260816 (create) + ClickHouse |
|
||||
|
||||
## 执行步骤（共 8 步）
|
||||
|
||||
---
|
||||
|
||||
### 步骤 1：创建 Bootstrap 迁移（保留在 `pkg/migrator`）
|
||||
|
||||
**文件**：`pkg/migrator/goose/postgres/00001_bootstrap.sql`
|
||||
|
||||
将以下全局迁移合并为一个 bootstrap 文件：
|
||||
- **`202606090001_initial_schema.sql`** → 创建 `users`, `auth_sources`, `external_accounts`, `access_tokens`, `system_configs`, `uploads`, `task_executions`, `templates`（全部无前缀旧名）
|
||||
- **`202606110003_rename_tables_to_w_prefix.sql`** → 全部重命名为 `w_` 前缀
|
||||
|
||||
**合并后，bootstrap 文件直接创建带 `w_` 前缀的表**，不再需要 rename 步骤：
|
||||
|
||||
```sql
|
||||
-- +goose Up
|
||||
CREATE TABLE IF NOT EXISTS w_users (
|
||||
id BIGINT PRIMARY KEY,
|
||||
username VARCHAR(64) UNIQUE,
|
||||
...
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS w_access_tokens (...);
|
||||
CREATE TABLE IF NOT EXISTS w_auth_sources (...);
|
||||
CREATE TABLE IF NOT EXISTS w_external_accounts (...);
|
||||
CREATE TABLE IF NOT EXISTS w_system_configs (
|
||||
key VARCHAR(64) PRIMARY KEY,
|
||||
value TEXT NOT NULL,
|
||||
...
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS w_uploads (...);
|
||||
CREATE TABLE IF NOT EXISTS w_task_executions (...);
|
||||
CREATE TABLE IF NOT EXISTS w_templates (...);
|
||||
CREATE TABLE IF NOT EXISTS w_schedules (...);
|
||||
```
|
||||
|
||||
> **为什么保留在 `pkg/migrator`**：这些是平台的"初始化基座"——无论哪些插件启用，这些表都存在。将 bootstrap 放到 `pkg/migrator` 之下回避了循环依赖问题（例如 `w_system_configs` 属于 admin，但 bootstrap 时 admin 插件尚未 apply）。
|
||||
|
||||
---
|
||||
|
||||
### 步骤 2：修复 `gooseEngine` 支持插件迁移
|
||||
|
||||
**文件**：`cmd/app.go`
|
||||
|
||||
```go
|
||||
type gooseEngine struct{}
|
||||
|
||||
func (e *gooseEngine) Migrate(_ context.Context, entries []core.MigrationEntry) error {
|
||||
// 1. 先跑 bootstrap（初始化基座）
|
||||
_ = migrator.Migrate()
|
||||
|
||||
// 2. 再跑每个插件注册的迁移
|
||||
for _, entry := range entries {
|
||||
gormDB := database.DB(context.Background())
|
||||
if gormDB == nil {
|
||||
continue
|
||||
}
|
||||
sqlDB, err := gormDB.DB()
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
goose.SetBaseFS(entry.FS)
|
||||
if err := goose.SetDialect(gooseDialect()); err != nil {
|
||||
return err
|
||||
}
|
||||
dir := entry.Dir
|
||||
if dir == "" {
|
||||
dir = "migrations"
|
||||
}
|
||||
if err := goose.Up(sqlDB, dir); err != nil {
|
||||
return fmt.Errorf("migrate %s: %w", entry.PluginID, err)
|
||||
}
|
||||
}
|
||||
|
||||
// 3. ClickHouse 迁移
|
||||
_ = migrator.MigrateClickHouse()
|
||||
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
依赖项：`gooseDialect()` 从 `pkg/migrator` 导出。
|
||||
|
||||
---
|
||||
|
||||
### 步骤 3：按表所有者拆分迁移到各插件
|
||||
|
||||
| 全局源文件 | 目标插件 | 迁移文件名 |
|
||||
|---|---|---|
|
||||
| `202606100002` (access_tokens is_admin) | `domain/auth` | `migrations/00002_add_access_token_is_admin.sql` |
|
||||
| `202606110001` (drop last_used_at) | `domain/auth` | `migrations/00003_drop_access_token_last_used_at.sql` |
|
||||
| `202606140003` (system user seed) | `domain/user` | `migrations/00002_seed_system_user.sql` |
|
||||
| `202606110004` (file_access_whitelist seed) | `domain/admin` | `migrations/00003_seed_file_access_whitelist.sql` |
|
||||
| `202606110005` (disk_cache configs seed) | `domain/admin` | `migrations/00004_seed_disk_cache_configs.sql` |
|
||||
| `202606120002` (update_upstream_repo seed) | `domain/admin` | `migrations/00005_seed_upstream_repo_config.sql` |
|
||||
| `202606130002` (system_configs value TEXT) | `domain/admin` | `migrations/00006_expand_config_value.sql` |
|
||||
| `202606130003` (storage_config seed) | `domain/admin` | `migrations/00007_seed_storage_config.sql` |
|
||||
| `202608160002` (log database configs) | `domain/admin` | `migrations/00008_seed_log_db_configs.sql` |
|
||||
| `202606120001` (login_session_ttl) | `domain/auth` | `migrations/00004_seed_login_session_ttl.sql` |
|
||||
| `202606130001` (w_uploads access_mode) | `domain/upload` | `migrations/00001_add_access_mode.sql` |
|
||||
| `202606170001` (upload indexes) | `domain/upload` | `migrations/00002_add_composite_indexes.sql` |
|
||||
| `202606170002` (upload stats table) | `domain/upload` | `migrations/00003_create_upload_stats.sql` |
|
||||
| `202606170003` (backfill stats) | `domain/upload` | `migrations/00004_backfill_upload_stats.sql` |
|
||||
| `202606180001` (drop storage_driver) | `domain/upload` | `migrations/00005_drop_storage_driver.sql` |
|
||||
| `202606140001` (push tables) | `domain/message_gateway` | `migrations/00002_create_push_tables.sql` |
|
||||
| `202606140004` (push channels) | `domain/message_gateway` | `migrations/00003_create_push_channels.sql` |
|
||||
| `202606150001` (push task_type) | `domain/message_gateway` | `migrations/00004_add_push_task_type.sql` |
|
||||
| `202606160001` (remove push config) | `domain/message_gateway` | `migrations/00005_remove_push_config.sql` |
|
||||
| `202608160003` (message gateway tables) | `domain/message_gateway` | `migrations/00006_create_message_tables.sql` |
|
||||
| `202606100001` (schedules) | `driver_asynq_cron` | `migrations/00001_create_schedules.sql` |
|
||||
| `202606110002` (schedules identity) | `driver_asynq_cron` | `migrations/00002_alter_schedules_identity.sql` |
|
||||
| `202606140005` (update cleanup schedule) | `driver_asynq_cron` | `migrations/00003_update_cleanup_schedule.sql` |
|
||||
| `202608160001` (user access logs) | `domain/risk_control/logstore` | `migrations/00001_create_access_logs.sql` |
|
||||
| `202608160002` (log_database configs) | `domain/admin` | （合并到 admin 步骤 7） |
|
||||
|
||||
---
|
||||
|
||||
### 步骤 4：补充缺失的 `go:embed` 和 `Register()` 调用
|
||||
|
||||
**`plugins/domain/admin/plugin.go`**：
|
||||
```go
|
||||
//go:embed migrations/*.sql
|
||||
var adminMigrations embed.FS
|
||||
|
||||
// 在 Apply() 中:
|
||||
ctx.Migrations().Register("admin", adminMigrations)
|
||||
```
|
||||
|
||||
**`plugins/domain/upload/plugin.go`**：
|
||||
```go
|
||||
//go:embed migrations/*.sql
|
||||
var uploadMigrations embed.FS
|
||||
|
||||
// 在 Apply() 中:
|
||||
ctx.Migrations().Register("upload", uploadMigrations)
|
||||
```
|
||||
|
||||
**`plugins/domain/risk_control/plugin.go`**：
|
||||
```go
|
||||
// go:embed 由 logstore 子包自行处理（它已有自己的 moved 文件）
|
||||
// 在 Apply() 中:
|
||||
ctx.Migrations().Register("risk_control/logstore", logstoreMigrationFS)
|
||||
```
|
||||
|
||||
**`plugins/drivers/driver_asynq_cron/plugin.go`**：
|
||||
```go
|
||||
//go:embed migrations/*.sql
|
||||
var cronMigrations embed.FS
|
||||
|
||||
// 在 Apply() 中:
|
||||
ctx.Migrations().Register("driver_asynq_cron", cronMigrations)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 步骤 5：解决 Admin 插件迁移与 Bootstrap 的冲突
|
||||
|
||||
当前 `admin/migrations/00001` 执行 `CREATE TABLE IF NOT EXISTS w_system_configs (...)`，但 bootstrap 已在步骤 1 中创建过这张表。需要：
|
||||
1. **保持 `IF NOT EXISTS`** 保证幂等性
|
||||
2. **从 admin migration 中移除 `w_schedules` 和 `w_task_executions` 的 CREATE**（它们在 bootstrap 中创建，属于 driver 插件）
|
||||
3. **仅保留 admin 自己的表**：`w_system_configs`, `w_templates`
|
||||
4. Seed 数据使用 `ON CONFLICT DO NOTHING` 避免重复：
|
||||
|
||||
当前 admin 的 seed 包含 29 个系统配置，其中约 14 个与全局迁移重复。整理后的 admin seed 应：
|
||||
|
||||
```sql
|
||||
INSERT INTO w_system_configs (...) VALUES
|
||||
('cap_login_enabled', 'false', ...),
|
||||
('cap_auto_solve', 'true', ...),
|
||||
-- ... (所有 29 个配置)
|
||||
ON CONFLICT (key) DO NOTHING;
|
||||
```
|
||||
|
||||
> 全局迁移中 `202606110004` 到 `202608160002` 的 7 个种子 INSERT 将被迁移到 admin，全部使用 `ON CONFLICT DO NOTHING`。
|
||||
|
||||
---
|
||||
|
||||
### 步骤 6：清理已迁移的全局文件
|
||||
|
||||
拆分完成后，从 `pkg/migrator/goose/postgres/` 中删除以下文件：
|
||||
|
||||
```
|
||||
202606100002_access_token_is_admin.sql
|
||||
202606100001_create_schedules.sql
|
||||
202606110001_remove_access_token_last_used_at.sql
|
||||
202606110002_alter_schedules_id_auto_increment.sql
|
||||
202606110004_add_file_access_whitelist_config.sql
|
||||
202606110005_add_disk_cache_configs.sql
|
||||
202606120001_add_login_session_ttl_config.sql
|
||||
202606120002_add_update_upstream_repository_config.sql
|
||||
202606130001_add_upload_access_mode.sql
|
||||
202606130002_expand_system_config_value.sql
|
||||
202606130003_add_storage_config.sql
|
||||
202606140001_create_push_tables.sql
|
||||
202606140003_add_system_user.sql
|
||||
202606140004_create_push_channels.sql
|
||||
202606140005_update_system_cleanup_schedule.sql
|
||||
202606150001_add_task_type_to_push_events.sql
|
||||
202606160001_remove_push_config.sql
|
||||
202606170001_add_upload_composite_indexes.sql
|
||||
202606170002_create_upload_stats_table.sql
|
||||
202606170003_backfill_upload_stats.sql
|
||||
202606180001_drop_upload_storage_driver.sql
|
||||
202608160001_create_user_access_logs.sql
|
||||
202608160002_log_database_configs.sql
|
||||
202608160003_create_message_gateway.sql
|
||||
```
|
||||
|
||||
**保留在 `pkg/migrator/goose/postgres/` 的仅限**：
|
||||
```
|
||||
00001_bootstrap.sql （合并后的初始化基座）
|
||||
```
|
||||
|
||||
**注意**：`202606110003_rename_tables_to_w_prefix.sql` 也被合并进 bootstrap。`202606090001_initial_schema.sql` 也被合并掉。
|
||||
|
||||
---
|
||||
|
||||
### 步骤 7：更新 `pkg/migrator` 导出 `gooseDialect()`
|
||||
|
||||
在 `pkg/migrator/migrator.go` 中将 `gooseDialect()` 和 `migrationDir()` 改为导出，供 `cmd/app.go` 的 `gooseEngine.Migrate()` 引用。
|
||||
|
||||
---
|
||||
|
||||
### 步骤 8：验证 + 提交
|
||||
|
||||
```bash
|
||||
cd /Users/ryan/Code/Go/Wavelet
|
||||
|
||||
# 1. 编译验证
|
||||
go build -mod=mod ./...
|
||||
go vet ./...
|
||||
|
||||
# 2. 架构门禁验证
|
||||
make code-check
|
||||
|
||||
# 3. 验证插件迁移注册完整性
|
||||
grep -rn 'go:embed.*migrations' plugins/domain/*/plugin.go plugins/drivers/*/plugin.go
|
||||
grep -rn 'Migrations()\.Register' plugins/domain/*/plugin.go plugins/drivers/*/plugin.go
|
||||
# → 每个有 migrations/ 目录的插件既要有 go:embed 又要有 Register()
|
||||
|
||||
# 4. 验证 admin 插件迁移完整性
|
||||
grep -rn 'w_schedules\|w_task_executions' plugins/domain/admin/migrations/
|
||||
# → 不应有（这些属于 driver 插件）
|
||||
|
||||
# 5. 提交
|
||||
git add -A && git commit -m "refactor(migration): split global SQL into per-plugin migrations
|
||||
|
||||
- Merge 26 global SQLs into bootstrap + per-plugin migrations
|
||||
- Fix gooseEngine to iterate plugin-registered MigrationEntry
|
||||
- Add go:embed + Register() to admin, upload, risk_control, driver_asynq_cron
|
||||
- Remove 23 migrated SQL files from pkg/migrator/goose/
|
||||
- Keep only bootstrap in pkg/migrator/goose/
|
||||
- All CREATE TABLE use IF NOT EXISTS, all INSERT use ON CONFLICT DO NOTHING"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 依赖关系图
|
||||
|
||||
```
|
||||
Bootstrap (pkg/migrator)
|
||||
├── 创建 w_users, w_access_tokens, w_auth_sources, w_external_accounts
|
||||
├── 创建 w_system_configs, w_templates, w_schedules, w_task_executions
|
||||
├── 创建 w_uploads, w_upload_stats
|
||||
└── 创建所有 w_ 前缀表
|
||||
│
|
||||
├─ auth/00002 (access_tokens is_admin)
|
||||
├─ auth/00003 (drop last_used_at)
|
||||
├─ auth/00004 (login_session_ttl seed)
|
||||
│
|
||||
├─ user/00002 (system user seed)
|
||||
│
|
||||
├─ admin/00001 (w_system_configs, w_templates) [IF NOT EXISTS]
|
||||
├─ admin/00002 (29 config seeds + 2 template seeds)
|
||||
├─ admin/00003–00008 (拆分后的种子迁移)
|
||||
│
|
||||
├─ upload/00001–00005 (access_mode → indexes → stats → backfill → drop)
|
||||
│
|
||||
├─ message_gateway/00001 (w_message_* tables)
|
||||
├─ message_gateway/00002–00006 (push tables → channels → task_type → cleanup)
|
||||
│
|
||||
├─ driver_asynq_cron/00001–00003 (schedules → identity → cleanup)
|
||||
│
|
||||
├─ driver_asynq_worker/00001 (task_executions — 如果有追加操作)
|
||||
│
|
||||
└─ risk_control/logstore/00001 (w_user_access_logs)
|
||||
```
|
||||
|
||||
所有步骤执行的迁移顺序由 Goose 的文件名前缀控制。Bootstrap 使用 `00001_`，每个插件的迁移从 `00002_` 开始编号（`00001` 留给插件自身表 CREATE，若插件 bootstrap 已创建则从 `00002` 开始）。
|
||||
@@ -1,84 +0,0 @@
|
||||
# Zero-Redis Pluggable Architecture Implementation Plan
|
||||
|
||||
> **Goal**: Extract Redis into optional plugins and introduce lightweight in-process equivalents (`cache_memory`, `driver_inproc_worker`, `driver_inproc_cron`), enabling zero-Redis monolithic and embedded deployment modes.
|
||||
|
||||
- **Architecture Spec**: [`docs/superpowers/specs/2026-08-28-zero-redis-pluggable-architecture-design.md`](file:///Users/ryan/Code/Go/Wavelet/docs/superpowers/specs/2026-08-28-zero-redis-pluggable-architecture-design.md)
|
||||
- **Branch**: `main`
|
||||
|
||||
---
|
||||
|
||||
## Proposed Changes
|
||||
|
||||
### 1. In-Memory Cache Infrastructure Plugin (`backend/plugins/infra/cache_memory`)
|
||||
|
||||
#### [NEW] `backend/plugins/infra/cache_memory/plugin.go`
|
||||
- Implements `core.Plugin` (`Name() == "cache_memory"`).
|
||||
- Applies `contracts.CacheService` to the Context via `core.Provide[contracts.CacheService](ctx, memCacheSvc)`.
|
||||
|
||||
#### [NEW] `backend/plugins/infra/cache_memory/cache.go`
|
||||
- Implements `contracts.CacheService` using `pkg/cache/ram`.
|
||||
- Dispatches in-process invalidation notifications via `ctx.Events().Emit("cache:invalidate", key)`.
|
||||
|
||||
#### [NEW] `backend/plugins/infra/cache_memory/plugin_test.go`
|
||||
- Unit tests for Get, Set, Delete, GetOrSet, TTL expiration, and event bus emission.
|
||||
|
||||
---
|
||||
|
||||
### 2. In-Process Async Worker Driver (`backend/plugins/drivers/driver_inproc_worker`)
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_worker/plugin.go`
|
||||
- Implements `core.Plugin` & `core.Driver` (`Type() == core.DriverTypeWorker`).
|
||||
- Scans and executes registered tasks from `ctx.Tasks().Tasks()`.
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_worker/executor.go`
|
||||
- In-memory buffered channel queue and worker goroutine pool managed via `util.Go`.
|
||||
- Supports execution timeout, retry with backoff, and graceful shutdown.
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_worker/plugin_test.go`
|
||||
- Unit tests for in-process task execution, concurrency limit, retry on error, and graceful shutdown.
|
||||
|
||||
---
|
||||
|
||||
### 3. In-Process Cron Scheduler Driver (`backend/plugins/drivers/driver_inproc_cron`)
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_cron/plugin.go`
|
||||
- Implements `core.Plugin` & `core.Driver` (`Type() == core.DriverTypeScheduler`).
|
||||
- Reads `ctx.Schedules().Schedules()` and schedules jobs using `robfig/cron/v3`.
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_cron/scheduler.go`
|
||||
- Handles Cron expression registration, job triggering, and graceful stopping.
|
||||
|
||||
#### [NEW] `backend/plugins/drivers/driver_inproc_cron/plugin_test.go`
|
||||
- Unit tests verifying cron job scheduling, execution tracking, and stop behavior.
|
||||
|
||||
---
|
||||
|
||||
### 4. Admin Domain Decoupling from Redis
|
||||
|
||||
#### [MODIFY] `backend/plugins/domain/admin/repository.go`
|
||||
- Introduce in-memory `RingBuffer` for task output streams when Redis is nil.
|
||||
- Fallback task log lookups to `RingBuffer` and `w_task_executions` table.
|
||||
|
||||
#### [MODIFY] `backend/plugins/domain/admin/system_config_cache.go`
|
||||
- Guard Redis PubSub listener so that when Redis is nil, it gracefully falls back to local event bus updates without spawning disconnected subscriber loops.
|
||||
|
||||
---
|
||||
|
||||
### 5. Application Assembly & Profile Switching
|
||||
|
||||
#### [MODIFY] `backend/cmd/app.go`
|
||||
- Switch dynamically between Redis plugins (`cache`, `driver_asynq_worker`, `driver_asynq_cron`) and In-Process plugins (`cache_memory`, `driver_inproc_worker`, `driver_inproc_cron`) based on `config.Config.Redis.Enabled`.
|
||||
|
||||
#### [MODIFY] `backend/cmd/app_test.go`
|
||||
- Add test verifying application bootstrap in both `Redis.Enabled = true` and `Redis.Enabled = false` states.
|
||||
|
||||
---
|
||||
|
||||
## Verification Plan
|
||||
|
||||
### Automated Tests
|
||||
1. **In-Memory Cache Tests**: `go test -v ./backend/plugins/infra/cache_memory/...`
|
||||
2. **In-Process Worker Tests**: `go test -v ./backend/plugins/drivers/driver_inproc_worker/...`
|
||||
3. **In-Process Cron Tests**: `go test -v ./backend/plugins/drivers/driver_inproc_cron/...`
|
||||
4. **Full Test Suite**: `cd backend && go test ./...`
|
||||
5. **Quality Gate**: `make code-check && make format`
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,595 +0,0 @@
|
||||
# Wavelet Cordis 插件化架构实战开发指南与标准规范
|
||||
|
||||
- **文档类型**: 下游开发者手册 / 架构实战指南 (Cookbook & Architecture Reference)
|
||||
- **目标受众**: 官方插件开发者、下游业务二开工程师、架构师
|
||||
- **版本**: v1.0.0 (2026-08-27)
|
||||
|
||||
---
|
||||
|
||||
# 目录
|
||||
- [第一部分：下游项目实战开发指南与 22 个高频开发场景解答](#第一部分下游项目实战开发指南与-22-个高频开发场景解答)
|
||||
- [场景 1：插件必须要实现哪些方法与契约？](#场景-1插件必须要实现哪些方法与契约)
|
||||
- [场景 2：插件间如何进行单向服务调用？](#场景-2插件间如何进行单向服务调用)
|
||||
- [场景 3：插件间存在双向/循环调用时如何解决（杜绝 import cycle）？](#场景-3插件间存在双向循环调用时如何解决杜绝-import-cycle)
|
||||
- [场景 4：如何开发并注册一个 HTTP API 接口？如何添加路由中间件？](#场景-4如何开发并注册一个-http-api-接口如何添加路由中间件)
|
||||
- [场景 5：如何获取当前登录用户信息？](#场景-5如何获取当前登录用户信息)
|
||||
- [场景 6：如何开发并注册一个 Asynq 异步 Worker 任务？](#场景-6如何开发并注册一个-asynq-异步-worker-任务)
|
||||
- [场景 7：如何开发并注册一个 Cron 定时任务？](#场景-7如何开发并注册一个-cron-定时任务)
|
||||
- [场景 8：数据库表结构如何声明？ORM 模型规范是什么？](#场景-8数据库表结构如何声明orm-模型规范是什么)
|
||||
- [场景 9：数据库如何做独立迁移？Goose SQL 怎么组织？](#场景-9数据库如何做独立迁移goose-sql-怎么组织)
|
||||
- [场景 10：如果有多个业务插件需要读写同一张表怎么办？](#场景-10如果有多个业务插件需要读写同一张表怎么办)
|
||||
- [场景 11：如果跨插件操作多张表，如何确保事务一致性？](#场景-11如果跨插件操作多张表如何确保事务一致性)
|
||||
- [场景 12：如何发布和订阅领域事件 (EventBus)？](#场景-12如何发布和订阅领域事件-eventbus)
|
||||
- [场景 13：如何向系统注册插件自定义配置（config.yaml 与管理台热加载设置）？](#场景-13如何向系统注册插件自定义配置configyaml-与管理台热加载设置)
|
||||
- [场景 14：如何使用多层缓存（RAM L1 + Redis L2 + PubSub 同步）？](#场景-14如何使用多层缓存ram-l1--redis-l2--pubsub-同步)
|
||||
- [场景 15：如何使用分布式锁 (DistLock) 防止并发超卖与重复消费？](#场景-15如何使用分布式锁-distlock-防止并发超卖与重复消费)
|
||||
- [场景 16：如何向管理后台动态注册监控数据与管理控制台？](#场景-16如何向管理后台动态注册监控数据与管理控制台)
|
||||
- [场景 17：插件如何实现健康检查探针与就绪检查 (Health Check)？](#场景-17插件如何实现健康检查探针与就绪检查-health-check)
|
||||
- [场景 18：插件如何扩展其他插件的能力（如新增一种 OAuth 登录提供商 / 新增消息推送渠道）？](#场景-18插件如何扩展其他插件的能力如新增一种-oauth-登录提供商--新增消息推送渠道)
|
||||
- [场景 19：插件如何编写单元测试与集成测试（Mock 上下文与依赖打桩）？](#场景-19插件如何编写单元测试与集成测试mock-上下文与依赖打桩)
|
||||
- [场景 20：以不同角色（api / worker / schedule / all）启动时，插件代码如何适配？](#场景-20以不同角色api--worker--schedule--all启动时插件代码如何适配)
|
||||
- [场景 21：当某个插件流量暴增需要独立拆分为微服务时，如何零成本平滑改造？](#场景-21当某个插件流量暴增需要独立拆分为微服务时如何零成本平滑改造)
|
||||
- [场景 22：插件如何安全处理文件上传与大文件摄取 (upload.Ingest)？](#场景-22插件如何安全处理文件上传与大文件摄取-uploadingest)
|
||||
- [第二部分：整个项目的目录结构划分与包职责定义](#第二部分整个项目的目录结构划分与包职责定义)
|
||||
- [第三部分：框架核心提供给插件调用的公用能力矩阵 (Context Capability Matrix)](#第三部分框架核心提供给插件调用的公用能力矩阵-context-capability-matrix)
|
||||
|
||||
---
|
||||
|
||||
# 第一部分：下游项目实战开发指南与 22 个高频开发场景解答
|
||||
|
||||
### 场景 1：插件必须要实现哪些方法与契约？
|
||||
每个插件必须实现 `core.Plugin` 接口，仅需提供两个核心方法：`Name()` 与 `Apply(ctx *core.Context)`。
|
||||
|
||||
```go
|
||||
package myplugin
|
||||
|
||||
import "github.com/Rain-kl/Wavelet/core"
|
||||
|
||||
type Plugin struct{}
|
||||
|
||||
// 1. Name: 返回全局唯一的插件标识符（建议遵循命名空间规范，如 "biz.order"）
|
||||
func (p *Plugin) Name() string {
|
||||
return "biz.order"
|
||||
}
|
||||
|
||||
// 2. Apply: 核心装载入口，所有的路由注册、任务注册、服务提供与依赖消费均在此完成
|
||||
func (p *Plugin) Apply(ctx *core.Context) error {
|
||||
// 在此编写装载逻辑
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 2：插件间如何进行单向服务调用？
|
||||
**规则**：插件之间**禁止直接相互 import 具体实现包**。调用方仅面向 `core/contracts` 中的纯 Interface 编程，运行时通过 Context 解析。
|
||||
|
||||
```go
|
||||
// 1. 插件 A (提供者 plugins/user) 将服务注入 Context
|
||||
func (p *UserPlugin) Apply(ctx *core.Context) error {
|
||||
userSvc := NewUserServiceImpl(ctx.DB())
|
||||
ctx.Provide[contracts.UserService](userSvc)
|
||||
return nil
|
||||
}
|
||||
|
||||
// 2. 插件 B (消费者 plugins/order) 声明依赖并调用
|
||||
func (p *OrderPlugin) Apply(ctx *core.Context) error {
|
||||
return ctx.Using(func(userSvc contracts.UserService) {
|
||||
// userSvc 已由容器自动注入就绪
|
||||
v1 := ctx.Router().Group("/api/v1/orders")
|
||||
v1.POST("", func(c *gin.Context) {
|
||||
userInfo, err := userSvc.GetUserProfile(c.Request.Context(), "user_123")
|
||||
// 处理订单逻辑...
|
||||
})
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 3：插件间存在双向/循环调用时如何解决（杜绝 import cycle）？
|
||||
**问题场景**：`auth` 登录成功后需要查 `user` 资料；`user` 重置密码后需要调 `auth` 吊销 session。若两个 package 互相 import，Go 编译器会报 `import cycle not allowed`。
|
||||
|
||||
**Cordis 解法**：
|
||||
1. 接口均定义在 `core/contracts`，双方只依赖 `core/contracts`。
|
||||
2. 运行时采用 **延迟注入 (Lazy Resolution / Inject)** 或 **事件解耦 (EventBus)**：
|
||||
|
||||
```go
|
||||
// plugins/auth/service.go
|
||||
func (s *AuthServiceImpl) OnLoginSuccess(c context.Context, uid string) {
|
||||
// 延迟注入 UserService，不发生 package 级循环导入
|
||||
userSvc, err := core.Inject[contracts.UserService](s.ctx)
|
||||
if err == nil {
|
||||
userSvc.UpdateLastLoginTime(c, uid)
|
||||
}
|
||||
}
|
||||
```
|
||||
*更加推荐的方式是发射领域事件*（见场景 12），由 `user` 插件自愿监听，彻底消除相互调用的硬依赖。
|
||||
|
||||
---
|
||||
|
||||
### 场景 4：如何开发并注册一个 HTTP API 接口？如何添加路由中间件？
|
||||
插件通过 `ctx.Router()` 声明路由。微内核支持标准 Gin 路由组与中间件挂载：
|
||||
|
||||
```go
|
||||
func (p *OrderPlugin) Apply(ctx *core.Context) error {
|
||||
// 获取全局或 auth 插件提供的中间件
|
||||
authSvc, _ := core.Inject[contracts.AuthService](ctx)
|
||||
|
||||
// 创建带版本前缀和鉴权中间件的路由组
|
||||
group := ctx.Router().Group("/api/v1/orders", authSvc.RequireAuthMiddleware())
|
||||
|
||||
// 注册 Handler
|
||||
group.GET("", p.handleListOrders)
|
||||
group.POST("", p.handleCreateOrder)
|
||||
group.GET("/:id", p.handleGetOrderDetail)
|
||||
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 5：如何获取当前登录用户信息？
|
||||
`auth` 插件会在上下文中注入当前用户 Session。业务 Handler 可直接调用统一 Helper：
|
||||
|
||||
```go
|
||||
func (p *OrderPlugin) handleCreateOrder(c *gin.Context) {
|
||||
// 1. 从当前 Gin 请求上下文中提取认证用户信息
|
||||
currentUser, ok := oauth.GetCurrentUser(c)
|
||||
if !ok {
|
||||
response.AbortUnauthorized(c, errs.ErrUnauthorized)
|
||||
return
|
||||
}
|
||||
|
||||
log.Printf("当前下单用户 ID: %s, 权限角色: %s", currentUser.ID, currentUser.Role)
|
||||
// 2. 正常业务处理...
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 6：如何开发并注册一个 Asynq 异步 Worker 任务？
|
||||
```go
|
||||
func (p *OrderPlugin) Apply(ctx *core.Context) error {
|
||||
// 1. 注册 Asynq 任务类型与消费处理器
|
||||
ctx.Task().Register("order:cancel_timeout", p.handleTimeoutCancelTask)
|
||||
return nil
|
||||
}
|
||||
|
||||
// 2. 任务执行函数
|
||||
func (p *OrderPlugin) handleTimeoutCancelTask(ctx context.Context, t *asynq.Task) error {
|
||||
var payload OrderTimeoutPayload
|
||||
if err := json.Unmarshal(t.Payload(), &payload); err != nil {
|
||||
return err
|
||||
}
|
||||
// 执行超时关单业务逻辑...
|
||||
return nil
|
||||
}
|
||||
|
||||
// 3. 业务中异步投递任务
|
||||
func (p *OrderPlugin) EnqueueTimeoutCheck(ctx context.Context, orderID string) {
|
||||
p.ctx.TaskClient().EnqueueContext(ctx, asynq.NewTask("order:cancel_timeout", payloadBytes), asynq.ProcessIn(15*time.Minute))
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 7：如何开发并注册一个 Cron 定时任务？
|
||||
```go
|
||||
func (p *ReportPlugin) Apply(ctx *core.Context) error {
|
||||
// 每天凌晨 2 点执行日报汇总任务
|
||||
ctx.Schedule().RegisterCron("0 2 * * *", "report:daily_summary", DailyReportPayload{Type: "all"})
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 8：数据库表结构如何声明？ORM 模型规范是什么？
|
||||
**规范**：
|
||||
1. 表名必须带有插件专有前缀（如 `w_order_`、`w_auth_`），避免跨插件表名冲突。
|
||||
2. 零值与数据库默认值严格对齐；禁止物理外键，显式建索引。
|
||||
3. 必须通过 GORM 结构体清晰声明 `gorm:"..."` 标签与 `json:"..."`。
|
||||
|
||||
```go
|
||||
package models
|
||||
|
||||
import "time"
|
||||
|
||||
type Order struct {
|
||||
ID string `gorm:"column:id;primaryKey;size:64" json:"id"`
|
||||
UserID string `gorm:"column:user_id;index;size:64;not null" json:"user_id"`
|
||||
Amount int64 `gorm:"column:amount;not null" json:"amount"`
|
||||
Status string `gorm:"column:status;size:32;index;not null;default:'pending'" json:"status"`
|
||||
CreatedAt time.Time `gorm:"column:created_at;autoCreateTime" json:"created_at"`
|
||||
UpdatedAt time.Time `gorm:"column:updated_at;autoUpdateTime" json:"updated_at"`
|
||||
DeletedAt *time.Time `gorm:"column:deleted_at;index" json:"-"`
|
||||
}
|
||||
|
||||
func (Order) TableName() string {
|
||||
return "w_orders"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 9：数据库如何做独立迁移？Goose SQL 怎么组织？
|
||||
**彻底告别集中大迁移目录**。每个插件在内部目录建立 `migrations/`，并通过 `//go:embed` 打包注入：
|
||||
|
||||
```go
|
||||
// plugins/order/plugin.go
|
||||
package order
|
||||
|
||||
import (
|
||||
"embed"
|
||||
"github.com/Rain-kl/Wavelet/core"
|
||||
)
|
||||
|
||||
//go:embed migrations/*.sql
|
||||
var orderMigrations embed.FS
|
||||
|
||||
func (p *Plugin) Apply(ctx *core.Context) error {
|
||||
// 注册本插件的专属迁移（系统启动时自动按版本号执行）
|
||||
ctx.Migrations().Register("order", orderMigrations)
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
#### SQL 迁移脚本规范 (`plugins/order/migrations/00001_initial.sql`)：
|
||||
|
||||
每个插件只需维护一个 `00001_initial.sql`，包含该插件的全部建表语句与种子数据。
|
||||
|
||||
```sql
|
||||
-- +goose Up
|
||||
-- +goose StatementBegin
|
||||
CREATE TABLE IF NOT EXISTS w_orders (
|
||||
id VARCHAR(64) PRIMARY KEY,
|
||||
user_id VARCHAR(64) NOT NULL,
|
||||
amount BIGINT NOT NULL,
|
||||
status VARCHAR(32) NOT NULL DEFAULT 'pending',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
CREATE INDEX IF NOT EXISTS idx_w_orders_user_id ON w_orders(user_id);
|
||||
|
||||
-- 种子数据（使用 ON CONFLICT DO NOTHING 保证幂等）
|
||||
INSERT INTO w_orders (id, user_id, amount, status, created_at, updated_at)
|
||||
VALUES ('init_001', 'system', 0, 'completed', CURRENT_TIMESTAMP, CURRENT_TIMESTAMP)
|
||||
ON CONFLICT (id) DO NOTHING;
|
||||
-- +goose StatementEnd
|
||||
|
||||
-- +goose Down
|
||||
-- +goose StatementBegin
|
||||
DROP TABLE IF EXISTS w_orders;
|
||||
-- +goose StatementEnd
|
||||
```
|
||||
|
||||
#### 版本管理机制
|
||||
|
||||
所有插件共享一张 `w_schema_versions` 表，以 `plugin_id` 区分：
|
||||
|
||||
```
|
||||
w_schema_versions (plugin_id, version_id, applied_at)
|
||||
```
|
||||
|
||||
启动时，引擎遍历每个插件：
|
||||
1. 查询 `w_schema_versions WHERE plugin_id = 'order'` 获取当前最大版本号
|
||||
2. 扫描插件 `migrations/` 目录下的 `.sql` 文件
|
||||
3. 如果存在未应用的版本号 → 执行迁移
|
||||
4. 如果全部已应用 → 跳过
|
||||
|
||||
```sql
|
||||
-- 查看全局迁移状态
|
||||
SELECT * FROM w_schema_versions ORDER BY plugin_id, version_id;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 10：如果有多个业务插件需要读写同一张表怎么办？
|
||||
**黄金准则**：**表有且仅有一个所有者插件 (Single Owner Principle)**。
|
||||
* 严禁插件 B 直接通过 SQL 修改插件 A 拥有的核心表（如订单插件直接修改用户表）。
|
||||
* **合法模式 1（服务调用）**：插件 A 提供 `UserService.DeductBalance(uid, amount)`，插件 B 调用该接口。
|
||||
* **合法模式 2（只读视图 / 共享查询 DTO）**：如果仅仅是高频联合查询（报表），插件 A 暴露只读查询接口，或通过数据库只读从库直接投影。
|
||||
|
||||
---
|
||||
|
||||
### 场景 11：如果跨插件操作多张表，如何确保事务一致性？
|
||||
在插件化和微服务就绪体系下，**跨插件的强分布式事务是反模式**。
|
||||
|
||||
1. **同插件内多表操作**：直接使用本地数据库事务：
|
||||
```go
|
||||
err := ctx.DB().Transaction(func(tx *gorm.DB) error {
|
||||
if err := tx.Create(&order).Error; err != nil { return err }
|
||||
if err := tx.Create(&orderItem).Error; err != nil { return err }
|
||||
return nil
|
||||
})
|
||||
```
|
||||
2. **跨插件操作（如创建订单 + 扣减库存 + 发送通知）**：
|
||||
* 采用 **最终一致性 (Eventual Consistency / Saga 模式)**。
|
||||
* 本地事务成功后，发射 `OrderCreatedEvent` 到 EventBus；
|
||||
* 库存插件监听到事件后扣减库存，若失败则发布补偿事件触发订单取消。
|
||||
|
||||
---
|
||||
|
||||
### 场景 12：如何发布和订阅领域事件 (EventBus)？
|
||||
```go
|
||||
// 1. 定义强类型事件结构
|
||||
type OrderPaidEvent struct {
|
||||
OrderID string `json:"order_id"`
|
||||
UserID string `json:"user_id"`
|
||||
PayAmount int64 `json:"pay_amount"`
|
||||
}
|
||||
|
||||
// 2. 插件 A 发布事件
|
||||
ctx.Events().Emit("order:paid", OrderPaidEvent{OrderID: "ord_1", UserID: "u_1", PayAmount: 9900})
|
||||
|
||||
// 3. 插件 B 订阅事件
|
||||
ctx.Events().On("order:paid", func(c context.Context, e OrderPaidEvent) error {
|
||||
log.Printf("收到支付成功事件，开始为用户 %s 发放权益", e.UserID)
|
||||
return nil
|
||||
})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 13：如何向系统注册插件自定义配置（config.yaml 与管理台热加载设置）？
|
||||
```go
|
||||
type OrderConfig struct {
|
||||
MaxItemsPerOrder int `yaml:"max_items" json:"max_items"`
|
||||
AutoCancelMins int `yaml:"auto_cancel_mins" json:"auto_cancel_mins"`
|
||||
}
|
||||
|
||||
func (p *OrderPlugin) Apply(ctx *core.Context) error {
|
||||
var cfg OrderConfig
|
||||
// 1. 自动从 config.yaml 中的 plugins.order 节点绑定配置
|
||||
ctx.Config().Bind("plugins.order", &cfg)
|
||||
|
||||
// 2. 注册为管理台可动态修改的系统参数
|
||||
ctx.Settings().Register(core.SettingSchema{
|
||||
Key: "order.auto_cancel_mins",
|
||||
Default: 15,
|
||||
Description: "未支付订单自动取消时间 (分钟)",
|
||||
})
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 14：如何使用多层缓存（RAM L1 + Redis L2 + PubSub 同步）？
|
||||
框架提供三层穿透缓存能力，防止缓存击穿与雪崩：
|
||||
|
||||
```go
|
||||
func (s *OrderService) GetOrderWithCache(ctx context.Context, orderID string) (*Order, error) {
|
||||
var order Order
|
||||
err := s.ctx.Cache().GetOrSet(ctx, "order:"+orderID, &order, 10*time.Minute, func() (any, error) {
|
||||
// Cache Miss 回源查 DB
|
||||
var dbOrder Order
|
||||
if err := s.db.WithContext(ctx).First(&dbOrder, "id = ?", orderID).Error; err != nil {
|
||||
return nil, err
|
||||
}
|
||||
return &dbOrder, nil
|
||||
})
|
||||
return &order, err
|
||||
}
|
||||
|
||||
// 当订单更新时，广播失效所有节点的 L1 内存缓存与 L2 Redis 缓存
|
||||
func (s *OrderService) InvalidateCache(ctx context.Context, orderID string) {
|
||||
s.ctx.Cache().Delete(ctx, "order:"+orderID)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 15：如何使用分布式锁 (DistLock) 防止并发超卖与重复消费？
|
||||
```go
|
||||
func (s *OrderService) ProcessPayment(ctx context.Context, orderID string) error {
|
||||
// 获取分布式锁，租期 5 秒
|
||||
unlock, err := s.ctx.DistLock().Lock(ctx, "lock:order:pay:"+orderID, 5*time.Second)
|
||||
if err != nil {
|
||||
return fmt.Errorf("当前订单正在处理中，请勿重复提交")
|
||||
}
|
||||
defer unlock() // 确保释放
|
||||
|
||||
// 执行扣款操作...
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 16：如何向管理后台动态注册监控数据与管理控制台？
|
||||
插件可以向管理后台扩展点注入自己的仪表盘指标和诊断探针：
|
||||
|
||||
```go
|
||||
func (p *OrderPlugin) Apply(ctx *core.Context) error {
|
||||
ctx.Admin().RegisterMetric("order_count_today", func(c context.Context) any {
|
||||
var count int64
|
||||
ctx.DB().Model(&models.Order{}).Where("created_at >= ?", todayStart()).Count(&count)
|
||||
return count
|
||||
})
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 17：插件如何实现健康检查探针与就绪检查 (Health Check)？
|
||||
```go
|
||||
func (p *PaymentPlugin) Apply(ctx *core.Context) error {
|
||||
ctx.Health().RegisterProbe("payment_gateway", func(ctx context.Context) error {
|
||||
// 测试第三方支付网关网络连通性
|
||||
return pingPaymentGateway(ctx)
|
||||
})
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 18：插件如何扩展其他插件的能力（如新增一种 OAuth 登录提供商 / 新增消息推送渠道）？
|
||||
采用 **注册表扩展点模式 (Registry Pattern)**：
|
||||
|
||||
```go
|
||||
// 1. 下游编写微信登录插件 plugins/oauth_wechat
|
||||
func (p *WeChatOAuthPlugin) Apply(ctx *core.Context) error {
|
||||
return ctx.Using(func(authRegistry contracts.AuthRegistry) {
|
||||
// 向核心 auth 插件注入微信 OAuth 实现
|
||||
authRegistry.RegisterOAuthProvider("wechat", &WeChatProvider{...})
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 19：插件如何编写单元测试与集成测试（Mock 上下文与依赖打桩）？
|
||||
微内核提供轻量测试脚手架 `coretest`：
|
||||
|
||||
```go
|
||||
func TestOrderCreate(t *testing.T) {
|
||||
// 1. 创建内存测试专用 Context
|
||||
ctx := coretest.NewMockContext(t)
|
||||
|
||||
// 2. Mock 依赖的 UserService
|
||||
mockUserSvc := &MockUserService{ReturnUser: &contracts.UserDTO{ID: "u_1", Balance: 1000}}
|
||||
ctx.Provide[contracts.UserService](mockUserSvc)
|
||||
|
||||
// 3. 装载插件
|
||||
plugin := &OrderPlugin{}
|
||||
require.NoError(t, plugin.Apply(ctx))
|
||||
|
||||
// 4. 发起 HTTP 接口测试
|
||||
w := ctx.PerformRequest("POST", "/api/v1/orders", `{"item_id":"item_1"}`)
|
||||
assert.Equal(t, 200, w.Code)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 20：以不同角色（api / worker / schedule / all）启动时，插件代码如何适配？
|
||||
**开发者无需做任何特殊处理**！
|
||||
插件只需在一个 `Apply` 方法中把自己的路由、任务、调度全部注册进 `Context`。微内核调度器会根据运行命令自动按需激活对应的运行时驱动，不匹配的能力保持休眠。
|
||||
|
||||
---
|
||||
|
||||
### 场景 21：当某个插件流量暴增需要独立拆分为微服务时，如何零成本平滑改造？
|
||||
```go
|
||||
// 1. 之前单体模式：在 main.go 中加载本地实现
|
||||
app.Use(&auth.Plugin{}) // 进程内直接运行
|
||||
|
||||
// 2. 拆分为微服务后：只需将 main.go 替换为 gRPC 客户端代理插件！
|
||||
app.Use(&auth_grpc_client.Plugin{RemoteAddr: "auth-service.prod:9000"})
|
||||
|
||||
// 3. 所有依赖 auth 的业务插件（如 order, user）业务代码 0 处修改！
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 22：插件如何安全处理文件上传与大文件摄取 (upload.Ingest)？
|
||||
**严格规则**：禁止插件自行直接写入对象存储底层 Bucket 或直连底层文件系统。统一走平台摄取服务：
|
||||
|
||||
```go
|
||||
func (p *OrderPlugin) handleUploadInvoice(c *gin.Context) {
|
||||
fileHeader, _ := c.FormFile("file")
|
||||
|
||||
// 使用平台统一摄取引擎（自动计算哈希、防重传、生成签名 URL 与入库追踪）
|
||||
ingestResult, err := upload.IngestFormFile(c.Request.Context(), fileHeader, upload.IngestPolicy{
|
||||
AllowedTypes: []string{"image/png", "application/pdf"},
|
||||
MaxSizeBytes: 10 * 1024 * 1024,
|
||||
})
|
||||
if err != nil {
|
||||
response.AbortBadRequest(c, errs.ErrUploadFailed)
|
||||
return
|
||||
}
|
||||
|
||||
c.JSON(200, response.OK(gin.H{"file_url": ingestResult.URL}))
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 第二部分：整个项目的目录结构划分与包职责定义
|
||||
|
||||
```text
|
||||
Wavelet/
|
||||
├── cmd/ # CLI 命令分发与装配入口
|
||||
│ ├── root.go # Cobra 根命令
|
||||
│ ├── server.go # 综合启动器（支持 api/worker/schedule/all profile）
|
||||
│ └── migrate.go # 数据库独立迁移命令行工具
|
||||
│
|
||||
├── core/ # 【微内核引擎 (Zero Business Logic)】
|
||||
│ ├── context.go # Context 上下文总线与 Fork 树
|
||||
│ ├── container.go # 基于泛型的 IoC 服务注册与解析器
|
||||
│ ├── events.go # 强类型领域事件总线 (EventBus)
|
||||
│ ├── lifecycle.go # 启动/停止生命周期编排状态机
|
||||
│ ├── contracts/ # 【跨插件标准服务契约 (纯 Interface)】
|
||||
│ │ ├── auth.go # AuthService 契约
|
||||
│ │ ├── user.go # UserService 契约
|
||||
│ │ ├── cache.go # CacheService 契约
|
||||
│ │ └── database.go # DBService 契约
|
||||
│ └── extpoints/ # 扩展点定义 (Router, Task, Migration, Setting)
|
||||
│
|
||||
├── plugins/ # 【官方标准插件库 (完全高内聚闭包)】
|
||||
│ ├── drivers/ # 运行时驱动插件
|
||||
│ │ ├── driver_http/ # Gin Web HTTP 驱动
|
||||
│ │ ├── driver_asynq_worker/ # Asynq Worker 并发消费驱动
|
||||
│ │ └── driver_asynq_cron/ # Asynq Cron 调度器驱动
|
||||
│ │
|
||||
│ ├── infra/ # 基础设施服务插件
|
||||
│ │ ├── database/ # GORM 多数据源与读写分离插件
|
||||
│ │ ├── cache/ # RAM + Redis + PubSub 缓存插件
|
||||
│ │ ├── logger/ # Zap + Otel 分布式链路追踪日志插件
|
||||
│ │ └── storage/ # S3 / OSS / Local 对象存储插件
|
||||
│ │
|
||||
│ └── domain/ # 业务领域能力插件
|
||||
│ ├── auth/ # OAuth / Session / Passkey 认证插件
|
||||
│ ├── user/ # 用户资料 / 权限 / 角色插件
|
||||
│ ├── message_gateway/ # Bot 网关 / 渠道推送插件
|
||||
│ ├── risk_control/ # 访问控制 / IP 限流 / 安全风控插件
|
||||
│ └── admin/ # 系统管理台与监控面板插件
|
||||
│
|
||||
└── downstream/ # 【下游二开项目模板与脚手架】
|
||||
├── README.md # 下游插件开发指南
|
||||
└── plugins/ # 下游自定义业务插件目录
|
||||
└── custom_example/ # 官方标准插件开发基准模板（含完整分层结构）
|
||||
```
|
||||
|
||||
### 各层职责与禁止规则 (Guardrails)：
|
||||
1. **`core/`**：
|
||||
- **职责**：纯抽象，提供 IoC、Context、EventBus 和 Lifecycle。
|
||||
- **严禁**：严禁 import 任何具体业务包，严禁 import `gin`、`gorm`、`asynq`。
|
||||
2. **`core/contracts/`**：
|
||||
- **职责**：仅定义公开的 Go Interface 和公共 DTO。
|
||||
- **严禁**：严禁包含任何具体实现逻辑或 SQL 操作。
|
||||
3. **`plugins/` 与 `downstream/`**：
|
||||
- **职责**：所有业务逻辑和驱动实现的归宿。遵循统一标准分层架构（Layered Architecture / MVC 变体）。
|
||||
- **统一分层架构与标准开发模板**：
|
||||
- **唯一基准模板**：以 [`backend/downstream/plugins/custom_example`](file:///Users/ryan/Code/Go/Wavelet/backend/downstream/plugins/custom_example) 为全项目统一基准模板。
|
||||
- **物理子包隔离结构**：包含 `plugin.go`, `consts/`, `controller/`, `service/`, `dao/`, `model/` [含 `entity/`, `do/`], `migrations/` [含 `postgres/`, `sqlite/`]。
|
||||
- **命名与依赖禁令**：**严禁在根包平铺 `handlers_*`、`service_*`、`dao_*` 等前缀文件**，子包内文件直接以纯业务实体命名（如 `hello.go`、`user.go`）。严格约束 `controller -> service -> dao -> model` 单向依赖。
|
||||
- **严禁**：插件之间严禁跨包 import 内部私有代码，跨插件调用一律走 `contracts` 接口或 `EventBus`。
|
||||
|
||||
---
|
||||
|
||||
# 第三部分：框架核心提供给插件调用的公用能力矩阵 (Context Capability Matrix)
|
||||
|
||||
每个插件在 `Apply(ctx *core.Context)` 时，都可以无缝调用微内核暴露的以下标准能力：
|
||||
|
||||
| 扩展点方法 | 返回类型 | 功能说明 | 适用场景 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| `ctx.Router()` | `RouterExtension` | 声明 HTTP 路由、前缀分组与挂载中间件 | 暴露 API 接口、Web 控制台 |
|
||||
| `ctx.Task()` | `TaskExtension` | 注册 Asynq 异步任务消费处理器 | 耗时后台任务、异步消息发送 |
|
||||
| `ctx.Schedule()` | `ScheduleExtension`| 注册 Cron 定时调度任务 | 定时报表统计、周期性清理 |
|
||||
| `ctx.Migrations()` | `MigrationExtension`| 注册插件专属的 Goose SQL 迁移嵌入系统 | 自建数据表、版本升级 |
|
||||
| `ctx.Events()` | `EventBus` | 强类型领域事件的发布与订阅 (Emit / On) | 跨插件完全解耦通知与状态同步 |
|
||||
| `ctx.Settings()` | `SettingExtension` | 声明动态可配置项（支持热更新） | 业务参数配置、管理台可调节参数 |
|
||||
| `ctx.DB()` | `*gorm.DB` | 获取全局受事务与 Trace 保护的 GORM 数据源 | 数据持久化 CRUD |
|
||||
| `ctx.Cache()` | `CacheService` | 三层穿透缓存（RAM L1 + Redis L2 + PubSub 广播）| 高频读数据性能加速 |
|
||||
| `ctx.DistLock()` | `DistLockService` | 基于 Redis 的工业级分布式锁 | 防并发超卖、防重复执行 |
|
||||
| `ctx.Logger()` | `Logger` | 携带链路 TraceID 的结构化日志记录器 | 业务日志打印与审计 |
|
||||
| `ctx.Storage()` | `StorageService` | 统一对象存储读写引擎 | 文件摄取、图片持久化 |
|
||||
| `core.Provide[T]`| `void` | 向全局 IoC 容器注册本插件提供的强类型服务 | 暴露自身能力给其他插件消费 |
|
||||
| `core.Inject[T]` | `(T, error)` | 从全局 IoC 容器中按类型获取服务实例 | 消费其他插件暴露的服务 |
|
||||
| `core.Using[T]` | `error` | 响应式声明依赖，当服务就绪时执行回调 | 声明前置依赖关系 |
|
||||
|
||||
@@ -1,279 +0,0 @@
|
||||
# Wavelet Cordis 微内核与全插件化架构设计规范
|
||||
|
||||
- **创建日期**: 2026-08-27
|
||||
- **状态**: Approved Design
|
||||
- **架构代号**: Cordis-Wavelet (Next 5-Year Foundation)
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
### 1.1 现状与痛点
|
||||
Wavelet 当前采用中心化显式装配架构（`internal/platform/bootstrap` 与 `internal/router`），业务逻辑集中在 `internal/apps/` 下。
|
||||
随着业务功能的快速拓展，现有架构暴露出以下瓶颈：
|
||||
1. **模块高耦合**：新增功能需要横跨多个中心化目录（`apps/`、`router/`、`bootstrap/`、`migrator/`、`task/handlers/`）进行插桩，难以做到随插随用与物理隔离。
|
||||
2. **下游扩展困难**：二次开发项目无法在不修改核心源码的前提下灵活扩展或替换业务模块。
|
||||
3. **缺乏清晰的运行切面**：API、Worker、Scheduler 启动模式依赖手动条件判断，维护成本高。
|
||||
|
||||
### 1.2 改造核心目标
|
||||
1. **微内核 (Micro-Kernel)**：内核仅提供上下文总线（Context）、依赖注入（IoC）、生命周期状态机与扩展点协议，内核本身零具体业务依赖。
|
||||
2. **一切皆插件 (All-in-Plugins)**：数据库、缓存、日志、HTTP 服务、任务处理、认证鉴权、消息网关及业务能力全部以插件形式挂载在 Context 上。
|
||||
3. **下游一等公民支持**：下游项目通过声明式 `app.Use(&MyPlugin{})` 引入官方或自定义插件，编译为单一高性能二进制文件。
|
||||
4. **面向未来 5 年的分布式与微服务就绪 (Monolith-First, Microservice-Ready)**：基于强类型接口契约，单体模式下零开销内存调用，高并发下支持透明替换为 gRPC/RPC 客户端插件完成微服务拆分。
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心架构模型 (Core Architecture)
|
||||
|
||||
```
|
||||
+-----------------------------------------------------------------------------------+
|
||||
| 下游业务项目 (Downstream Application) |
|
||||
| main.go: app.Use(&logger.Plugin{}).Use(&auth.Plugin{})... |
|
||||
+-----------------------------------------------------------------------------------+
|
||||
│
|
||||
▼
|
||||
+-----------------------------------------------------------------------------------+
|
||||
| Wavelet Core (微内核上下文总线) |
|
||||
| - Context (服务树与扩展点总线) - Lifecycle Manager (生命周期编排) |
|
||||
| - Service Hub (泛型 IoC 容器) - EventBus (强类型领域事件总线) |
|
||||
+-----------------------------------------------------------------------------------+
|
||||
│ │
|
||||
▼ 注册与驱动 ▼ 挂载能力
|
||||
+------------------------------------+ +-------------------------------------------+
|
||||
| 运行时驱动插件 (Driver Plugins) | | 业务领域插件 (Domain Plugins) |
|
||||
| - driver-http (Gin Web 引擎) | | - plugin-auth (认证/Session/OAuth) |
|
||||
| - driver-worker (Asynq 消费池) | | - plugin-user (用户资料/角色权限) |
|
||||
| - driver-cron (Asynq 定时调度器) | | - plugin-msg-gateway (消息通道与推送) |
|
||||
| - driver-database (GORM 数据源) | | - plugin-risk-control (访问风控与限流) |
|
||||
| - driver-cache (RAM/Redis 缓存) | | - [下游自定义插件] (业务私有插件) |
|
||||
+------------------------------------+ +-------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 微内核协议契约与设计规范
|
||||
|
||||
### 3.1 插件契约 (`core.Plugin`)
|
||||
所有官方插件与下游自定义插件均实现统一的 `Plugin` 接口：
|
||||
|
||||
```go
|
||||
package core
|
||||
|
||||
import "context"
|
||||
|
||||
// Plugin 插件统一契约
|
||||
type Plugin interface {
|
||||
// Name 插件唯一标识（如 "auth", "database", "message_gateway"）
|
||||
Name() string
|
||||
// Apply 核心装载入口：通过 Context 提供服务、注册路由、声明任务与监听事件
|
||||
Apply(ctx *Context) error
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 运行时驱动契约 (`core.Driver`)
|
||||
HTTP 服务、Worker 消费池、Cron 调度器不硬编码在内核中，而是作为标准 `Driver` 挂载：
|
||||
|
||||
```go
|
||||
package core
|
||||
|
||||
type DriverType string
|
||||
|
||||
const (
|
||||
DriverTypeHTTP DriverType = "http"
|
||||
DriverTypeWorker DriverType = "worker"
|
||||
DriverTypeScheduler DriverType = "schedule"
|
||||
)
|
||||
|
||||
// Driver 是具备事件循环或监听端口的运行时引擎
|
||||
type Driver interface {
|
||||
Type() DriverType
|
||||
Start(ctx context.Context) error
|
||||
Stop(ctx context.Context) error
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 Context 统一服务总线与泛型注入
|
||||
```go
|
||||
package core
|
||||
|
||||
// Provide 向 Context 注册强类型服务实现
|
||||
func Provide[T any](ctx *Context, service T)
|
||||
|
||||
// Inject 从 Context 获取已注册的服务
|
||||
func Inject[T any](ctx *Context) (T, error)
|
||||
|
||||
// Using 声明式依赖注入（当且仅当依赖的服务全部就绪时激活回调）
|
||||
func Using[T1 any](ctx *Context, fn func(s1 T1)) error
|
||||
func Using2[T1, T2 any](ctx *Context, fn func(s1 T1, s2 T2)) error
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 领域扩展点规范 (Domain Extension Points)
|
||||
|
||||
微内核提供 6 大标准扩展点，供插件高内聚地声明自己的资源：
|
||||
|
||||
### 4.1 HTTP 路由扩展 (`ctx.Router()`)
|
||||
```go
|
||||
type RouterExtension interface {
|
||||
Group(relativePath string, handlers ...gin.HandlerFunc) *gin.RouterGroup
|
||||
Use(middleware ...gin.HandlerFunc)
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 数据迁移扩展 (`ctx.Migrations()`)
|
||||
每个插件通过 Go 内置 `embed.FS` 打包专属的 Goose SQL 文件，彻底消除单体大迁移目录的合并冲突：
|
||||
|
||||
```go
|
||||
type MigrationExtension interface {
|
||||
// Register 注册插件专属的 SQL 迁移文件系统
|
||||
Register(pluginID string, fsys fs.FS, dir ...string)
|
||||
}
|
||||
```
|
||||
|
||||
**版本隔离机制**：所有插件共享一张 `w_schema_versions` 表，以 `plugin_id` 列区分。运行时引擎（`gooseEngine`）实现 `goosedb.Store` 接口，对该表执行 `plugin_id` 限定的 CRUD 操作，确保各插件的版本互不干扰。
|
||||
|
||||
```sql
|
||||
w_schema_versions (
|
||||
plugin_id VARCHAR(64) NOT NULL,
|
||||
version_id BIGINT NOT NULL,
|
||||
applied_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
PRIMARY KEY (plugin_id, version_id)
|
||||
)
|
||||
```
|
||||
|
||||
**启动流程**：
|
||||
1. `ApplyPlugins()` 阶段：各插件调用 `ctx.Migrations().Register("order", embedFS)` 收集迁移
|
||||
2. `RunMigrations()` 阶段：引擎遍历所有 `entries`，为每个插件创建 `goose.NewProvider(dialect, sqlDB, entry.FS, goose.WithStore(store))`
|
||||
3. `provider.Up()` 查询 `w_schema_versions WHERE plugin_id = 'order'` 决定版本，执行增量迁移
|
||||
|
||||
### 4.3 异步任务与定时调度扩展 (`ctx.Task()` & `ctx.Schedule()`)
|
||||
```go
|
||||
type TaskExtension interface {
|
||||
Register(taskType string, handler asynq.HandlerFunc)
|
||||
}
|
||||
|
||||
type ScheduleExtension interface {
|
||||
RegisterCron(spec string, taskType string, payload any)
|
||||
}
|
||||
```
|
||||
|
||||
### 4.4 领域事件总线 (`ctx.Events()`)
|
||||
用于跨插件完全解耦通信，单机模式走内存通道，集群模式无缝升级为 Redis Stream / NATS：
|
||||
```go
|
||||
type EventBus interface {
|
||||
On(topic string, handler any)
|
||||
Emit(topic string, payload any) error
|
||||
}
|
||||
```
|
||||
|
||||
### 4.5 动态系统设置扩展 (`ctx.Settings()`)
|
||||
```go
|
||||
type SettingExtension interface {
|
||||
RegisterSchema(pluginID string, schema any)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 插件形态与目录布局规范
|
||||
|
||||
插件结构遵循 **“扁平 (Flat)、自包含 (Self-Contained)、就近组织 (Colocated)”** 原则，杜绝不必要的 DDD 样板代码。
|
||||
|
||||
### 5.1 官方插件目录结构
|
||||
```text
|
||||
plugins/
|
||||
├── database/ # 数据库驱动插件
|
||||
│ ├── plugin.go # 注册 DBService 与连接池
|
||||
│ └── service.go
|
||||
├── auth/ # 认证插件
|
||||
│ ├── plugin.go # 插件装载入口：ctx.Provide[AuthService] + 路由挂载
|
||||
│ ├── service.go # AuthService 接口实现 (登录/Token/Session)
|
||||
│ ├── handlers.go # HTTP Controller
|
||||
│ ├── models.go # GORM 实体定义
|
||||
│ └── migrations/ # 专属 Goose SQL 迁移
|
||||
│ └── 001_auth_init.sql
|
||||
├── message_gateway/ # 消息网关插件
|
||||
│ ├── plugin.go # 路由挂载 + Worker 任务注册
|
||||
│ ├── channels.go # Telegram / QQ / Webhook 各渠道实现
|
||||
│ └── models.go
|
||||
└── [下游自定义插件]/ # 下游业务方自研插件
|
||||
├── plugin.go
|
||||
└── models.go
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 插件间引用关系与协同规范
|
||||
|
||||
为杜绝 Go 语言的 `import cycle not allowed` 错误并保持插件的独立可替换性，插件间交互严格遵循以下 3 大模式：
|
||||
|
||||
1. **服务槽位与延迟绑定（用于跨插件直接调用）**：
|
||||
* 双方互不 import 对方包，仅面向 `core/contracts` 暴露的 Interface 编程。
|
||||
* 运行时通过 `core.Inject[contracts.UserService](ctx)` 获取服务。
|
||||
2. **事件总线广播（用于通知与状态联动）**：
|
||||
* 登录成功、密码修改、订单创建等事件统一通过 `ctx.Events().Emit()` 广播，下游自愿监听。
|
||||
3. **注册表扩展点模式（用于功能插件扩充主插件能力）**：
|
||||
* 主插件向 Context 提供注册表（如 `OAuthProviderRegistry`），扩充插件在 `Apply` 中向注册表添加自己的 Provider 实现。
|
||||
|
||||
---
|
||||
|
||||
## 7. 运行切面与启动路径 (Runtime Profiles)
|
||||
|
||||
CLI 命令仅作为**切面激活器 (Target Selector)**，业务插件无需感知当前的运行角色：
|
||||
|
||||
```
|
||||
[CLI: wavelet api / worker / schedule / all]
|
||||
↓
|
||||
1. App Bootstrap: 加载所有已配置插件并构建 Context
|
||||
↓
|
||||
2. Apply Phase: 执行所有 plugin.Apply(ctx)，收集路由、任务、调度与迁移
|
||||
└─ 各插件调用 ctx.Migrations().Register("auth", authMigrations) 等
|
||||
↓
|
||||
3. Migration Engine: 遍历所有 entries，逐插件创建 Goose Provider 执行迁移
|
||||
└─ 每个插件使用独立的 sharedStore(pluginID)，共享同一张 w_schema_versions 表
|
||||
└─ provider.Up() 检查 w_schema_versions WHERE plugin_id = 'auth'
|
||||
└─ 未执行过 → 执行 00001_initial.sql → INSERT 版本记录
|
||||
└─ 已执行过 → 跳过
|
||||
↓
|
||||
4. Profile Dispatch:
|
||||
- "api": 激活 DriverTypeHTTP 驱动 (Gin.ListenAndServe)
|
||||
- "worker": 激活 DriverTypeWorker 驱动 (Asynq.Run)
|
||||
- "schedule": 激活 DriverTypeScheduler 驱动 (Asynq.Scheduler)
|
||||
- "all": 激活所有 Driver 实例 (单体一键融合启动)
|
||||
↓
|
||||
5. Graceful Shutdown: 监听系统信号，逆序安全停机
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 面向未来 5 年的分布式与服务拆分演进
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph Monolith ["阶段 1：单体插件化 (进程内零开销)"]
|
||||
UserP["plugin-user"] -->|Go Interface 内存调用| AuthP["plugin-auth"]
|
||||
end
|
||||
|
||||
subgraph Distributed ["阶段 2：高并发微服务拆分 (透明代理替换)"]
|
||||
UserP2["plugin-user"] -->|相同的 Go Interface| AuthClient["plugin-auth-client (gRPC 代理)"]
|
||||
AuthClient -.->|gRPC / HTTP/2| RemoteAuth["独立 Auth 微服务集群"]
|
||||
end
|
||||
```
|
||||
|
||||
1. **接口不变性 (Contract Stability)**：所有跨模块调用走 Interface，微服务化拆分时只需引入 RPC 客户端插件替换原插件，调用方业务代码 **0 修改**。
|
||||
2. **分布式事件驱动**：进程内 EventBus 通过简单配置可无缝切换为 Redis Stream / NATS / Kafka。
|
||||
3. **独立数据分片**：每个插件表名自带命名空间（如 `w_auth_*`），且有独立 Migration，天然支持物理分库分表。
|
||||
|
||||
---
|
||||
|
||||
## 9. 渐进式改造实施路线图
|
||||
|
||||
1. **Phase 1: 微内核基础设施搭建 (`core/` & `core/contracts/`)**
|
||||
- 实现 Context、泛型 IoC 容器、生命周期状态机与 6 大扩展点协议。
|
||||
2. **Phase 2: 运行时驱动插件下沉 (`plugins/driver_*`)**
|
||||
- 将现有 Gin、Asynq Worker、Asynq Scheduler、GORM、Redis 封装为标准 Driver 插件。
|
||||
3. **Phase 3: 官方领域模块插件化拆分 (`plugins/domain_*`)**
|
||||
- 依次将 `auth`、`user`、`message_gateway`、`risk_control`、`admin` 迁移为标准插件。
|
||||
4. **Phase 4: 下游工程脚手架与验证**
|
||||
- 提供下游开发模板，编写示例自定义插件，端到端验证 API/Worker/Schedule 运行切面与测试覆盖。
|
||||
@@ -1,82 +0,0 @@
|
||||
# Cordis Architecture Alignment & Refactoring Design
|
||||
|
||||
**Date**: 2026-08-28
|
||||
**Topic**: Cordis Meta-framework Alignment (Spatiotemporal Composability, Revertible Effects, Reactive Coeffects & Boundary Isolation)
|
||||
**Status**: Approved
|
||||
|
||||
---
|
||||
|
||||
## 1. Background & Objectives
|
||||
|
||||
Wavelet adopts the **Cordis** micro-kernel paradigm (originating from Koishi and DeepSeek Harness) to achieve runtime composability and zero-side-effect lifecycle management.
|
||||
According to the formal metatheory of Cordis (*A Programming Paradigm for Spatiotemporal Composability*), the runtime must satisfy two orthogonal requirements:
|
||||
1. **Temporal Composability (时间可组合性)**: Every context mutation/registration must track an inverse operation (Revertible Effects) and automatically roll back in LIFO order upon unloading/disposing.
|
||||
2. **Spatial Composability (空间可组合性)**: Components declare required coeffects/dependencies (`inject`); when dependencies become available or unavailable, the system reactively activates or deactivates components (Fiber state machine), guaranteeing **Confluence (合流)** regardless of registration order.
|
||||
3. **Context as the Sole Surface & Defensive Isolation**: Eliminate cross-plugin private imports and global static singletons (`database.DB()`, global configs), strictly enforcing single-owner boundaries and `contracts` programming.
|
||||
|
||||
---
|
||||
|
||||
## 2. Architecture & Detailed Design
|
||||
|
||||
### 2.1 Revertible Effects & Scoped Extpoints (时间可组合性)
|
||||
|
||||
- **`Context` Scoped Lifetime**:
|
||||
Each plugin instance is mounted with a dedicated child context `pluginCtx := rootCtx.Fork()`.
|
||||
- **Automatic Disposer Registration for Extpoints**:
|
||||
When registrations occur through `pluginCtx`, inverse operations are automatically pushed to `pluginCtx`'s Disposer stack:
|
||||
- **`Router`**: Registering a route returns a definition with an ID; `pluginCtx` records a disposer that calls `router.UnregisterByID(id)`.
|
||||
- **`Events`**: `ctx.Events().On(...)` returns a `Disposer`; when called on a scoped context (or via `ctx.On(...)`), it binds to `pluginCtx.OnDispose`.
|
||||
- **`Tasks`**: Registering an async task binds `tasks.Unregister(taskType)` to `pluginCtx.OnDispose`.
|
||||
- **`Schedules`**: Registering a cron schedule binds `schedules.Unregister(cronName)` to `pluginCtx.OnDispose`.
|
||||
- **`Settings`**: Registering setting schemas binds schema deregistration to `pluginCtx.OnDispose`.
|
||||
- **`Container (Provide)`**: Providing a service type `T` binds `container.remove(T)` to `pluginCtx.OnDispose`.
|
||||
- **LIFO Teardown Guarantee**:
|
||||
Calling `pluginCtx.Dispose()` runs all registered disposers in reverse order (LIFO), cleanly revoking routes, event listeners, tasks, schedules, and service bindings without residual side effects.
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Reactive Coeffects & Fiber Lifecycle (空间可组合性)
|
||||
|
||||
- **Dependency Declaration (`DependentPlugin`)**:
|
||||
Plugins can optionally implement:
|
||||
```go
|
||||
type DependentPlugin interface {
|
||||
Plugin
|
||||
Inject() []reflect.Type
|
||||
}
|
||||
```
|
||||
- **Plugin Fiber State Machine**:
|
||||
```
|
||||
PENDING ──(All dependencies provided)──> LOADING ──(Apply succeeds)──> ACTIVE
|
||||
▲ │
|
||||
└─────────────(Dependency removed / Plugin unloaded)──────────────────────┘
|
||||
```
|
||||
- **States**: `FiberPending`, `FiberLoading`, `FiberActive`, `FiberUnloading`, `FiberDisposed`.
|
||||
- **Reconciler**: When `core.Provide[T]` registers a service or `core.App.Use` registers a plugin, the reconciler checks all pending fibers. Fibers with satisfied dependencies transition `Pending -> Loading -> Active`.
|
||||
- **Confluence**: Plugin registration order (`app.Use(A, B)` vs `app.Use(B, A)`) produces the exact same final active state once all dependencies are satisfied.
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Boundary Defense & Single Owner Enforcement (架构防线)
|
||||
|
||||
- **Eliminate Direct Global Invocations**:
|
||||
- Refactor `plugins/domain/user/repository.go` and other domain repositories to avoid direct `import "Wavelet/plugins/infra/database"` and direct calls to `database.DB(ctx)`.
|
||||
- Inject `contracts.DBService` via repository struct or retrieve via `ctx.DB()`.
|
||||
- **Strict Package Separation**:
|
||||
- `backend/core/`: Micro-kernel, context, container, fiber, events, scoped extpoints.
|
||||
- `backend/core/contracts/`: Public interfaces and shared DTOs/events.
|
||||
- `backend/plugins/infra/`: Infrastructure implementations providing contracts services.
|
||||
- `backend/plugins/drivers/`: Runtime drivers (HTTP, Asynq Worker, Cron).
|
||||
- `backend/plugins/domain/`: Domain business logic and single-owner tables.
|
||||
- `backend/pkg/`: Stateless utilities and algorithm libraries.
|
||||
|
||||
---
|
||||
|
||||
## 3. Verification Plan
|
||||
|
||||
1. **Unit Tests for Core**:
|
||||
- `core/fiber_test.go`: Test fiber state transitions, out-of-order registration confluence, and dynamic unloading.
|
||||
- `core/context_test.go` & `core/extpoints/`: Test automatic scoped disposer tracking for routes, tasks, schedules, and event listeners.
|
||||
2. **Refactoring Verification for Domain Plugins**:
|
||||
- Run `go test ./backend/...` across all domain and infra packages.
|
||||
- Run `make code-check` and verify zero lint regressions.
|
||||
@@ -1,84 +0,0 @@
|
||||
# Cordis 架构重构设计规格书 (Cordis Architecture Refactor Design)
|
||||
|
||||
**日期**: 2026-08-28
|
||||
**目标**: 依据 Cordis 时空可组合性元框架（Spatiotemporal Composability）哲学，重构 Wavelet 后端包结构、包职责与插件边界，消除全局静态单例与跨插件私有实现依赖，实现真正的可逆副作用与契约化隔离。
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与核心设计原则
|
||||
|
||||
Cordis 是一个面向时空可组合性的元框架，核心在于：
|
||||
1. **时间可组合性 (Temporal Composability / Revertible Effects)**：组件挂载到上下文时产生的任何副作用（数据库连接、Redis 客户端、路由、事件监听、定时任务）必须具备明确的逆操作，在卸载时按 LIFO（后进先出）干净撤销。
|
||||
2. **空间可组合性 (Spatial Composability / Reactive Coeffects)**：组件通过 `Inject` 声明依赖；无特权微内核，所有基础设施与业务均以平等插件形态存在；组件之间严格面向抽象服务契约（Contracts）编程，严禁跨包引用私有实现。
|
||||
3. **合流定理 (Confluence)**：任何插件的装载/卸载顺序，静止状态等同于从零静态装配，杜绝全局隐藏状态与启动顺序隐式假设。
|
||||
|
||||
---
|
||||
|
||||
## 2. 详细重构方案
|
||||
|
||||
### 2.1 微内核纯洁化 (`backend/core/`)
|
||||
|
||||
#### 改造点：
|
||||
1. **移除特权辅助方法**：
|
||||
- 从 `backend/core/context.go` 中移除 `func (c *Context) DB() contracts.DBService` 与 `func (c *Context) Cache() contracts.CacheService`。
|
||||
- 所有服务消费方统一面向 `core.Inject[T](ctx)`、`core.MustInject[T](ctx)` 或 `core.Using[T](ctx, ...)`。
|
||||
2. **保持依赖注入纯粹性**：
|
||||
- 内核仅保留：`Context`、`Container`、`Fiber`、`EventBus`、生命周期管理以及通用的扩展点挂载。
|
||||
|
||||
---
|
||||
|
||||
### 2.2 基础设施插件生命周期可逆化 (`backend/plugins/infra/`)
|
||||
|
||||
#### 1. 数据库插件 (`plugins/infra/database`)
|
||||
- **移除隐式副作用**：
|
||||
- 删除 `postgres.go` 与 `sqlite.go` 中的 `func init() { ... }` 静态建连。
|
||||
- 删除包级导出的静态全局变量 `var db *gorm.DB` 以及全局 `DB(ctx)` / `SetDB()`。
|
||||
- **生命周期受控与可逆释放**：
|
||||
- 在 `Plugin.Apply(ctx *core.Context)` 时根据配置建立数据库连接（GORM + underlying `*sql.DB`）。
|
||||
- 创建 `contracts.DBService` 实例并通过 `core.Provide[contracts.DBService](ctx, svc)` 注册。
|
||||
- 注册 `ctx.OnDispose` 逆操作，在插件卸载时调用 `sqlDB.Close()`。
|
||||
|
||||
#### 2. 缓存插件 (`plugins/infra/cache`)
|
||||
- **移除隐式副作用**：
|
||||
- 删除 `redis.go` 中的 `func init() { ... }` 静态建连。
|
||||
- 删除包级导出的全局变量 `var Redis redis.UniversalClient`。
|
||||
- **生命周期受控与可逆释放**：
|
||||
- 在 `Plugin.Apply(ctx *core.Context)` 时初始化 Redis 客户端并构造 `contracts.CacheService`。
|
||||
- 通过 `core.Provide[contracts.CacheService](ctx, svc)` 注册。
|
||||
- 注册 `ctx.OnDispose` 逆操作，在插件卸载时调用 `client.Close()`。
|
||||
|
||||
---
|
||||
|
||||
### 2.3 业务领域插件防线隔离与依赖重构 (`backend/plugins/domain/`)
|
||||
|
||||
#### 1. 消除跨插件私有 Import
|
||||
- 遍历并重构以下 8 个 Domain 插件：
|
||||
- `auth`
|
||||
- `user`
|
||||
- `admin`
|
||||
- `cap`
|
||||
- `message_gateway`
|
||||
- `risk_control`
|
||||
- `system`
|
||||
- `upload`
|
||||
- **规则**：
|
||||
- 严禁任何 domain 插件 `import "Wavelet/plugins/infra/database"` 或 `import "Wavelet/plugins/infra/cache"`。
|
||||
- 严禁任何 domain 插件直接 import 另一个 domain 插件的具体实现包（如 `admin` 严禁 import `risk_control/logstore` 或 `storage/diskcache`）。
|
||||
- 各插件内部的 Repository / Service 统一通过 `core.Inject[contracts.DBService](ctx)` 或插件内部 scoped context 获取数据库连接。
|
||||
|
||||
#### 2. `admin` 插件解耦与全局变量清除
|
||||
- 移除 `admin/plugin.go` 中的包级变量（`globalUserSvc`, `globalAuthSvc`, `globalCoreCtx`）。
|
||||
- 将 `admin` 的日志查询、任务触发、缓存清理等管理接口改造为通过 `contracts` 或 `ctx.Tasks()` 访问，消除对 `risk_control`、`driver_asynq_worker` 等的私有依赖。
|
||||
|
||||
---
|
||||
|
||||
## 3. 验证与门禁标准
|
||||
|
||||
1. **编译与依赖检查**：
|
||||
- 运行 `grep -r "Wavelet/plugins/infra/database" backend/plugins/domain/` 结果为空。
|
||||
- 运行 `grep -r "Wavelet/plugins/infra/cache" backend/plugins/domain/` 结果为空。
|
||||
2. **自动化测试**：
|
||||
- 所有既有单元测试与集成测试（`go test ./...`）无回归，全部 PASS。
|
||||
3. **代码质量门禁**：
|
||||
- `make code-check` 静态检查 0 告警通过。
|
||||
- `make format` 格式化通过。
|
||||
@@ -1,128 +0,0 @@
|
||||
# Cordis 架构插件标准分层设计规范 (Plugin Layered Architecture Spec)
|
||||
|
||||
- **文档状态**: 已敲定 (Approved)
|
||||
- **版本**: v1.1.0 (2026-08-28)
|
||||
- **适用范围**: Wavelet 官方插件 (`backend/plugins/`)、下游定制插件 (`downstream/custom_plugins/`)
|
||||
|
||||
---
|
||||
|
||||
## 1. 架构总览与统一标准规范 (Architecture & Unified Standard Spec)
|
||||
|
||||
在 Wavelet 的 Cordis 微内核架构中，系统通过 **微内核 (`core/`) + 服务契约 (`core/contracts/`) + 自包含插件 (`plugins/` 及 `downstream/plugins/`)** 实现高度解耦与单向依赖。
|
||||
所有插件统一以 [`backend/downstream/plugins/custom_example`](file:///Users/ryan/Code/Go/Wavelet/backend/downstream/plugins/custom_example) 为基准模板，严格遵循物理子包隔离的分层架构（`controller -> service -> dao -> model`）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 统一标准分层目录结构 (以 `custom_example` 为基准)
|
||||
|
||||
```text
|
||||
backend/downstream/plugins/custom_example/ (或 backend/plugins/domain/<plugin_name>/)
|
||||
├── plugin.go # [插件根入口] 实现 core.Plugin，装配各子包并向 Cordis 注册
|
||||
│
|
||||
├── consts/ # package consts：常量与模块内部错误码定义
|
||||
│ └── consts.go
|
||||
│
|
||||
├── controller/ # package controller：HTTP API 接入层 (参数绑定、会话获取、统一信封响应)
|
||||
│ └── hello/ # 业务分组/实体子包
|
||||
│ └── hello.go # 接口处理 Handler（直接以业务命名，禁止 controller_hello.go）
|
||||
│
|
||||
├── service/ # package service：核心业务用例层 (业务用例、事务编排、事件发布)
|
||||
│ └── hello.go # 业务用例实现（纯 Go 逻辑，禁止依赖 *gin.Context）
|
||||
│
|
||||
├── dao/ # package dao：数据持久化访问层 DAL (GORM CRUD、SQL 转义防注入)
|
||||
│ └── hello.go # 数据访问实现（直接以业务命名，禁止 dao_hello.go）
|
||||
│
|
||||
├── model/ # package model：纯数据实体与传输对象 (零 Web/数据库框架依赖)
|
||||
│ ├── entity/ # 数据库映射实体 (TableName() 必须带 w_<plugin>_ 前缀)
|
||||
│ │ └── hello.go
|
||||
│ └── do/ # 领域对象、请求 Request DTO 与响应 Response DTO
|
||||
│ └── hello.go
|
||||
│
|
||||
└── migrations/ # Goose SQL 独立迁移嵌入目录 (//go:embed)
|
||||
├── postgres/ # PostgreSQL 专属迁移 SQL
|
||||
│ └── 20260901000001_init.sql
|
||||
└── sqlite/ # SQLite 专属迁移 SQL
|
||||
└── 20260901000001_init.sql
|
||||
```
|
||||
|
||||
> ⚠️ **严禁规则**：严禁在插件根目录下平铺 `handlers_*.go`、`service_*.go`、`dao_*.go` 等前缀文件，子包内文件直接按业务实体命名。严格约束 `controller -> service -> dao -> model` 单向依赖。
|
||||
│ ├── auth.go # 认证业务逻辑（直接命名为 auth.go，禁止 service_auth.go）
|
||||
│ ├── user.go # 用户业务逻辑（直接命名为 user.go，禁止 service_user.go）
|
||||
│ ├── config.go # 配置业务逻辑（直接命名为 config.go，禁止 service_config.go）
|
||||
│ └── logs.go # 日志业务逻辑（直接命名为 logs.go，禁止 service_logs.go）
|
||||
│
|
||||
├── repository/ # package repository：数据访问持久化层 (DAL)
|
||||
│ ├── repository.go # 仓储通用方法与工厂
|
||||
│ ├── user.go # 用户仓储实现（直接命名为 user.go，禁止 repository_user.go）
|
||||
│ ├── config.go # 配置仓储实现（直接命名为 config.go，禁止 repository_config.go）
|
||||
│ └── log.go # 日志仓储实现（直接命名为 log.go，禁止 repository_log.go）
|
||||
│
|
||||
├── model/ # package model (或 models/)：纯领域实体与传输对象
|
||||
│ ├── entity.go # 数据库映射实体 (TableName() 必须带 w_<plugin>_ 前缀)
|
||||
│ ├── dto.go # 请求入参与响应出参 DTO
|
||||
│ └── events.go # 插件内部/广播事件结构体定义
|
||||
│
|
||||
├── errs/ # package errs：错误常量与错误码定义 (或根目录 errs.go)
|
||||
│ └── errs.go
|
||||
│
|
||||
└── migrations/ # Goose SQL 独立迁移嵌入文件 (//go:embed)
|
||||
└── 20260828000001_init_<plugin_name>.sql
|
||||
```
|
||||
|
||||
### 3.2 依赖方向约束 (Strict Dependency Flow)
|
||||
```mermaid
|
||||
graph TD
|
||||
Plugin[plugin.go 入口] --> Handler[handler/ 接入层]
|
||||
Plugin --> Service[service/ 业务层]
|
||||
Plugin --> Repository[repository/ 仓储层]
|
||||
Handler --> Service
|
||||
Handler --> Model[model/ 实体与DTO]
|
||||
Handler --> Errs[errs/ 错误常量]
|
||||
Service --> Repository
|
||||
Service --> Model
|
||||
Service --> Errs
|
||||
Repository --> Model
|
||||
```
|
||||
* **单向依赖铁律**：
|
||||
1. `handler/` 依赖 `service/`、`model/`、`errs/`；
|
||||
2. `service/` 依赖 `repository/`、`model/`、`errs/`，**严禁 import gin**；
|
||||
3. `repository/` 依赖 `model/` 和数据库底层，**严禁反向依赖 service 或 handler**；
|
||||
4. `model/` 纯粹由 Go 结构体组成，**严禁依赖上层 handler/service/repository**。
|
||||
|
||||
---
|
||||
|
||||
## 4. 各层职责边界与编码守则 (Layer Responsibilities & Guardrails)
|
||||
|
||||
### 4.1 Handler 层 (`handler/`)
|
||||
1. **参数绑定**：使用 `c.ShouldBindJSON` 或 `c.ShouldBindQuery`。
|
||||
2. **上下文提取**：从 `*gin.Context` 提取登录态（如 `oauth.GetCurrentUser(c)`）。
|
||||
3. **调用下游**：调用 Service 方法，禁止直接调用 Repository 或编写 SQL。
|
||||
4. **统一信封响应**：
|
||||
- 成功：`c.JSON(http.StatusOK, response.OK(data))` 或 `response.OKNil()`。
|
||||
- 失败：使用 `backend/pkg/response` 的 `Abort*` 系列函数（如 `AbortBadRequest`、`AbortUnauthorized`、`AbortNotFound`、`AbortInternal`）。
|
||||
5. **Swagger 注释**：每个导出 Handler 必须编写完整的 OpenAPI/Swagger 注解。
|
||||
|
||||
### 4.2 Service 层 (`service/`)
|
||||
1. **纯 Go 逻辑**：第一参数必须为 `ctx context.Context`，返回 `(result, error)`。
|
||||
2. **禁止依赖 Web 框架**：严禁 import `github.com/gin-gonic/gin`，严禁接收 `*gin.Context`，严禁调用 `c.JSON`/`Abort*`。
|
||||
3. **事务编排**：涉及插件内多表原子操作时，通过 `ctx.DB().Transaction(...)` 编排。
|
||||
4. **事件驱动解耦**：跨插件业务通知与状态联动统一通过 `ctx.Events().Emit(...)` 广播领域事件，杜绝直接跨插件调用私有方法。
|
||||
|
||||
### 4.3 Repository 层 (`repository/`)
|
||||
1. **GORM / SQL 操作**：统一接收 `context.Context`，通过 `db.WithContext(ctx)` 操作数据。
|
||||
2. **SQL LIKE 防注入**：所有含用户输入的模糊查询必须调用 `backend/pkg/util.EscapeLike` 并显式声明 `ESCAPE '\\'`。
|
||||
3. **表单一所有者原则**：仅操作本插件所属表（前缀 `w_<plugin>_*`），严禁越权 DML/DDL 其他插件所有表。
|
||||
|
||||
### 4.4 Model 层 (`model/` 或 `models/`)
|
||||
1. **GORM 映射**：显式实现 `TableName() string` 返回带前缀表名。
|
||||
2. **零值对齐**：Go 结构体字段零值必须与数据库默认值匹配。
|
||||
3. **无物理外键**：禁止物理外键约束，显式建立单列/复合索引。
|
||||
|
||||
### 4.5 Plugin 入口 (`plugin.go`)
|
||||
1. 实现 `core.Plugin` 接口（`Name() string` 与 `Apply(ctx *core.Context) error`）。
|
||||
2. 在 `Apply` 中完成：
|
||||
- 依赖注入与解析（`core.Provide` / `core.Inject` / `ctx.Using`）
|
||||
- 路由与中间件声明（`ctx.Router().Group(...)`）
|
||||
- 异步与定时任务注册（`ctx.Task().Register` / `ctx.Schedule().RegisterCron`）
|
||||
- 配置与设置声明（`ctx.Settings().Register` / `ctx.Config().Bind`）
|
||||
- 数据库迁移注册（`ctx.Migrations().Register`）
|
||||
@@ -1,97 +0,0 @@
|
||||
# Zero-Redis Pluggable Architecture Design
|
||||
|
||||
**Date**: 2026-08-28
|
||||
**Topic**: Decoupling Redis via Cordis Pluggable Infrastructure and In-Process Drivers (Zero-Redis Monolith Mode)
|
||||
**Status**: Approved
|
||||
|
||||
---
|
||||
|
||||
## 1. Background & Objectives
|
||||
|
||||
Currently, the Wavelet platform has direct or indirect couplings with Redis across four areas:
|
||||
1. **Cache Layer (`infra/cache`)**: Hardcoded initialization of Redis client and L2 cache lookup.
|
||||
2. **Background Worker & Cron Drivers (`drivers/driver_asynq_*`)**: Asynq requires Redis as message queue and timer broker.
|
||||
3. **Cross-Node Invalidation (Pub/Sub)**: Invalidation messages directly interact with Redis channels.
|
||||
4. **Task Execution Log Stream**: Real-time worker output writes directly to Redis pipelines in `admin/repository.go`.
|
||||
|
||||
**Goal**:
|
||||
In accordance with Cordis's "Everything is a Plugin" and "Single Owner Principle", extract Redis into dedicated optional plugins and provide lightweight in-process equivalents (`cache_memory`, `driver_inproc_worker`, `driver_inproc_cron`) so that standalone monolith deployments, embedded scenarios, and local development can run with zero external Redis dependency.
|
||||
|
||||
---
|
||||
|
||||
## 2. Architecture & Detailed Design
|
||||
|
||||
### 2.1 Cache Infrastructure Split (`backend/plugins/infra/`)
|
||||
|
||||
`contracts.CacheService` remains the sole contract for caching. Two alternative plugins implement this contract:
|
||||
|
||||
1. **`plugins/infra/cache_memory` (Default for Monolith / Zero-Redis)**:
|
||||
- Encapsulates `pkg/cache/ram` for fast in-process TTL caching.
|
||||
- Cache invalidations emit `cache:invalidate` events via `ctx.Events()` locally.
|
||||
- Provides `core.Provide[contracts.CacheService](ctx, memCacheSvc)`.
|
||||
2. **`plugins/infra/cache_redis` (Distributed Cluster Mode)**:
|
||||
- Provides full multi-tier caching: L1 Local RAM + L2 Remote Redis + Redis Pub/Sub invalidation.
|
||||
- Implements `core.DependentPlugin` (declares dependencies on database / configuration).
|
||||
- Provides `core.Provide[contracts.CacheService](ctx, redisCacheSvc)`.
|
||||
|
||||
---
|
||||
|
||||
### 2.2 In-Process Worker & Scheduler Drivers (`backend/plugins/drivers/`)
|
||||
|
||||
Domain plugins register tasks and schedules only against `ctx.Tasks()` and `ctx.Schedules()` extension points, completely oblivious to the underlying runner.
|
||||
|
||||
1. **`plugins/drivers/driver_inproc_worker` (In-Process Worker Driver)**:
|
||||
- Implements `core.Driver` with `Type() == core.DriverTypeWorker`.
|
||||
- Maintains an in-memory buffered channel queue and worker goroutine pool (managed via `util.Go` with panic recovery).
|
||||
- Supports task concurrency limits, exponential backoff retries, and context execution timeouts.
|
||||
2. **`plugins/drivers/driver_inproc_cron` (In-Process Cron Scheduler Driver)**:
|
||||
- Implements `core.Driver` with `Type() == core.DriverTypeScheduler`.
|
||||
- Uses `robfig/cron/v3` to poll and trigger entries in `ctx.Schedules().Schedules()`.
|
||||
3. **`plugins/drivers/driver_asynq_*` (Distributed Cluster Drivers)**:
|
||||
- Retains Asynq worker and cron drivers for Redis-backed distributed workloads.
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Task Execution Log Stream & Event Bus Decoupling
|
||||
|
||||
1. **Task Stream Logs**:
|
||||
- Provide an in-memory `RingBuffer` (e.g. recent 500 lines per execution).
|
||||
- When Redis is disabled, logs stream into the `RingBuffer` and flush to `w_task_executions` upon completion.
|
||||
2. **System Config & Invalidation Broadcast**:
|
||||
- In single-node mode, `ctx.Events()` in-process event bus handles all notifications immediately.
|
||||
- In multi-node mode, `cache_redis` bridges events across instances via Redis Pub/Sub.
|
||||
|
||||
---
|
||||
|
||||
### 2.4 Application Assembly (`backend/cmd/app.go`)
|
||||
|
||||
In `cmd/app.go`, the application declaratively selects the plugin suite based on configuration:
|
||||
|
||||
```go
|
||||
if config.Config.Redis.Enabled {
|
||||
app.Use(
|
||||
cache_redis.New(),
|
||||
driver_asynq_worker.New(),
|
||||
driver_asynq_cron.New(),
|
||||
)
|
||||
} else {
|
||||
app.Use(
|
||||
cache_memory.New(),
|
||||
driver_inproc_worker.New(),
|
||||
driver_inproc_cron.New(),
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Verification Plan
|
||||
|
||||
1. **Unit Tests**:
|
||||
- `plugins/infra/cache_memory/plugin_test.go`: Test in-memory cache operations, TTL expiry, and `contracts.CacheService` compliance.
|
||||
- `plugins/drivers/driver_inproc_worker/plugin_test.go`: Test in-process task dispatch, concurrency, retry, and cancellation.
|
||||
- `plugins/drivers/driver_inproc_cron/plugin_test.go`: Test in-process cron schedule execution.
|
||||
2. **Integration Verification**:
|
||||
- Verify that running the application with `config.Database.Enabled = false` and `config.Redis.Enabled = false` boots cleanly into `all`, `api`, `worker`, and `scheduler` profiles with zero connection errors.
|
||||
3. **Quality Gate**:
|
||||
- Run `go test ./...`, `make code-check`, and `make format`.
|
||||
@@ -1,364 +0,0 @@
|
||||
# Cordis 配置扩展点设计 (Config Extension Point)
|
||||
|
||||
- **文档状态**: 已敲定 (Approved)
|
||||
- **版本**: v1.0.0 (2026-08-29)
|
||||
- **适用范围**: `backend/core/`(微内核)、`backend/plugins/`(自包含插件)、`backend/cmd/`(组合根)、`backend/pkg/`(无状态基础库)
|
||||
|
||||
---
|
||||
|
||||
## 0. 背景与动机
|
||||
|
||||
`backend/pkg/config` 同时承担了三件事：viper 装载 `config.yaml`、环境变量覆盖、以及以全局单例 `config.Config` 暴露全量配置模型。它与架构文档对 `backend/pkg/` 的定位（"Stateless utilities and algorithm libraries"）冲突，并且带来两个结构性问题：
|
||||
|
||||
1. **配置所有权倒挂**：任何包都能读到全量配置，因此 `cmd` 直接替 `cache` 插件判断 Redis 是否启用、`risk_control` 直接判断 `clickhouse.enabled`。配置的"读者"与"所有者"没有关系约束。
|
||||
2. **隐式全局状态**：`init()` 内完成文件搜索、解析与 `log.Fatalf`，并以 `isTest()` 猜测执行上下文来禁用数据库/Redis/ClickHouse；测试通过改写全局单例驱动生产代码路径。
|
||||
|
||||
本设计把"配置的读取框架"下沉为内核扩展点，把"读哪些字段"的所有权交给各插件自己声明，并一次性迁移全部 27 个消费文件（109 处引用），彻底删除全局单例。
|
||||
|
||||
`AGENTS.md` 与 `new-setting` skill 中早已写明插件应通过 `ctx.Config().Bind(...)` 绑定静态配置，但该 API 在代码中从未存在——本设计同时修正这一文档漂移。
|
||||
|
||||
---
|
||||
|
||||
## 1. 决策记录
|
||||
|
||||
| # | 决策 | 理由与取舍 |
|
||||
| :--- | :--- | :--- |
|
||||
| D1 | **预声明阶段 + 配置门禁** | 内核在 `Apply` 之前收集声明并求值门禁，使组合根不再跨插件读配置选实现。代价是给 Fiber 增加"被门禁跳过"语义。 |
|
||||
| D2 | **混合读取形态：结构体 `Bind` + 泛型 `Get`** | `redis`/`database` 等 14+ 字段结构体整体消费，逐 key 声明不可读；`app.session_secret` 等单字段不值得为它绑一个结构体。 |
|
||||
| D3 | **共享声明 + 内核冲突校验** | 配置是进程级只读事实，不存在数据表那种写竞争，因此允许读者各自声明同一 key；由内核强制"重复声明必须一致"兜底。放弃严格单所有权（需为若干配置值另造契约接口，且 `driver_http` 需 session store 连接参数是真实底层依赖）。 |
|
||||
| D4 | **一次性全量迁移** | 不留双轨，架构一次到位；接受较大的 diff。 |
|
||||
| D5 | **显式测试缝** | 删除 `isTest()` 魔法，测试通过 `core.WithConfigValues(...)` 注入。放弃"测试环境自动禁用中间件"的安全网，换取语义透明与可并行。 |
|
||||
| D6 | **内核持抽象，viper 归 infra 适配器** | 微内核防线规定 `core/` 严禁 import 具体运行时依赖。`core` 只依赖 `ConfigSource` 接口，viper/yaml 装载放 `plugins/infra/config`。放弃"全放 core/config"（污染内核纯净性）与"完全插件化 + `contracts.ConfigService`"（门禁求值在 core，而 config 插件 `Apply` 尚未运行，存在鸡生蛋时序问题）。 |
|
||||
| D7 | **顺带解耦 `pkg/idgen`** | 其 `init()` 读全局配置，导致 `pkg` 反向依赖配置单例。 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 分层与物理结构
|
||||
|
||||
```text
|
||||
backend/core/extpoints/config.go # 配置引擎（仅 stdlib + reflect）：
|
||||
# ConfigSource 接口、声明注册、解析、冲突校验、脱敏 dump
|
||||
backend/core/config.go # 泛型读取入口与 App 装配选项（Go 方法不支持类型参数）
|
||||
backend/core/fiber.go # 新增 FiberSkipped 状态与门禁求值
|
||||
backend/core/types.go # 新增 ConfigExtension / ConfigBinding / ConfigView 别名
|
||||
backend/plugins/infra/config/ # viper + yaml 适配器，实现 core.ConfigSource（非 core.Plugin）
|
||||
backend/cmd/ # 组合根：host 声明集 + app.Prepare()
|
||||
backend/pkg/idgen/ # 移除 config 依赖，改为显式 Init(nodeID)
|
||||
删除 backend/pkg/config/ # 全局单例 config.Config 一并消失
|
||||
```
|
||||
|
||||
职责边界：
|
||||
|
||||
| 单元 | 做什么 | 不做什么 |
|
||||
| :--- | :--- | :--- |
|
||||
| `core/extpoints` 配置引擎 | 维护 key 注册表、按优先级解析、类型转换、冲突校验、脱敏输出 | 不知道任何具体 key 的名字，不读文件，不 import viper |
|
||||
| `plugins/infra/config` | 定位 `config.yaml`（`CONFIG_PATH` → 向上查找）、解析成 raw map、代理 env 查询 | 不含 schema、不含业务字段语义 |
|
||||
| 各插件 | 声明自己读哪些字段（tag 结构体）、声明门禁谓词 | 不读未声明的 key、不访问他插件的声明类型 |
|
||||
| `cmd` | 声明 host 级 key、注入 `ConfigSource`、按已解析值初始化 logger/trace/banner | 不做 `if redis.enabled { ... }` 这类跨插件判断 |
|
||||
|
||||
`plugins/infra/config` 不实现 `core.Plugin`，不出现在 `app.Use()` 列表里：它只向内核提供一个 `ConfigSource` 实例，没有服务、路由或任务可注册。它归 `plugins/infra/` 而非 `pkg/`，是因为它封装了具体运行时依赖（viper、文件系统）并持有装载状态，不符合 `pkg/` 的无状态定位。
|
||||
|
||||
`pkg/idgen` 解耦后，`backend/pkg/` 恢复"不依赖配置源"的无状态定位。
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心类型与 API
|
||||
|
||||
### 3.1 声明形态：带 tag 的结构体
|
||||
|
||||
唯一的批量作者形态是结构体 tag，一个字段同时表达 yaml 路径、env 覆盖名、默认值与敏感标记：
|
||||
|
||||
```go
|
||||
// plugins/infra/cache/redis_config.go —— redis 配置由 redis 插件自己声明
|
||||
type redisConfig struct {
|
||||
Enabled bool `config:"enabled" env:"REDIS_ENABLED" default:"false" autoEnable:"REDIS_ADDR"`
|
||||
Addrs []string `config:"addrs" env:"REDIS_ADDR"`
|
||||
Username string `config:"username" env:"REDIS_USERNAME"`
|
||||
Password string `config:"password" env:"REDIS_PASSWORD" secret:"true"`
|
||||
DB int `config:"db" env:"REDIS_DB"`
|
||||
ClusterMode bool `config:"cluster_mode" env:"REDIS_CLUSTER_MODE"`
|
||||
MasterName string `config:"master_name" env:"REDIS_MASTER_NAME"`
|
||||
KeyPrefix string `config:"key_prefix" env:"REDIS_KEY_PREFIX"`
|
||||
MaintNotifications bool `config:"maint_notifications" env:"REDIS_MAINT_NOTIFICATIONS" default:"false"`
|
||||
// ...pool/timeout 字段略
|
||||
}
|
||||
```
|
||||
|
||||
支持的 tag：`config`（yaml 相对路径，必填）、`env`（覆盖用环境变量名）、`default`（字符串形式，缺省时视为未设置）、`autoEnable`（该 env 一旦存在即把本布尔字段置 true）、`secret`（dump 时脱敏）。
|
||||
|
||||
### 3.2 内核接口
|
||||
|
||||
```go
|
||||
// ConfigSource 抽象了"原始值从哪来"，由 infra 适配器实现，使内核不绑定 viper。
|
||||
type ConfigSource interface {
|
||||
Lookup(path string) (any, bool) // config.yaml 中的点分路径
|
||||
LookupEnv(name string) (string, bool)
|
||||
Describe() string // 用于日志，如 "config.yaml" 或 "<env only>"
|
||||
}
|
||||
|
||||
// ConfigBinding 把一个结构体绑定到某个 yaml 前缀上，是插件的声明单元。
|
||||
type ConfigBinding struct {
|
||||
Prefix string // "redis"；空串表示字段 key 即完整路径
|
||||
Target any // 指向带 tag 的结构体的指针
|
||||
}
|
||||
|
||||
// ConfigView 是只读的已解析视图，供门禁与零散取值使用。
|
||||
type ConfigView interface {
|
||||
String(key, fallback string) string
|
||||
Bool(key string, fallback bool) bool
|
||||
Int(key string, fallback int) int
|
||||
Duration(key string, fallback time.Duration) time.Duration
|
||||
Strings(key string) []string
|
||||
WasSet(envName string) bool
|
||||
Source(key string) string // "env" | "yaml" | "default"，用于诊断
|
||||
}
|
||||
|
||||
// ConfigExtension 是挂载在 Context 上的扩展点，根 Context 与所有 Fork 共享。
|
||||
type ConfigExtension interface {
|
||||
ConfigView
|
||||
Declare(pluginID string, bindings ...ConfigBinding) error
|
||||
Bind(prefix string, target any) error
|
||||
Entries() []ConfigEntry // 有效配置的脱敏视图
|
||||
}
|
||||
```
|
||||
|
||||
`core` 侧导出别名与泛型入口（沿用仓库既有 `core.Provide[T]` / `core.Inject[T]` 风格）：
|
||||
|
||||
```go
|
||||
func ConfigGet[T any](v extpoints.ConfigView, key string) (T, error)
|
||||
```
|
||||
|
||||
### 3.3 插件侧用法
|
||||
|
||||
```go
|
||||
// 批量绑定（Apply 内）
|
||||
var cfg redisConfig
|
||||
if err := ctx.Config().Bind("redis", &cfg); err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
// 单字段读取：带 fallback 的访问器（门禁使用）
|
||||
secret := ctx.Config().String("app.session_secret", "")
|
||||
|
||||
// 单字段读取：需要区分"未设置"与"设置为零值"时用泛型入口
|
||||
rate, err := core.ConfigGet[float64](ctx.Config(), "otel.sampling_rate")
|
||||
```
|
||||
|
||||
`ConfigEntry` 是 `Entries()` 返回的诊断单元，只含元数据与脱敏后的值：
|
||||
|
||||
```go
|
||||
type ConfigEntry struct {
|
||||
Key string // "redis.password"
|
||||
PluginID string // 首次声明者，用于冲突报错点名
|
||||
Env string
|
||||
Source string // "env" | "yaml" | "default"
|
||||
Value string // secret key 输出 "******"
|
||||
}
|
||||
```
|
||||
|
||||
`Bind` 的双重语义：若该 prefix 尚未声明，则按 `Target` 的 tag 自登记；若已声明，则是纯读取。登记时提供的 `env`/`default`/`secret` 元数据一律参与冲突校验（依 D3），因此自登记不会绕过校验。**只有需要早于 `Apply` 求值的插件才必须显式 `DeclareConfig()`。**
|
||||
|
||||
### 3.4 门禁接口与 Fiber 跳过态
|
||||
|
||||
```go
|
||||
// ConfigGatedPlugin 是可选接口：让内核在 Apply 之前决定插件是否激活。
|
||||
type ConfigGatedPlugin interface {
|
||||
Plugin
|
||||
DeclareConfig() []extpoints.ConfigBinding // 门禁所需 key 必须提前声明
|
||||
ConfigEnabled(v extpoints.ConfigView) bool
|
||||
}
|
||||
```
|
||||
|
||||
`FiberState` 新增 `FiberSkipped`。`App.reconcileLocked()` 在 `Load()` 前求值门禁：门禁为 false 的 Fiber 置 `FiberSkipped`，不计入依赖 satisfied 判定，也不参与 driver 启动。`App.Stop()` 对 skipped 与 active 一视同仁地按 LIFO 卸载其 scoped Context。
|
||||
|
||||
受门禁的插件对（现状仅三对，均为 Redis 存在与否的互斥实现）：
|
||||
|
||||
| 启用 | 跳过 | 门禁谓词 |
|
||||
| :--- | :--- | :--- |
|
||||
| `infra/cache` | `infra/cache_memory` | `redis.enabled` |
|
||||
| `drivers/driver_asynq_worker` | `drivers/driver_inproc_worker` | `redis.enabled` |
|
||||
| `drivers/driver_asynq_cron` | `drivers/driver_inproc_cron` | `redis.enabled` |
|
||||
|
||||
### 3.5 组合根
|
||||
|
||||
```go
|
||||
src := config.NewSource() // plugins/infra/config：仅定位与 raw 解析
|
||||
app := core.NewApp(
|
||||
core.WithProfile(profile),
|
||||
core.WithConfigSource(src),
|
||||
core.WithConfigDecl(hostBinding...), // app.* / log.* / otel.*
|
||||
)
|
||||
app.Use(
|
||||
infradb.New(), logger.New(), storage.New(),
|
||||
cache.New(), cache_memory.New(), // 不再 if/else，门禁决定
|
||||
driver_asynq_worker.New(), driver_inproc_worker.New(),
|
||||
driver_asynq_cron.New(), driver_inproc_cron.New(),
|
||||
admin.New(), user.New(), auth.New(), /* ... */
|
||||
driver_http.New(), // addr 由插件自己声明读取
|
||||
)
|
||||
if err := app.Prepare(); err != nil { return err } // 解析屏障 + 门禁求值
|
||||
|
||||
timeout, _ := app.Context().Config().Duration("app.graceful_shutdown_timeout", 30)
|
||||
app.SetShutdownTimeout(timeout)
|
||||
```
|
||||
|
||||
`WithShutdownTimeout(d)` 保留为显式覆盖入口（测试与非标准装配使用），生产路径改为 `Prepare()` 之后由已解析视图经 `SetShutdownTimeout` 设定。`driver_http.New(WithAddr(...))` 选项删除，addr 归 `driver_http` 在 `Apply` 内声明读取。
|
||||
|
||||
---
|
||||
|
||||
## 4. 解析语义与启动时序
|
||||
|
||||
### 4.1 单 key 优先级链
|
||||
|
||||
```text
|
||||
1. 显式 env 命中 env:"DB_ENABLED" → 最高优先级
|
||||
2. autoEnable env 命中 autoEnable:"DB_HOST" → true（被 1 覆盖）
|
||||
3. config.yaml 命中 config:"enabled"
|
||||
4. default tag 兜底
|
||||
```
|
||||
|
||||
需要保留的既有特殊语义：
|
||||
|
||||
- **标量 env 填充切片字段**：`REDIS_ADDR=redis:6379` → `redis.addrs = ["redis:6379"]`；`CLICKHOUSE_HOST` 同理。
|
||||
- **隐式启用**：`DB_HOST` → `database.enabled=true`、`REDIS_ADDR` → `redis.enabled=true`、`CLICKHOUSE_HOST` → `clickhouse.enabled=true`；显式 `*_ENABLED` 始终优先于隐式推导。
|
||||
- **同一 env 的双重角色**：`REDIS_ADDR` 既是 `redis.addrs` 的值来源，又是 `redis.enabled` 的 `autoEnable` 触发器。引擎按 key 独立解析、允许一个 env 名服务多个 key，实现时不可把它建模成"env → 单一 key"的一对一映射。
|
||||
- **时长字段**：`slow_threshold: 200ms` 解析为 `time.Duration`。
|
||||
- **文件定位**：`CONFIG_PATH` 优先；否则从工作目录向上最多 5 层查找 `config.yaml`（该文件位于仓库根，`backend/` 为其子目录）。
|
||||
|
||||
### 4.2 时序
|
||||
|
||||
```text
|
||||
config.NewSource() # 读 yaml → raw map；零 schema 知识
|
||||
↓
|
||||
core.NewApp(WithConfigSource) # 记录 host 声明
|
||||
↓
|
||||
app.Use(...) # 遇 DeclareConfig() 立即登记 binding（叶子 key + env + default + secret）
|
||||
↓
|
||||
app.Prepare() # ① 冲突校验 ② 逐 key 解析 ③ 脱敏 dump ④ 门禁求值 → FiberSkipped
|
||||
↓
|
||||
app.Run() → Reconcile/Apply # 插件内 Bind/Get 读取已解析值
|
||||
```
|
||||
|
||||
`App.Start()` 在未显式调用 `Prepare()` 时幂等补做，防止遗漏。冲突校验规则：同一 key 的多份声明必须 `env` 名、`default`、`secret` 三项一致，否则 `Prepare()` 返回错误并点名两个声明者。
|
||||
|
||||
### 4.3 有意的行为变更
|
||||
|
||||
| # | 变更 | 现状 | 变更后 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| C1 | `default` 生效条件 | `applyDefaults` 对零值二次回落（`session_age<=0` → 86400） | 仅当 env 与 yaml 均缺失时生效；`app.session_age<=0` 在 `Prepare()` 判为配置错误（fail fast 优于静默改写） |
|
||||
| C2 | 测试上下文 | `isTest()` 自动禁用 DB/Redis/ClickHouse 并把 sqlite 指向 `:memory:` | 删除该魔法；测试用 `core.WithConfigValues(...)` 显式声明。未声明 `database.enabled` 时按 default `false` 落 sqlite 后备，其路径沿用 `postgres.go` 既有的 `./data/wavelet.db` 回落——需要内存库的用例必须显式注入 `database.sqlite_path = ":memory:"` |
|
||||
| C3 | 配置 dump | `printConfig` 明文打印全量结构体，含 `DB_PASSWORD`、`APP_SESSION_SECRET` | 按 `secret:"true"` 脱敏后输出，并标注每个 key 的来源（env/yaml/default） |
|
||||
| C4 | 队列默认值 | 硬编码在 `pkg/config` 的 `applyEnvOverrides` | 移入唯一消费者 `driver_asynq_worker` 的声明（`webhook`/`whitelist_only`/`default` 三级优先级不变） |
|
||||
| C5 | 非法 env 值 | `envInt/envBool/envFloat64` 在 `strconv` 失败时静默丢弃 env 值、回落 yaml/default | `Prepare()` 返回 `ErrConfigType` 并点名 key 与非法值 |
|
||||
|
||||
除此之外，解析结果与现状逐 key 等价（由 §7.1 第 4 条的对拍测试证明）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 声明归属映射
|
||||
|
||||
| 声明方 | key 前缀 | 消费者（含跨插件读） |
|
||||
| :--- | :--- | :--- |
|
||||
| `cmd` host 声明集 | `app.{env,app_name,addr,node_id,graceful_shutdown_timeout}`、`log.*`、`otel.*` | `cmd/root.go`、`cmd/banner.go`、`core.App` |
|
||||
| `plugins/infra/cache` | `redis.*`（含 `enabled` 门禁、`autoEnable: REDIS_ADDR`） | `infra/cache`、`driver_http`(session store)、`driver_asynq_worker`、`driver_asynq_cron` |
|
||||
| `plugins/infra/database` | `database.*`、`clickhouse.*` | `infra/database`、`admin`、`risk_control` |
|
||||
| `plugins/domain/auth` | `app.session_*`（cookie/secret/age/domain/secure/http_only） | `auth`、`cap`、`message_gateway`、`driver_http` |
|
||||
| `plugins/drivers/driver_asynq_worker` | `worker.*`（并发、strict_priority、queues 默认值） | 自身 |
|
||||
| 其余 | 按需就近声明 | — |
|
||||
|
||||
跨插件读同一 key（如 `cap` 读 auth 声明的 `app.session_secret`）依 D3 走共享声明：`cap` 也声明该 key，三份元数据必须与 auth 一致，否则启动失败。
|
||||
|
||||
**Key 命名约定**：既有 infra key 保持顶层（`redis.*`、`database.*`），以兼容线上 `config.yaml`；新增插件的私有配置归 `plugins.<name>.*` 命名空间，与 `new-setting` skill 的描述对齐。
|
||||
|
||||
### 5.1 `pkg/idgen` 解耦
|
||||
|
||||
- 删除 `init()` 中对 `config.Config.App.NodeID` 的读取。
|
||||
- 新增 `idgen.Init(nodeID int64) error`，由 host 在 `Prepare()` 之后显式调用（值来自 host 声明的 `app.node_id`）。
|
||||
- 未初始化时 `NextUint64ID()` panic 并点名"未调用 idgen.Init"，而非静默使用 nodeID=0 生成可能与集群冲突的 ID。
|
||||
- 11 个调用点的 `idgen.NextUint64ID()` 签名保持不变；依赖 ID 生成的测试需显式 `idgen.Init`。这是本次迁移唯一会触及既有测试文件之处。
|
||||
|
||||
### 5.2 明确不在范围内
|
||||
|
||||
本设计只改变配置的**来源与所有权**，不动这些既有全局变量：`cache.Redis`、`driver_asynq_worker.RedisOpt`/`AsynqClient`、`infra/database.db`。它们各自的收敛属于独立议题。
|
||||
|
||||
---
|
||||
|
||||
## 6. 错误处理
|
||||
|
||||
- `Prepare()` 以 `errors.Join` 聚合全部配置错误，哨兵错误：`ErrConfigConflict`（重复声明不一致）、`ErrConfigType`（env 值无法转为目标类型）、`ErrConfigInvalid`（值域校验失败，如 `session_age<=0`）、`ErrConfigNotResolved`（`Prepare()` 之前调用 `Bind`/`Get`，错误信息点名正确调用顺序）。
|
||||
- 所有配置错误经 `error` 返回，由 `cmd` 决定终止方式；`core` 与 `extpoints` 内不再有 `log.Fatalf`。
|
||||
- `config.yaml` 缺失不是错误（沿用"仅用 env"路径，记一条 info 日志）；`CONFIG_PATH` 显式指定但读不到或解析失败 → 返回 error。
|
||||
- 门禁 `ConfigEnabled(v ConfigView) bool` 只读已解析值、用带 fallback 的访问器，配置错误已在 `Prepare()` 阶段暴露，因此门禁不引入新的错误源。
|
||||
- `Declare` 与 `Bind` 校验 `Target` 必须是非 nil 结构体指针，否则返回 error（不 panic）。
|
||||
|
||||
---
|
||||
|
||||
## 7. 测试与验收
|
||||
|
||||
### 7.1 测试分层
|
||||
|
||||
1. **引擎单测**（`core/extpoints`）：内存 fake `ConfigSource`，表驱动覆盖优先级四档、标量 env→切片、`autoEnable` 与显式 env 的优先关系、冲突校验、脱敏 dump、`time.Duration` 与嵌套结构体 tag 解析、`Prepare()` 前访问的错误路径。
|
||||
2. **门禁单测**（`core`）：互斥插件对恰好激活一个、被跳过插件不计入依赖 satisfied、`FiberSkipped` 参与 `Stop` 的 LIFO 卸载。
|
||||
3. **适配器单测**（`plugins/infra/config`）：`t.TempDir()` 写 yaml + `t.Setenv`，禁止相对路径。
|
||||
4. **新旧对拍**：迁移期间保留一份临时对拍测试，用仓库现网 `config.yaml` 与 `.env` 逐 key 比较旧 `pkg/config` 与新引擎的输出，证明除 C1–C5 外完全等价；验证通过后随旧包一并删除。
|
||||
5. **迁移后插件测试**：改用 `core.WithConfigValues(...)` 显式注入；依赖 ID 生成的测试显式 `idgen.Init`。
|
||||
|
||||
### 7.2 验收标准
|
||||
|
||||
1. `backend/pkg/config` 不存在，`grep -rn "pkg/config\|config\.Config" backend/` 零命中。
|
||||
2. `core/` 无 viper import；`backend/pkg/` 内不出现任何配置源 import。
|
||||
3. `cmd/app.go` 中不存在跨插件配置判断，驱动选型完全由门禁产生。
|
||||
4. `.env`、`config.yaml`、docker-compose **零改动**即可启动，行为等价（除已登记的 C1–C5）。
|
||||
5. 同时挂载 `cache` 与 `cache_memory` 而仅激活其一——"预声明 + 门禁"的端到端可验证证据；两条路径（Redis 启用 → asynq；禁用 → inproc）各实跑一次。
|
||||
6. `make code-check`、`make format`、`go test ./backend/...` 全绿；`go run main.go all` 实跑通过，覆盖 banner、迁移与门禁。
|
||||
7. `AGENTS.md`、`new-setting` skill 与白皮书中 `ctx.Config().Bind(...)` 的签名与 key 命名约定更新为已实现的真实 API。
|
||||
|
||||
### 7.3 实施顺序建议
|
||||
|
||||
每阶段独立可验证，供实施计划拆分参考：
|
||||
|
||||
| 阶段 | 内容 | 验证 |
|
||||
| :--- | :--- | :--- |
|
||||
| P1 | 配置引擎（`core/extpoints/config.go`）+ `plugins/infra/config` 适配器 + 新旧对拍测试 | `go test ./backend/core/...`；对拍输出等价性报告 |
|
||||
| P2 | 门禁与 `FiberSkipped`、`App.Prepare()` 解析屏障 | `core` 门禁单测；现有测试全绿（此时旧单例仍在，未迁移） |
|
||||
| P3 | 按 infra → drivers → domain → cmd 顺序迁移 27 个文件；`idgen.Init` 解耦 | 每层迁移后 `go build ./...` + 该层测试；最后实跑两条门禁路径 |
|
||||
| P4 | 删除 `backend/pkg/config` 与对拍测试；更新 `AGENTS.md`/skill/白皮书 API | §7.2 全部验收项逐条复核 |
|
||||
|
||||
---
|
||||
|
||||
## 附录 A：迁移清单
|
||||
|
||||
删除：`backend/pkg/config/{config.go,model.go,config_test.go}`
|
||||
|
||||
新增：`backend/core/extpoints/config.go`、`backend/core/config.go`、`backend/plugins/infra/config/*`、各插件内 `<name>_config.go` 声明文件
|
||||
|
||||
需改写的 27 个文件：
|
||||
|
||||
| 分组 | 文件 |
|
||||
| :--- | :--- |
|
||||
| 组合根 | `cmd/app.go`、`cmd/root.go`、`cmd/banner.go`、`cmd/app_test.go`、`cmd/banner_test.go`、`cmd/redis_plug_test.go` |
|
||||
| 基础库 | `pkg/idgen/snowflake.go`（连带 `pkg/idgen/snowflake_test.go`） |
|
||||
| infra | `plugins/infra/cache/redis.go`、`plugins/infra/database/postgres.go`、`plugins/infra/database/clickhouse.go` |
|
||||
| drivers | `plugins/drivers/driver_http/engine.go`、`plugins/drivers/driver_http/middlewares.go`、`plugins/drivers/driver_asynq_worker/utils.go`、`plugins/drivers/driver_asynq_worker/utils_test.go`、`plugins/drivers/driver_asynq_cron/plugin.go` |
|
||||
| domain/admin | `plugins/domain/admin/handler/db.go`、`plugins/domain/admin/repository/db.go`、`plugins/domain/admin/service/db.go`、`plugins/domain/admin/service/status.go`、`plugins/domain/admin/service/log_switch.go` |
|
||||
| domain/其他 | `plugins/domain/auth/session.go`、`plugins/domain/cap/service.go`、`plugins/domain/message_gateway/service/service.go`、`plugins/domain/system/plugin.go`、`plugins/domain/risk_control/middleware.go`、`plugins/domain/risk_control/middleware_test.go`、`plugins/domain/risk_control/logstore/provider.go` |
|
||||
|
||||
> 注：`risk_control/middleware.go`、`cap/service.go`、`message_gateway/service/service.go` 等处以 `config.Config != nil` 做存在性判断的分支，在注入式配置模型下不再可能，迁移时一并消除。
|
||||
|
||||
---
|
||||
|
||||
## 8. 落地回写（P1 + P2 已实施）
|
||||
|
||||
实施结果与本设计原述的差异，均已按下列口径落地：
|
||||
|
||||
| # | 设计原述 | 落地结果 | 缘由 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| R1 | §4.3 C1、§6 把 `app.session_age<=0` 列为内核解析错误 | 引擎不做值域校验，`ErrConfigInvalid` 保留但未在内核使用；值域由声明者在 `Bind` 之后校验（P3 由 auth 承担） | 引擎被设计成不认识任何业务 key 的语义，把业务规则塞进内核会破坏该不变式 |
|
||||
| R2 | §3.2 `ConfigView.Source(key)` | 更名 `Origin(key)`；新增 `Value(key) (any, bool)`；`ConfigExtension` 增加 `SetSource`、`Resolved` | `Source` 与类型名 `ConfigSource` 同文件易混淆；`Value` 支撑 `core.ConfigGet[T]`（Go 方法不能带类型参数）；`SetSource` 进接口以免运行时类型断言 |
|
||||
| R3 | §3.5 仅有 `WithShutdownTimeout` | 新增 `App.ShutdownTimeout()` 与 `SetShutdownTimeout(d) *App` | 组合根需在 `Prepare()` 之后把已解析预算写回内核，构造期选项无法表达该顺序 |
|
||||
| R4 | §4.2 时序图把门禁求值画在 `Prepare()` 内 | `Prepare()` 只建立解析屏障，门禁在 `reconcileLocked` 每轮调和中求值 | `App.Use` 可在 `Prepare()` 之后继续挂载插件；只在 `Prepare` 求值会留下一批永不判定的门禁 |
|
||||
| R5 | 未涉及 | `App` 未注入 `ConfigSource` 时配置能力视为未启用，解析屏障直接放行；实现了 `ConfigGatedPlugin` 却无配置源的插件 fail fast 点名原因 | 内核存在大量不使用配置的装配路径（既有测试与嵌入式用法），不能强制要求配置源；但门禁无数据可依时必须报错，而非静默全激活 |
|
||||
| R6 | §4.1 隐含"每个 key 都有 env 覆盖" | env 覆盖面完全由声明决定。旧装载器只对部分 key 提供 env（`slow_threshold`、`conn_max_lifetime` 等从未有 env 覆盖），对拍镜像必须精确复刻该覆盖面 | 否则对拍出现假漂移；放宽某 key 的 env 覆盖是 P3 的声明选择，不构成引擎行为变更 |
|
||||
| R7 | §4.1 "向上最多 5 层查找 `config.yaml`" | 该向上查找会**越出 git worktree 边界**：从 `backend/pkg/config` 出发第 5 层可命中父级检出的 `config.yaml` | 属既有行为、非本次引入，但在 worktree 中开发会静默使用另一份检出的配置。对拍测试已改为以入库的 `config.example.yaml` 所在目录为锚；`config.yaml` 本身被 gitignore，干净克隆中不存在 |
|
||||
|
||||
分期口径：本设计 §7.3 的 P1 + P2 已实施完成；P3（27 个消费文件迁移、`pkg/idgen` 解耦）与 P4（删除 `backend/pkg/config`、移除对拍夹具）由后续计划承接。
|
||||
Reference in New Issue
Block a user