企业官网建设流程全解析

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/lago

Lago 是一个开源计量和基于使用量的计费平台：你把 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

跑起来的东西：db（PostgreSQL）、redis、migrate（迁移）、api（Rails API，3000 端口）、api-worker（Sidekiq 后台任务）、api-clock（Clockwork 定时调度）、front（UI，80 端口）、pdf（发票 PDF 生成）。想在启动时自动创建组织和 API key，在 .env 里设LAGO_CREATE_ORG=true并配好LAGO_ORG_NAME等变量即可。

仓库导览：核心代码到底在哪

三块主体加一圈配套

• api/：整个系统的核心，Ruby on Rails，处理 API、计费逻辑和后台作业。它是指向独立 lago-api 仓库的 git submodule
• front/：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_EVENTS=true），对应作业就自动改走独立队列，可以单独扩副本。这就是为什么 docker-compose.yml 里专职 worker 服务大多被注释掉：小规模部署默认 worker 够用，量大了再逐个解开。

高吞吐事件处理是独立的 Go 服务

当事件量大到 Rails 链路吃不住，events-processor/ 就是干这个的：它从 Kafka（Redpanda）消费原始事件，做订阅匹配、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