26e - Webhook与高级集成

节点配置：
├── HTTP Method: POST（推荐，也支持 GET/PUT/DELETE/PATCH）
├── Path: /my-webhook-endpoint（自定义路径）
├── Authentication: 选择认证方式
│   ├── None（不推荐用于生产）
│   ├── Basic Auth
│   ├── Header Auth（推荐）
│   └── JWT Auth
├── Respond: 选择响应模式
│   ├── Immediately（立即返回 200）
│   ├── When Last Node Finishes（等待工作流完成后返回）
│   └── Using 'Respond to Webhook' Node（自定义响应）
└── Options:
    ├── Binary Property: 接收文件上传
    ├── Raw Body: 保留原始请求体（签名验证必需）
    └── IP Whitelist: IP 白名单过滤

1. 进入 n8n → Credentials → 新建 Header Auth
2. 配置：
   - Name: X-Webhook-Secret
   - Value: your-random-secret-key-here（建议 32+ 字符随机字符串）
3. 在 Webhook 节点中选择此凭证
4. 调用方在请求头中携带：
   X-Webhook-Secret: your-random-secret-key-here

// n8n Code 节点 - HMAC 签名验证
const crypto = require('crypto');
 
const secret = $env.WEBHOOK_SECRET; // 从环境变量获取密钥
const signature = $input.first().headers['x-hub-signature-256'];
const body = $input.first().body; // 需要开启 Raw Body
 
const expectedSignature = 'sha256=' + 
  crypto.createHmac('sha256', secret)
    .update(JSON.stringify(body))
    .digest('hex');
 
if (signature !== expectedSignature) {
  throw new Error('Invalid webhook signature');
}
 
return $input.all();

场景选择指南：
├── 同步响应（When Last Node Finishes）
│   ├── 适用：调用方需要处理结果（如 API 端点）
│   ├── 超时风险：工作流执行时间 > 调用方超时时间
│   └── 建议：工作流执行时间 < 30 秒
├── 异步响应（Immediately）
│   ├── 适用：调用方只需确认接收（如支付回调）
│   ├── 优势：立即返回 200，不阻塞调用方
│   └── 建议：大多数 Webhook 场景首选
└── 自定义响应（Respond to Webhook Node）
    ├── 适用：需要返回自定义状态码、Header 或 Body
    ├── 示例：返回 { "status": "accepted", "id": "xxx" }
    └── 注意：必须在工作流中放置 Respond to Webhook 节点

1. 新建场景 → 添加模块 → 搜索 "Webhooks"
2. 选择 "Custom webhook"
3. 点击 "Create a webhook"
4. 配置：
   - Webhook name: 描述性名称（如 "Stripe Payment Webhook"）
   - IP restrictions: 限制来源 IP（可选但推荐）
   - JSON pass-through: 
     - No（默认）：Make 解析 JSON 结构，可在后续模块中直接引用字段
     - Yes：原始 JSON 字符串传递，需手动解析
5. 复制生成的 Webhook URL
6. 点击 "Redetermine data structure" → 发送一个测试请求
   → Make 自动识别数据结构，后续模块可直接映射字段

Custom Webhook → Filter（验证条件）→ 后续处理

Filter 配置示例：
├── Condition 1: headers.x-api-key = "your-secret-key"
├── Condition 2: body.event_type 存在且不为空
└── Fallback: 不满足条件时场景静默终止

Custom Webhook → 处理逻辑 → Webhook response 模块

Webhook response 配置：
├── Status: 200（或自定义状态码）
├── Headers: Content-Type: application/json
└── Body: {"status": "processed", "timestamp": "{{now}}"}

你是一位 n8n/Make.com 自动化专家。请帮我设计一个 Webhook 集成工作流：

## 需求
- 接收来源：[第三方服务名称，如 Stripe/GitHub/Shopify]
- 事件类型：[具体事件，如 payment.succeeded / push / order.created]
- 处理逻辑：[需要执行的操作，如 更新数据库/发送通知/触发下游流程]
- 安全要求：[HMAC 签名验证 / API Key / IP 白名单]

## 请提供
1. Webhook 节点配置（认证方式、响应模式）
2. 签名验证代码（如适用）
3. 数据提取和转换逻辑
4. 错误处理和重试策略
5. 测试验证步骤

