# Phase 3: 网关配置变更广播机制 - Context

**Gathered:** 2026-03-03
**Status:** Ready for planning

<domain>
## Phase Boundary

分析现有的网关配置广播机制，梳理路由→服务→下游的完整链路，确定配置变更时的广播策略。

</domain>

<decisions>
## Implementation Decisions

### 广播触发策略
- **仅手动触发**：所有 CRUD 操作（路由、集群、实例、权重）不自动广播
- 下游需要刷新时，手动调用 POST /api/console/gateway/reload
- 事件只通知"需要刷新"，不包含具体变更内容
- 下游收到通知后，自行查询数据库刷新配置

### 广播事件格式
- 通道：`gateway_config_changed`
- 事件内容：只包含 action: "reload"，不含具体变更详情
- 下游逻辑：收到通知 → 查询数据库 → 刷新内存缓存

### 需分析的现有代码
- ConfigNotificationService.cs - 已实现的 NOTIFY 机制
- GatewayService.cs - 需集成通知服务
- GatewayController.cs - /reload 接口

### Claude's Discretion
- 自动触发 vs 手动触发的具体实现方式
- 广播失败时的错误处理策略
- 日志记录细节

</decisions>

<code_context>
## Existing Code Insights

### Reusable Assets
- ConfigNotificationService.cs: PostgreSQL NOTIFY 机制已实现
- INotificationService 接口: 可直接复用

### Established Patterns
- 使用 PgSqlNotificationService 发布通知
- 通道名称: `gateway_config_changed`

### Integration Points
- GatewayService 需注入 INotificationService
- ReloadGatewayAsync 需调用通知服务

</code_context>

<specifics>
## Specific Ideas

- 事件 payload 尽量精简，只传递 "reload" action
- 下游网关监听同一数据库连接，收到 NOTIFY 后刷新

</specifics>

<deferred>
## Deferred Ideas

- 自动触发广播（未来可选优化）

</deferred>

---

*Phase: 03-gateway-config-broadcast*
*Context gathered: 2026-03-03*