背景
现有 WebHook 机制实现简单,存在以下问题:
- 硬编码实现:仅支持 RestTemplate POST,无法扩展其他协议
- 静态配置:WebHook URL 写死在配置文件,修改需重启服务
- 事件类型单一:只支持配置发布,无法订阅回滚、合并等事件
- 缺乏安全性:没有签名或认证,易被伪造
- 缺乏可观测性:无调用日志,无 UI 管理,无失败重试
改造目标
- 插件化:支持 HTTP、MQ、gRPC、Email、企业微信等通知方式
- 动态管理:提供 API + UI 管理 WebHook 订阅
- 安全性:通过 HMAC-SHA256 签名保证请求可信
- 可靠性:异步调用 + 重试机制,失败不影响主流程
- 可观测性:记录调用日志,支持查询与调试
技术方案
1. 插件化架构
2. 数据库表设计
Webhook:存储订阅配置(AppId, Url, Secret, 启用状态)
WebhookEvent:存储订阅的事件类型(RELEASE, ROLLBACK 等)
WebhookLog:存储调用日志(请求体、响应体、状态码、是否成功)
3. API 设计
POST /apps/{appId}/webhooks:创建订阅(返回一次性 secret)
GET /apps/{appId}/webhooks:查询订阅列表
PUT /webhooks/{id}:更新订阅
DELETE /webhooks/{id}:删除订阅
GET /webhooks/{id}/logs:查询调用日志
4. 安全与可靠性
- 签名:请求头
X-Apollo-Signature-256 携带 HMAC-SHA256 签名
- 异步投递:独立线程池执行,不阻塞主发布流程
- 失败重试:1min、5min、15min 三次重试机制
- 错误隔离:单个 WebHook 失败不影响其他订阅
5. Portal 扩展
- 新增 WebHook 管理界面
- 支持插件配置、调试与启停
实施计划
- 阶段 1:实现 SPI 接口、插件管理器、HTTP 插件、数据库表结构
- 阶段 2:扩展 MQ、企业微信、邮件插件,提供管理界面
- 阶段 3:支持插件热加载、性能监控、重试与熔断机制
Checklist
背景
现有 WebHook 机制实现简单,存在以下问题:
改造目标
技术方案
1. 插件化架构
设计标准 SPI 接口:
NotificationHandler、NotificationConfig、NotificationContext插件管理器
WebHookPluginManager,支持插件注册、验证、运行时加载内置插件:
2. 数据库表设计
Webhook:存储订阅配置(AppId, Url, Secret, 启用状态)WebhookEvent:存储订阅的事件类型(RELEASE, ROLLBACK 等)WebhookLog:存储调用日志(请求体、响应体、状态码、是否成功)3. API 设计
POST /apps/{appId}/webhooks:创建订阅(返回一次性 secret)GET /apps/{appId}/webhooks:查询订阅列表PUT /webhooks/{id}:更新订阅DELETE /webhooks/{id}:删除订阅GET /webhooks/{id}/logs:查询调用日志4. 安全与可靠性
X-Apollo-Signature-256携带 HMAC-SHA256 签名5. Portal 扩展
实施计划
Checklist