Hotdry.
归档
systems-engineering

GitHub Actions控制平面计费系统架构设计：API网关使用量跟踪与实时计费引擎

深入解析GitHub Actions控制平面计费系统的架构设计，涵盖API网关使用量跟踪、实时计费引擎、配额管理与微服务集成，为构建企业级计费系统提供工程实践。

2025 年 12 月，GitHub 宣布了 Actions 定价的重大变革：从 2026 年 3 月 1 日起，所有 GitHub Actions 使用将收取每分钟 0.002 美元的平台费用。这一变化标志着 GitHub Actions 控制平面正式结束免费时代，无论用户使用 GitHub 托管 runner、自托管 runner 还是第三方 runner（如 Blacksmith），都需要为控制平面服务付费。

这一变革背后是 GitHub 对控制平面的直接货币化策略。正如 Blacksmith 博客所指出的，GitHub Actions 长期面临 "毕业流失" 问题：随着企业规模扩大，CI 工作负载变得更加庞大、复杂和昂贵，最终推动团队转向自托管或第三方 runner。此前，这种转变的一个重要副作用是，企业可以继续使用 GitHub Actions 控制平面，同时不为 CI 执行向 GitHub 支付任何费用。新的每分钟平台费用改变了这一局面，直接货币化控制平面，并为 GitHub 的 CI 收入设定了底线。

控制平面计费系统的核心架构

1. 系统边界与组件划分

GitHub Actions 控制平面计费系统需要处理的核心组件包括：

  • API 网关层：负责接收所有 Actions API 请求，进行身份验证、授权和请求路由
  • 使用量跟踪引擎：实时记录每个组织、仓库、工作流和 job 的使用量
  • 计费引擎：根据使用量计算费用，应用费率、折扣和配额
  • 配额管理系统：管理免费额度、并发限制和资源配额
  • 数据聚合管道：将原始使用量数据聚合为计费周期内的可计费单位
  • 计费 API：为外部系统提供使用量查询和计费信息访问接口

2. 数据流设计

典型的控制平面计费数据流如下：

用户请求 → API网关 → 使用量记录器 → 实时流处理 → 计费引擎 → 计费数据库
                                     ↓
                             配额检查器 → 配额数据库

每个组件都需要设计为高可用、可扩展且容错的系统。使用量记录器需要处理每秒数千甚至数万次的事件写入，而计费引擎需要保证最终一致性，确保计费数据的准确性。

API 网关使用量跟踪的实现策略

1. 请求标识与关联

API 网关需要为每个请求生成唯一的跟踪标识，并将其与以下维度关联：

  • 组织 ID：计费的主要实体
  • 仓库 ID：使用量的具体来源
  • 工作流 ID：CI/CD 流程的标识
  • Job ID：具体执行单元
  • Runner 类型：GitHub 托管、自托管或第三方
  • 执行时间：精确到毫秒的开始和结束时间
// 示例：使用量记录数据结构
{
  "request_id": "req_abc123",
  "org_id": "github_org_456",
  "repo_id": "repo_789",
  "workflow_id": "workflow_101",
  "job_id": "job_202",
  "runner_type": "self_hosted",
  "start_time": "2025-12-17T10:30:00.123Z",
  "end_time": "2025-12-17T10:31:30.456Z",
  "duration_ms": 90333,
  "resource_usage": {
    "cpu_seconds": 90.3,
    "memory_mb": 2048,
    "network_bytes": 1048576
  }
}

2. 实时流处理架构

使用 Apache Kafka 或 AWS Kinesis 作为事件流平台，构建实时处理管道：

API网关 → Kafka主题 → Flink作业 → 计费数据库
                   ↓
            Elasticsearch集群（实时监控）

实时流处理作业需要处理以下关键逻辑：

  • 时间窗口聚合：将毫秒级事件聚合为分钟级使用量
  • 重复检测：防止因重试或网络问题导致的重复计费
  • 异常检测：识别异常使用模式（如 DDoS 攻击或配置错误）
  • 配额检查：实时验证是否超出免费额度或并发限制

实时计费引擎的设计要点

1. 计费规则引擎

计费引擎需要支持灵活的计费规则配置：

billing_rules:
  - id: "actions_platform_fee"
    name: "GitHub Actions Platform Fee"
    description: "Per-minute platform fee for all Actions usage"
    rate: 0.002  # USD per minute
    unit: "minute"
    rounding: "ceil"  # 向上取整到最接近的分钟
    effective_date: "2026-03-01T00:00:00Z"
    
  - id: "github_hosted_runner"
    name: "GitHub Hosted Runner Compute"
    description: "Compute cost for GitHub-hosted runners"
    rate: 0.008  # USD per minute (after 39% reduction)
    unit: "minute"
    runner_type: "github_hosted"
    
  - id: "free_minutes"
    name: "Free Minutes Quota"
    description: "Free minutes included in plan"
    quota: 3000  # minutes per month
    reset_schedule: "monthly"

2. 计费周期处理

计费引擎需要处理复杂的计费周期逻辑：

  • 周期对齐：确保计费周期与日历月对齐
  • 按比例分配：处理跨计费周期的使用量
  • 费率变更：支持历史费率回溯计算
  • 折扣应用：批量折扣、承诺使用折扣等