## 约束
- 平台：[n8n 自托管 / n8n Cloud / Make.com]
- 预期流量：[每日请求量]
- 响应时间要求：[同步/异步]

Schedule Trigger 节点配置：
├── Trigger Times:
│   ├── 每 N 分钟/小时: interval 模式
│   │   └── 示例: 每 15 分钟执行一次
│   ├── 每天固定时间: 指定小时和分钟
│   │   └── 示例: 每天 09:00 执行
│   ├── 每周固定日期: 指定星期几 + 时间
│   │   └── 示例: 每周一和周五 10:00
│   └── Cron 表达式: 完全自定义
│       └── 示例: 0 */6 * * 1-5（工作日每 6 小时）
└── 注意: 多条规则是"加法"关系（OR），不是"交集"

Cron 表达式格式（5 字段）：
┌───────────── 分钟 (0-59)
│ ┌───────────── 小时 (0-23)
│ │ ┌───────────── 日 (1-31)
│ │ │ ┌───────────── 月 (1-12)
│ │ │ │ ┌───────────── 星期 (0-7, 0和7都是周日)
│ │ │ │ │
* * * * *

时区优先级（从高到低）：
1. 工作流级别时区设置
   └── 工作流编辑器 → 右上角 ⋮ → Settings → Timezone
2. n8n 实例级别时区
   └── 环境变量: GENERIC_TIMEZONE=Asia/Shanghai
3. 默认时区
   ├── 自托管: America/New_York（注意！不是 UTC）
   └── n8n Cloud: 注册时检测用户时区，回退到 GMT

# Docker 部署时设置时区（docker-compose.yml）
services:
  n8n:
    environment:
      - GENERIC_TIMEZONE=Asia/Shanghai
      - TZ=Asia/Shanghai
    # 确保容器系统时区也正确
    volumes:
      - /etc/localtime:/etc/localtime:ro

⚠️ 常见时区陷阱：
1. 夏令时切换：使用 IANA 时区名（Asia/Shanghai）而非固定偏移（UTC+8）
   → IANA 时区自动处理夏令时，固定偏移不会
2. 实例重启后时区重置：确保时区配置在环境变量中持久化
3. 多条规则的时区不一致：所有规则共享工作流时区设置
4. Railway/Render 等 PaaS 平台：默认 UTC，必须显式设置

Make.com 场景调度配置：
├── 场景设置 → Scheduling
│   ├── Run scenario: 
│   │   ├── At regular intervals（固定间隔）
│   │   │   └── 最小间隔: 免费版 15 分钟，付费版 1 分钟
│   │   ├── Once（单次执行）
│   │   └── Every day（每天指定时间）
│   ├── Advanced scheduling:
│   │   ├── 指定运行日期（周一至周日）
│   │   ├── 指定运行时间段（如 09:00-18:00）
│   │   └── 指定月份中的日期
│   └── Time zone: 在账户设置中配置
├── 注意事项：
│   ├── Make.com 不支持原生 Cron 表达式
│   ├── 复杂调度需要组合多个场景或使用外部 Cron 服务
│   └── 场景执行有操作数（Operations）限制，注意计费

请帮我设计一个定时调度工作流：

## 任务描述
- 任务名称：[如 每日销售报告生成]
- 执行频率：[如 每天早上 9 点 / 每小时 / 每周一]
- 时区要求：[如 Asia/Shanghai / America/New_York]
- 平台：[n8n / Make.com]

## 调度要求
- 是否需要跳过节假日：[是/否]
- 是否需要错过执行补偿：[是/否，如服务器宕机后是否补执行]
- 并发控制：[同一工作流是否允许并行执行]
- 执行窗口：[是否限制在特定时间段内执行]

## 请提供
1. Cron 表达式或调度配置
2. 时区设置建议
3. 错过执行的处理策略
4. 监控和告警配置

