Lago 开源用量计费平台十分钟跑起来再看懂它怎么工作【免费下载链接】lagoOpen Source Metering and Usage Based Billing API ⭐️ Consumption tracking, Subscription management, Pricing iterations, Payment orchestration Revenue analytics项目地址: https://gitcode.com/GitHub_Trending/la/lagoLago 是一个开源计量和基于使用量的计费平台你把 API 调用、token、计算时长这些用量事件发过去它负责聚合成计费指标、套用你的定价规则、生成发票并对接收款。如果你一直靠手写代码解决“按量收费”这件事Lago 就是把这条链路做成一套可以自托管的系统。快速上手用内置演示看到第一笔计费一条命令跑通 AI 计费演示理解 Lago 最短的路径是 examples/agentic-ai-demo/ 里的演示。clone 仓库后一条命令./examples/agentic-ai-demo/run.sh # 启动演示 ./examples/agentic-ai-demo/run.sh --cleanup # 结束后清掉容器和数据它只需要 Docker、curl、jq。脚本会起一个独立的 Lago创建临时组织发 3 个模拟 AI 请求每个各带一条输入 token、一条输出 token 事件再通过 API 取回用量独立对账金额甚至重发同一个 transaction_id 来验证幂等——用量不会被重复计费。跑完打开 http://localhost:8080用 README 里给的演示账号登录就能在 UI 里看到客户、订阅、用量事件和最终扣费。事件 → 计量 → 定价 → 计费这条链路一次看全。用 docker compose 起完整服务真实使用则用根目录的 docker-compose.yml 起全套服务唯一的额外动作是生成一个 RSA 私钥Webhook 签名用git clone --depth 1 https://gitcode.com/GitHub_Trending/la/lago cd lago echo LAGO_RSA_PRIVATE_KEY\$(openssl genrsa 2048 | openssl base64 -A)\ .env docker compose up -d跑起来的东西dbPostgreSQL、redis、migrate迁移、apiRails API3000 端口、api-workerSidekiq 后台任务、api-clockClockwork 定时调度、frontUI80 端口、pdf发票 PDF 生成。想在启动时自动创建组织和 API key在 .env 里设LAGO_CREATE_ORGtrue并配好LAGO_ORG_NAME等变量即可。仓库导览核心代码到底在哪三块主体加一圈配套api/整个系统的核心Ruby on Rails处理 API、计费逻辑和后台作业。它是指向独立 lago-api 仓库的 git submodulefront/Web 界面同样是 submodule本质由 nginx 伺服静态资源events-processor/用 Go 写的独立高吞吐事件处理服务下面重点讲外围还有 connectors/SQS/Kinesis/HTTP 接入、deploy/生产用 compose 文件、extra/ClickHouse、Kafka Connect、nginx TLS 配置、docker/Dockerfile 与启动脚本。读代码 80% 的精力花在 api/纯跑通则只需要 compose 文件。它为什么这样设计两个值得看懂的取舍主 API 只接单重活全丢给 worker结论先说Rails API 本身几乎不做计费计算它收到事件后把作业塞进 Sidekiq 队列干活的是 worker。原因很直白——计量事件量不可预测如果在请求里同步算账一个慢作业比如生成一张大发票就能把 API 拖住。所以 Lago 把作业分成 events、billing、webhook、pdfs 等队列默认由一个 api-worker 全扛量上来后打开布尔环境变量比如 SIDEKIQ_EVENTStrue对应作业就自动改走独立队列可以单独扩副本。这就是为什么 docker-compose.yml 里专职 worker 服务大多被注释掉小规模部署默认 worker 够用量大了再逐个解开。高吞吐事件处理是独立的 Go 服务当事件量大到 Rails 链路吃不住events-processor/ 就是干这个的它从 KafkaRedpanda消费原始事件做订阅匹配、charge 计算和结果缓存把加工后的事件写回其他 topic处理失败的事件进死信队列。配套地connectors/ 负责把 SQS、Kinesis 或 HTTP 直推的事件搬进 Kafka也就是说你不走同步 API 也能做计量。这笔交易换来两样东西热路径事件接入 实时用量不再压在主 API 上Postgres 只管业务数据客户、订阅、发票海量用量明细由 ClickHouse 承接查询。代价是得额外运维一套 Kafka 加 ClickHouse——events-processor 的 README 也明说它面向高量场景、需要配套 ClickHouse 和 Redpanda。适合谁不适合谁这些情况放心用产品有“用量”概念要收费API 调用、token、GPU/CPU 时长、存储、席位、活跃用户想让计费和收款方解耦Lago 管计量、定价、额度、发票收款交给 Stripe/Adyen/GoCardless商品目录以 Lago 为准而不是支付方你是平台想给客户做白牌计费能力Embedded 模式数据必须自托管且有人愿意维护 Postgres Redis Kafka/ClickHouse这套栈这些情况建议绕开只需要“订阅 卡支付”团队没人维护这一堆服务——docs/architecture.md 里的最小生产配置也是四类服务、每个带副本数已经用 Stripe Billing 且想沿用它的商品模型——Lago 是独立的计费引擎刻意没建在 Stripe 目录体系上用量极小每月几十个用户开源计费平台的运维成本会高于它帮你省的账单⚠️ 生产部署前值得知道的几件事Sidekiq 默认不重试retry: 0失败作业直接进死信队列兜底靠 clock 的定期补偿任务如失败发票每 15 分钟重试一次。作业挂了别指望自动恢复盯死信队列和队列深度对应指标在 docs/monitoring.md生产上至少把 events、billing、webhook、pdfs 的专职 worker 打开compose 文件里已备好服务定义解开注释即可Webhook 签名有 HMAC 和 JWT 两种按 endpoint 配置启动时生成的 RSA 密钥就是给 JWT 签名用的想从源码跑开发环境额外依赖 Traefik、mkcert、ClickHouse 等步骤见 docs/dev_environment.md比 compose 部署繁琐不少Lago 把你过去手写的“事件到收款”链路做成了一套可自托管的独立系统docker compose 一条命令能跑但生产要运维一整个服务集群这份成本得自己掂量。有按量计费场景的话从内置演示开始一小时能比十页文档看懂它得多。【免费下载链接】lagoOpen Source Metering and Usage Based Billing API ⭐️ Consumption tracking, Subscription management, Pricing iterations, Payment orchestration Revenue analytics项目地址: https://gitcode.com/GitHub_Trending/la/lago创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考