3. 数据一致性保证

计费系统必须保证数据的最终一致性：

  • 幂等操作：所有计费操作必须是幂等的
  • 补偿事务：实现 Saga 模式处理跨服务事务
  • 对账系统：定期运行对账作业，验证计费数据的准确性
  • 审计日志：记录所有计费变更，支持审计和调试

配额管理与监控系统

1. 配额管理架构

配额管理系统需要支持多级配额控制：

组织级配额 → 仓库级配额 → 工作流级配额
    ↓            ↓            ↓
并发限制    分钟配额    资源限制

关键设计考虑：

  • 实时配额检查：在 API 网关层进行配额预检查
  • 软限制与硬限制：支持警告阈值和硬性限制
  • 配额借用：允许临时超出配额，后续周期扣除
  • 配额预警：提前通知用户接近配额限制

2. 监控与告警系统

构建全面的监控体系：

  • 使用量仪表板：实时显示组织、仓库、工作流的使用量
  • 成本分析工具：按团队、项目、环境分析 CI 成本
  • 异常检测：自动检测异常使用模式
  • 预算告警：当预计成本超过预算时发送告警
# 示例：预算告警规则
budget_alerts = [
    {
        "org_id": "github_org_456",
        "budget_limit": 1000,  # USD per month
        "alert_thresholds": [0.5, 0.8, 0.9, 1.0],
        "notification_channels": ["email", "slack", "webhook"],
        "rollup_period": "daily"  # 每日汇总检查
    }
]

工程实践与挑战

1. 高并发处理

GitHub Actions 每天处理数百万个 job，计费系统需要处理极高的并发：

  • 分片策略：按组织 ID 或时间分片处理使用量数据
  • 批量处理：将小事件聚合成批量处理，减少数据库压力
  • 读写分离：使用读写分离的数据库架构
  • 缓存策略：缓存频繁访问的配额和费率数据

2. 数据准确性保证

计费数据的准确性至关重要：

  • 双重写入验证：同时写入两个数据存储，定期比对
  • 端到端测试：模拟完整的使用量到计费流程
  • 对账作业：每日运行对账作业，验证计费准确性
  • 人工审核流程：为争议计费提供人工审核机制

3. 系统可观测性

构建全面的可观测性体系：

  • 分布式追踪：使用 OpenTelemetry 追踪跨服务调用
  • 指标收集：收集关键业务和技术指标
  • 结构化日志：所有操作记录结构化日志
  • 性能监控：监控系统延迟、吞吐量和错误率

4. 安全与合规

计费系统需要满足严格的安全和合规要求：

  • 数据加密：所有敏感数据在传输和静态时加密
  • 访问控制：基于角色的细粒度访问控制
  • 审计追踪：记录所有数据访问和修改
  • 合规认证：满足 SOC 2、ISO 27001 等合规要求

未来演进方向

1. 预测性计费

基于历史使用模式预测未来成本：

  • 时间序列分析：使用 ARIMA 或 LSTM 模型预测使用量
  • 季节性模式识别：识别工作日 / 周末、发布周期等模式
  • 成本优化建议：基于预测提供成本优化建议

2. 精细化计费

支持更精细的计费维度：

  • 按资源类型计费：CPU、内存、存储、网络分别计费
  • 按优先级计费：高优先级 job 收取溢价
  • 按环境计费：生产、预发布、开发环境不同费率

3. 生态系统集成

与 CI/CD 生态系统深度集成：

  • 插件架构：支持第三方计费插件
  • API 标准化：提供标准化的计费 API
  • 市场集成：与云市场集成，支持一键购买

总结

GitHub Actions 控制平面计费系统的设计是一个复杂的系统工程挑战。它需要在保证高可用性、可扩展性和数据准确性的同时，处理极高的并发和复杂的业务逻辑。通过采用现代化的架构模式，如事件驱动架构、微服务、实时流处理和最终一致性，可以构建出既可靠又灵活的计费系统。

对于正在构建或优化自身计费系统的团队，以下关键建议值得参考：

  1. 从简单开始：先实现核心计费逻辑，再逐步添加高级功能
  2. 设计可扩展：确保架构可以水平扩展，应对增长的使用量
  3. 重视数据质量：建立完善的数据验证和对账机制
  4. 投资可观测性：全面的监控和告警是系统可靠性的基础
  5. 保持灵活性：计费规则和费率可能频繁变更，系统需要支持快速配置

随着云服务和 SaaS 产品的普及，计费系统正从边缘功能转变为核心竞争优势。一个设计良好的计费系统不仅能准确收费，还能提供有价值的业务洞察，帮助用户优化使用，最终提升客户满意度和业务增长。

资料来源：

  1. Blacksmith 博客：The GitHub Actions control plane is no longer free (https://www.blacksmith.sh/blog/actions-pricing)
  2. GitHub 社区讨论：Billing API returns zero usage (https://github.com/orgs/community/discussions/156125)
  3. Moesif 文档：Getting started with API Monetization (https://moesif.com/docs/getting-started/api-monetization)
查看归档