n8n HTTP Request 节点配置：
├── Method: GET / POST / PUT / PATCH / DELETE
├── URL: https://api.example.com/v1/resources
├── Authentication: 
│   ├── Predefined Credential Type（推荐，支持 OAuth2 等）
│   ├── Generic Credential Type（Header Auth / Query Auth）
│   └── None
├── Headers:
│   ├── Content-Type: application/json
│   └── Accept: application/json
├── Query Parameters: key=value 对
├── Body:
│   ├── JSON（最常用）
│   ├── Form-Data（文件上传）
│   └── Raw（自定义格式）
├── Options:
│   ├── Timeout: 请求超时时间（毫秒）
│   ├── Retry On Fail: 失败重试
│   ├── Batching: 批量请求控制
│   └── Pagination: 自动分页（关键功能！）
└── Response:
    └── Response Format: JSON / Text / File

Pagination 配置（n8n HTTP Request 节点）：

方式 1：Offset-Based 分页
├── Pagination Mode: Offset and Limit
├── Limit Parameter: limit（或 per_page / pageSize）
├── Offset Parameter: offset（或 skip）
├── Page Size: 100（每页记录数）
├── Max Pages: 50（最大页数，防止无限循环）
└── Complete When: 
    └── Response Is Empty（返回空数组时停止）

方式 2：Cursor-Based 分页
├── Pagination Mode: Response Contains Next URL
├── Next URL: {{ $response.body.next }}（从响应中提取下一页 URL）
├── Max Pages: 50
└── Complete When:
    └── Next URL Is Empty

方式 3：Page Number 分页
├── Pagination Mode: Update a Parameter in Each Request
├── Parameter Name: page
├── Parameter Type: Query
├── Initial Value: 1
├── Update Expression: {{ $pageCount + 1 }}
├── Max Pages: 100
└── Complete When:
    └── Response Body Contains: "has_more": false

Make.com 不支持内置自动分页，需要手动实现：

方案 1：使用 Repeater + HTTP 模块
├── Repeater 模块: 设置最大迭代次数
├── HTTP 模块: 每次请求带上 offset/cursor
├── Router: 检查是否还有更多数据
│   ├── 有 → 继续循环
│   └── 无 → 退出循环
└── Array Aggregator: 合并所有页的数据

方案 2：使用递归场景（Webhook 自调用）
├── 场景 A: 处理当前页 + 检查是否有下一页
├── 如果有下一页 → HTTP 模块调用自身的 Webhook URL
└── 注意：每次调用消耗操作数，大数据集成本较高

n8n 速率限制处理策略：

策略 1：节点级 Retry on Fail
├── 开启 Retry On Fail
├── Max Tries: 5
├── Wait Between Tries: 动态计算
│   └── 读取响应头 Retry-After 或使用固定退避
└── 适用：简单的 429 重试

策略 2：Split In Batches + Wait 节点
├── Split In Batches: 将大量请求分成小批次
│   └── Batch Size: 根据 API 限制设置（如 10）
├── HTTP Request: 处理当前批次
├── Wait 节点: 批次间等待
│   └── Wait Time: 根据 API 速率限制计算
│       例如 API 限制 60 请求/分钟 → 批次间等待 10 秒
└── 适用：批量 API 调用

策略 3：Code 节点动态退避
├── 在 Code 节点中实现指数退避逻辑
├── 读取 HTTP 响应头中的速率限制信息：
│   ├── X-RateLimit-Remaining: 剩余请求数
│   ├── X-RateLimit-Reset: 重置时间戳
│   └── Retry-After: 建议等待秒数
└── 动态调整请求间隔

n8n GraphQL 节点配置：
├── Endpoint: https://api.example.com/graphql
├── Authentication: 同 HTTP Request 节点
├── Request Format: GraphQL（自动处理 Content-Type）
├── Query:
│   query GetUsers($first: Int!, $after: String) {
│     users(first: $first, after: $after) {
│       edges {
│         node { id name email }
│         cursor
│       }
│       pageInfo {
│         hasNextPage
│         endCursor
│       }
│     }
│   }
├── Variables:
│   {
│     "first": 100,
│     "after": null
│   }
└── Response Path: data.users.edges（提取嵌套数据）

// n8n Code 节点 - GraphQL Cursor 分页
const results = [];
let hasNextPage = true;
let cursor = null;
 
