WebhockTransfer/.trae/documents/Webhook中继系统 - 核心逻辑重构计划.md
houhuan 2bc7460f1f feat: 初始化Webhook中继系统项目
- 添加FastAPI应用基础结构,包括主入口、路由和模型定义
- 实现Webhook接收端点(/webhook/{namespace})和健康检查(/health)
- 添加管理后台路由和模板,支持端点、目标、渠道和模板管理
- 包含SQLite数据库模型定义和初始化逻辑
- 添加日志记录和统计服务
- 包含Dockerfile和配置示例文件
- 添加项目文档,包括设计、流程图和验收标准
2025-12-21 18:43:12 +08:00

3.1 KiB
Raw Blame History

Webhook 中继系统 - 核心逻辑重构计划

1. 核心设计理念变更

响应您的需求我们将系统从“基于固定字段remark的路由”升级为**“基于端点的自定义规则引擎”**。

  • 以端点为中心每个接收端点Endpoint拥有独立的配置页面绑定属于自己的处理流程。
  • 通用规则引擎:不再硬编码检测 remarkevent_define_no
    • 变量自定义:您可以指定检测 JSON 中的任意字段(如 body.statusdata.order_id)。
    • 条件匹配:当指定字段的值等于设定值时,触发动作。
  • 统一动作Action:将“转发”和“通知”统一为规则命中的“动作”。
    • 动作 A转发给目标 X原 Target
    • 动作 B使用模板 Y 发送给渠道 Z原 Notification

2. 数据库模型重构 (app/db.py)

我们需要调整表结构以支持这种灵活关系(建议重置数据库):

  1. 保留WebhookEndpoint, Target, NotificationChannel, RequestLog, DeliveryLog
  2. 移除RemarkRule, 旧的 EventTemplate 关联逻辑。
  3. 新增/修改
    • MessageTemplate (原 EventTemplate)仅存储模板文本不再绑定特定事件ID作为纯资源库。
    • ProcessingRule (处理规则):绑定到 WebhookEndpoint
      • 字段:match_field (匹配键,如 trans_order_info.remark), match_value (匹配值)。
    • RuleAction (规则动作):绑定到 ProcessingRule
      • 字段:action_type (forward/notify), target_id (关联Target), channel_id (关联Channel), template_id (关联Template)。

3. 业务逻辑升级 (app/services/engine.py)

创建新的规则引擎服务:

  • 动态取值:支持点号索引(如 data.user.id)从深层 JSON 中提取变量。
  • 流程执行
    1. 接收 Webhook -> 查找 Endpoint。
    2. 遍历 Endpoint 下的所有 ProcessingRule
    3. 提取 match_field 对应的值与 match_value 比对。
    4. 命中则执行该规则下的所有 RuleAction(并行执行转发或通知)。

4. Admin UI 交互大改版

  • 资源库模式目标管理通知渠道消息模板 变为纯粹的基础资源维护页面。
  • 端点编排页(核心):
    • 点击某个端点,进入**“流程配置”**详情页。
    • 可视化规则编辑器
      • "当 [输入框: 字段路径] 等于 [输入框: 值] 时:"
        • 添加动作:[转发] -> 选择目标。
        • 添加动作:[通知] -> 选择渠道 + 选择模板。
  • 体验优化:在同一个页面完成逻辑闭环,无需在不同菜单间跳转。

5. 实施步骤

  1. 重构 DB:更新 app/db.py 模型定义。
  2. 实现引擎:编写 app/services/engine.py 实现动态匹配与分发。
  3. 更新 API:修改 app/main.py 调用新引擎。
  4. 重写 UI
    • 改造 admin.py 路由。
    • 新增 templates/admin/endpoint_detail.html 作为核心配置页。
    • 简化其他资源页面。
  5. 迁移/重置:删除旧 DB文件重新构建运行。