while (hasNextPage) {
  const response = await this.helpers.httpRequest({
    method: 'POST',
    url: 'https://api.example.com/graphql',
    body: {
      query: `query($first: Int!, $after: String) {
        users(first: $first, after: $after) {
          edges { node { id name email } cursor }
          pageInfo { hasNextPage endCursor }
        }
      }`,
      variables: { first: 100, after: cursor }
    },
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${$credentials.apiToken}`
    }
  });
  
  const data = response.data.users;
  results.push(...data.edges.map(e => e.node));
  hasNextPage = data.pageInfo.hasNextPage;
  cursor = data.pageInfo.endCursor;
}
 
return results.map(item => ({ json: item }));

请帮我设计一个外部 API 集成工作流：

## API 信息
- API 类型：[REST / GraphQL]
- 基础 URL：[API 端点地址]
- 认证方式：[API Key / OAuth2 / Bearer Token]
- 速率限制：[如 100 请求/分钟]
- 分页方式：[Offset / Cursor / Page Number / 无分页]

## 集成需求
- 操作类型：[读取数据 / 写入数据 / 双向同步]
- 数据量级：[每次调用的预期数据量]
- 执行频率：[实时 / 每小时 / 每天]
- 数据转换：[是否需要字段映射或格式转换]

## 请提供
1. API 调用配置（认证、Header、参数）
2. 分页处理策略
3. 速率限制应对方案
4. 错误处理和重试逻辑
5. 数据转换和映射规则

n8n 凭证架构：
├── 存储层：
│   ├── 数据库中存储加密后的凭证数据
│   ├── 加密算法：AES-256-GCM
│   └── 加密密钥：N8N_ENCRYPTION_KEY 环境变量
├── 访问控制：
│   ├── 凭证归属于创建者
│   ├── 可通过项目（Project）共享给团队成员
│   ├── 共享的凭证：成员可使用但无法查看明文
│   └── 注意：共享凭证以创建者身份执行操作
├── 凭证类型：
│   ├── 预定义类型：OAuth2、API Key、Basic Auth 等（200+ 种）
│   ├── 通用类型：Header Auth、Query Auth
│   └── 自定义类型：通过社区节点扩展
└── 生命周期：
    ├── 创建：通过 UI 或 API 创建
    ├── 使用：工作流节点引用
    ├── 更新：手动更新或 OAuth2 自动刷新
    └── 删除：手动删除（不可恢复）

# 生成强加密密钥（32 字节随机字符串）
openssl rand -hex 32
# 输出示例：a1b2c3d4e5f6...（64 个十六进制字符）
 
# 在 docker-compose.yml 中配置
services:
  n8n:
    environment:
      - N8N_ENCRYPTION_KEY=your-generated-key-here
    # 或使用 Docker secrets（更安全）
    secrets:
      - n8n_encryption_key
 
secrets:
  n8n_encryption_key:
    file: ./secrets/n8n_encryption_key.txt

⚠️ 关键警告：
1. N8N_ENCRYPTION_KEY 丢失 = 所有凭证永久不可恢复
2. 必须备份此密钥到安全位置（密码管理器、保险箱）
3. 更换密钥需要重新输入所有凭证
4. 不同环境（开发/生产）应使用不同的密钥

n8n 凭证共享模型：
├── 个人凭证（默认）：
│   └── 仅创建者可使用和管理
├── 项目级共享：
│   ├── 将凭证移动到项目中
│   ├── 项目成员可在工作流中使用
│   ├── 成员无法查看凭证明文值
│   └── 操作以凭证创建者身份执行
├── 权限层级：
│   ├── Owner：完全控制（查看、编辑、删除、共享）
│   ├── Admin：可管理项目内凭证
│   ├── Editor：可使用凭证，不可查看明文
│   └── Viewer：不可使用凭证
└── 安全建议：
    ├── 为每个服务创建独立凭证（不复用）
    ├── 使用描述性命名：[服务]-[环境]-[用途]
    │   例如：stripe-prod-payments / github-dev-ci
    └── 定期审计凭证使用情况

Make.com Connections 架构：
├── 连接类型：
│   ├── 预建连接：1000+ 应用的 OAuth2/API Key 连接
│   ├── 自定义连接：通过 HTTP 模块手动配置
│   └── Webhook 连接：无需认证的入站连接
├── 安全特性：
│   ├── OAuth2 自动刷新 Token
│   ├── 连接加密存储
│   ├── 连接可在场景间复用
│   └── 团队成员可共享连接
├── 管理操作：
│   ├── 创建：场景中首次使用时创建
│   ├── 测试：Verify 按钮测试连接有效性
│   ├── 重新授权：OAuth2 Token 过期时重新授权
│   └── 删除：从 Connections 页面管理
└── 限制：
    ├── 免费版：有限连接数
    ├── 连接绑定到创建者账户
    └── 团队转移需要重新授权

凭证轮换最佳实践：

1. API Key 轮换流程：
   ├── 在第三方服务中生成新 Key
   ├── 在 n8n/Make 中更新凭证为新 Key
   ├── 验证工作流正常运行
   ├── 在第三方服务中撤销旧 Key
   └── 记录轮换日期和下次轮换时间

2. OAuth2 Token 管理：
   ├── n8n 和 Make.com 都支持自动刷新 Access Token
   ├── 但 Refresh Token 也有过期时间（通常 90 天）
   ├── 设置定时提醒在 Refresh Token 过期前重新授权
   └── 监控 401 错误作为 Token 失效的信号

3. 轮换频率建议：
   ├── 高敏感凭证（支付、数据库）：每 30 天
   ├── 中敏感凭证（CRM、邮件）：每 90 天
   ├── 低敏感凭证（公开 API）：每 180 天
   └── 发生安全事件时：立即轮换所有相关凭证

4. 自动化轮换（高级）：
   ├── 使用 HashiCorp Vault 动态生成短期凭证
   ├── n8n 通过 HTTP Request 节点调用 Vault API
   ├── 每次工作流执行时获取临时凭证
   └── 凭证自动过期，无需手动轮换

n8n 架构对比：

默认模式（单进程）：
┌─────────────────────────┐
│         n8n 主进程        │
│  ┌─────┐ ┌─────┐ ┌─────┐│
│  │编辑器│ │触发器│ │执行器││
│  └─────┘ └─────┘ └─────┘│
│  所有功能在同一进程中运行  │
│  → 编辑器卡顿影响执行     │
│  → 单线程瓶颈             │
└─────────────────────────┘

队列模式（分布式）：
┌──────────┐    ┌───────┐    ┌──────────┐
│ n8n 主进程 │───→│ Redis │←───│ Worker 1 │
│ (编辑器+  │    │ Queue │←───│ Worker 2 │
│  触发器)  │    │       │←───│ Worker 3 │
└──────────┘    └───────┘    └──────────┘
  ↑ Webhook       任务队列      独立执行
  ↑ Cron                       可水平扩展
  ↑ 手动触发                    互不影响

# docker-compose.yml - n8n 队列模式配置
version: '3.8'
 
services:
  # Redis 队列
  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
 
  # PostgreSQL 数据库（生产必须，替代 SQLite）
  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 3
 
  # n8n 主进程（编辑器 + 触发器 + Webhook 接收）
  n8n:
    image: n8nio/n8n:latest
    restart: always
    environment:
      # 队列模式核心配置
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      # 数据库配置
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      # 加密与时区
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=Asia/Shanghai
      - TZ=Asia/Shanghai
      # Webhook URL（外部可访问地址）
      - WEBHOOK_URL=https://n8n.yourdomain.com/
    ports:
      - "5678:5678"
    depends_on:
      redis:
        condition: service_healthy
      postgres:
        condition: service_healthy
 
  # Worker 进程（可启动多个实例）
  n8n-worker:
    image: n8nio/n8n:latest
    restart: always
    command: worker
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=Asia/Shanghai
      # Worker 并发配置
      - QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD=60000
    depends_on:
      redis:
        condition: service_healthy
      postgres:
        condition: service_healthy
    # 水平扩展：启动多个 Worker
    deploy:
      replicas: 3
 
volumes:
  redis_data:
  postgres_data:

Worker 扩展决策指南：

评估当前负载：
├── 查看 Redis 队列积压量
│   redis-cli LLEN bull:n8n:jobs:waiting
├── 查看 Worker 内存使用
│   docker stats n8n-worker
└── 查看工作流平均执行时间

扩展策略：
├── 垂直扩展（增加单 Worker 资源）：
│   ├── 适用：工作流内存密集（大文件处理、大数据集）
│   ├── 调整：增加容器内存限制
│   └── 上限：单 Worker 建议不超过 4GB 内存
├── 水平扩展（增加 Worker 数量）：
│   ├── 适用：大量并发工作流执行
│   ├── 调整：增加 deploy.replicas 数量
│   ├── 建议：每个 CPU 核心 1-2 个 Worker
│   └── 注意：所有 Worker 共享同一 Redis 和 PostgreSQL
└── 混合扩展：
    ├── 为不同类型的工作流分配不同的 Worker 池
    ├── 重型工作流（AI 推理）→ 高内存 Worker
    └── 轻型工作流（数据转发）→ 多个低配 Worker

批处理策略（n8n）：

场景：需要处理 10,000 条记录

❌ 错误方式：逐条处理
├── HTTP Request 节点处理每条记录
├── 10,000 次 API 调用
├── 耗时：~3 小时（假设每次 1 秒）
└── 问题：内存溢出、API 限流、执行超时

✅ 正确方式：Split In Batches 批处理
├── Split In Batches 节点：
│   ├── Batch Size: 100（每批 100 条）
│   └── Options: Reset = false（保持状态）
├── HTTP Request 节点：
│   └── 使用 API 的批量端点（如 POST /bulk）
├── Wait 节点（可选）：
│   └── 批次间等待 1-2 秒，避免限流
└── 结果：
    ├── 100 次 API 调用（而非 10,000 次）
    ├── 耗时：~5 分钟
    └── 内存使用稳定

内存管理最佳实践：

1. 执行数据清理：
   # 环境变量配置
   EXECUTIONS_DATA_PRUNE=true
   EXECUTIONS_DATA_MAX_AGE=168  # 保留 7 天
   EXECUTIONS_DATA_SAVE_ON_SUCCESS=none  # 成功执行不保存数据
   EXECUTIONS_DATA_SAVE_ON_ERROR=all     # 失败执行保存完整数据

2. 大数据集处理：
   ├── 使用 Streaming 模式处理大文件
   ├── 避免在 Code 节点中加载整个数据集到内存
   ├── 使用数据库中间存储而非内存传递
   └── 及时释放不需要的中间数据

3. 工作流设计优化：
   ├── 拆分大工作流为多个小工作流
   ├── 使用 Execute Workflow 节点串联
   ├── 每个子工作流独立执行，独立释放内存
   └── 通过 Webhook 或数据库传递中间结果

4. 数据库优化（PostgreSQL）：
   ├── 定期 VACUUM ANALYZE
   ├── 为 execution_entity 表添加索引
   ├── 配置连接池大小
   └── 监控慢查询

Make.com 操作数（Operations）优化：

理解计费模型：
├── 每个模块执行 = 1 个操作（Operation）
├── 循环中的模块：每次迭代 = 1 个操作
├── 示例：处理 100 条记录，每条经过 3 个模块 = 300 个操作
└── 免费版：1,000 ops/月，Core $9.99/月 10,000 ops

优化策略：

1. 减少模块数量：
   ├── 合并多个 Set Variable 为一个
   ├── 使用 JSON 模块批量处理而非逐字段
   └── 用 Code 模块替代多个简单模块

2. 批量处理：
   ├── 使用 Array Aggregator 收集数据
   ├── 一次性批量写入而非逐条写入
   └── 利用 API 的批量端点

3. 条件过滤前置：
   ├── 在场景开头使用 Filter 模块
   ├── 尽早过滤不需要处理的数据
   └── 减少下游模块的执行次数

4. 调度优化：
   ├── 非实时任务使用较长的调度间隔
   ├── 合并多个小场景为一个大场景
   └── 使用 Webhook 替代轮询（减少空执行）

5. 数据存储优化：
   ├── 使用 Make.com Data Store 缓存频繁查询的数据
   ├── 避免每次执行都调用外部 API 获取配置
   └── 利用场景变量存储运行时状态

生产级高流量架构（n8n 自托管）：

                    ┌─────────────┐
                    │   CDN/WAF   │
                    │ (Cloudflare)│
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │ Load Balancer│
                    │  (Nginx)    │
                    └──┬───────┬──┘
                       │       │
              ┌────────▼─┐  ┌─▼────────┐
              │ n8n 主进程│  │ n8n 主进程│  ← 高可用（主备）
              │ (编辑器)  │  │ (备用)   │
              └────┬─────┘  └──────────┘
                   │
            ┌──────▼──────┐
            │    Redis     │
            │  (Sentinel)  │  ← Redis 高可用
            └──────┬──────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
   ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
   │Worker 1│ │Worker 2│ │Worker 3│  ← 水平扩展
   └────────┘ └────────┘ └────────┘
        │          │          │
        └──────────┼──────────┘
                   │
            ┌──────▼──────┐
            │ PostgreSQL   │
            │ (Primary +   │  ← 数据库高可用
            │  Replica)    │
            └─────────────┘

性能指标参考：
├── 单 Worker：~50-100 并发工作流执行
├── 3 Worker：~150-300 并发工作流执行
├── Webhook 吞吐：~1,000-5,000 请求/秒（取决于工作流复杂度）
├── Redis 内存：每 10,000 待处理任务约 100MB
└── PostgreSQL：建议 SSD 存储，至少 4GB 内存

请帮我设计一个高流量 n8n/Make.com 工作流优化方案：

## 当前状况
- 平台：[n8n 自托管 / n8n Cloud / Make.com]
- 当前部署：[单机 / Docker / Kubernetes]
- 日均执行量：[当前工作流执行次数]
- 目标执行量：[期望达到的执行次数]
- 瓶颈表现：[执行延迟 / 内存溢出 / 队列积压 / 编辑器卡顿]

## 工作流特征
- 平均执行时间：[秒/分钟]
- 数据量级：[每次执行处理的记录数]
- 外部 API 调用数：[每次执行的 API 调用次数]
- 是否有大文件处理：[是/否]
- 并发要求：[是否需要同时执行多个实例]

## 请提供
1. 架构优化建议（队列模式 / 水平扩展 / 数据库升级）
2. 工作流设计优化（批处理 / 拆分 / 缓存）
3. 基础设施配置（Redis / PostgreSQL / Worker 数量）
4. 监控指标和告警阈值
5. 成本估算

GitHub PR 事件
    │
    ▼
┌──────────────┐
│ Webhook 节点  │ ← 接收 GitHub Webhook，HMAC 签名验证
│ POST /github │
└──────┬───────┘
       │
┌──────▼───────┐
│ Code 节点     │ ← 验证签名 + 提取 PR 信息
│ 签名验证      │
└──────┬───────┘
       │
┌──────▼───────┐
│ IF 节点       │ ← 过滤：仅处理 opened/synchronize 事件
│ 事件过滤      │
└──────┬───────┘
       │
┌──────▼───────┐
│ HTTP Request  │ ← 调用 GitHub API 获取 PR diff
│ 获取 PR Diff  │
└──────┬───────┘
       │
┌──────▼───────┐
│ AI Agent 节点 │ ← 使用 GPT-4o/Claude 审查代码
│ 代码审查      │
└──────┬───────┘
       │
┌──────▼───────┐
│ HTTP Request  │ ← 将审查结果作为 PR Comment 发布
│ 发布 Comment  │
└──────┬───────┘
       │
┌──────▼───────┐
│ Slack 节点    │ ← 发送通知到 Slack 频道
│ 发送通知      │
└──────────────┘

HTTP Method: POST
Path: /github-pr-review
Authentication: None（使用 Code 节点验证签名）
Respond: Immediately（立即返回 200，避免 GitHub 超时）
Options:
  Raw Body: true（签名验证需要原始请求体）

const crypto = require('crypto');
 
const secret = $env.GITHUB_WEBHOOK_SECRET;
const signature = $input.first().json.headers['x-hub-signature-256'];
const rawBody = $input.first().json.body;
 
// 计算预期签名
const expectedSignature = 'sha256=' + 
  crypto.createHmac('sha256', secret)
    .update(typeof rawBody === 'string' ? rawBody : JSON.stringify(rawBody))
    .digest('hex');
 
// 使用 timingSafeEqual 防止时序攻击
const sigBuffer = Buffer.from(signature || '', 'utf8');
const expectedBuffer = Buffer.from(expectedSignature, 'utf8');
 
if (sigBuffer.length !== expectedBuffer.length || 
    !crypto.timingSafeEqual(sigBuffer, expectedBuffer)) {
  throw new Error('Invalid GitHub webhook signature');
}
 
// 提取 PR 信息
const payload = typeof rawBody === 'string' ? JSON.parse(rawBody) : rawBody;
return [{
  json: {
    action: payload.action,
    pr_number: payload.pull_request.number,
    pr_title: payload.pull_request.title,
    pr_url: payload.pull_request.html_url,
    diff_url: payload.pull_request.diff_url,
    repo: payload.repository.full_name,
    author: payload.pull_request.user.login
  }
}];

你是一位资深代码审查专家。请审查以下 Pull Request 的代码变更：

## PR 信息
- 仓库：{{ $json.repo }}
- PR 标题：{{ $json.pr_title }}
- 作者：{{ $json.author }}

## 代码 Diff
{{ $json.diff }}

## 审查要求
请从以下维度进行审查：
1. **代码质量**：命名规范、代码结构、可读性
2. **潜在 Bug**：逻辑错误、边界条件、空值处理
3. **安全问题**：注入风险、敏感信息泄露、权限问题
4. **性能问题**：N+1 查询、内存泄漏、不必要的计算
5. **最佳实践**：设计模式、错误处理、测试覆盖

## 输出格式
请使用以下格式输出审查结果：

### 🔴 必须修复（Critical）
- [文件:行号] 问题描述

### 🟡 建议改进（Suggestion）
- [文件:行号] 改进建议

### 🟢 亮点（Good）
- 值得肯定的代码实践

### 📊 总体评分
- 代码质量：X/10
- 安全性：X/10
- 可维护性：X/10

📝 *PR 代码审查完成*

*仓库*：{{ $json.repo }}
*PR*：<{{ $json.pr_url }}|#{{ $json.pr_number }} {{ $json.pr_title }}>
*作者*：{{ $json.author }}

*审查结果*：
{{ $json.review_result }}

_由 AI Code Reviewer 自动生成_

每日 09:00 定时触发
    │
    ▼
┌──────────────┐
│ Schedule      │ ← Cron: 0 9 * * 1-5（工作日 09:00）
│ Trigger       │
└──────┬───────┘
       │
       ├──────────────────────────────┐
       │                              │
┌──────▼───────┐              ┌──────▼───────┐
│ HTTP Request  │              │ HTTP Request  │
│ GitHub API    │              │ Jira API      │
│ (昨日 PR/Issue)│             │ (昨日任务)     │
└──────┬───────┘              └──────┬───────┘
       │                              │
       └──────────┬───────────────────┘
                  │
           ┌──────▼───────┐
           │ Merge 节点    │ ← 合并多源数据
           │ 数据合并      │
           └──────┬───────┘
                  │
           ┌──────▼───────┐
           │ AI Agent 节点 │ ← 生成每日摘要报告
           │ 报告生成      │
           └──────┬───────┘
                  │
           ┌──────▼───────┐
           │ Slack 节点    │ ← 发送到团队频道
           │ 发送报告      │
           └──────────────┘

Schedule Trigger:
├── Rule: Cron Expression
├── Expression: 0 9 * * 1-5
├── Timezone: Asia/Shanghai（工作流设置中配置）
└── 含义：工作日每天上午 9 点执行

GitHub API 调用:
├── URL: https://api.github.com/repos/[owner]/[repo]/pulls
├── Query: state=all&sort=updated&since={{ $today.minus(1, 'day').toISO() }}
├── Authentication: GitHub OAuth2 凭证
└── Pagination: Response Contains Next URL（Link header）

Jira API 调用:
├── URL: https://[domain].atlassian.net/rest/api/3/search
├── Body: { "jql": "updated >= -1d ORDER BY updated DESC", "maxResults": 50 }
├── Authentication: Jira API Token（Basic Auth）
└── Pagination: Offset-Based（startAt + maxResults）