Kill Bill 0.24.22 介绍与选型指南

目标：全面认识 Kill Bill 这款开源订阅计费与支付平台，掌握其定位、技术架构、计费模型与功能特性，并能在与 Lago、BTCPay Server 及 Stripe Billing、Chargebee 等商业 SaaS 计费产品之间做出量化选型。本文为认知溯源篇，全部信息来自官方与公开渠道实查，来源与查询日期（2026-10-23）均已在文中标注，未做本地实测。

一、环境信息

本文为认知与选型篇，内容以公开资料溯源为主，关键取证信息与查询日期如下：

• 软件名称：Kill Bill（取自电影《杀死比尔》，官方口号「The Open-Source Subscription Billing & Payments Platform」）
• 开发与维护方：Kill Bill 团队（GitHub 组织 killbill），源码托管于 github.com/killbill/killbill
• 官网：https://killbill.io；官方文档站：https://killbill.io/docs/
• 最新稳定版本：0.24.22（GitHub Releases 实查，最新 tag 为 killbill-0.24.22，查询日期 2026-10-23；与 Docker Hub 官方仓库 killbill/killbill 的 0.24.22 标签相互印证，该标签构建于 2026-09-29，Docker Hub API 实查）
• 版本节奏（Docker Hub 标签时间线实查，查询日期 2026-10-23）：0.24.11（2024-10-22）→ 0.24.12（2025-01-23）→ 0.24.13（2025-08-11）→ 0.24.15（2025-11-14）→ 0.24.16（2026-04-16）→ 0.24.17（2026-05-06）→ 0.24.18（2026-07-02）→ 0.24.19（2026-07-24）→ 0.24.20（2026-08-07）→ 0.24.21（2026-09-09）→ 0.24.22（2026-09-29）。2026 年内已发布 8 个小版本，其中 2026 年 5—9 月连续 6 版，迭代节奏明显加快
• 配套管理界面 KAUI（Kill Bill Admin UI）：最新标签 4.0.31（2026-09-29 构建，Docker Hub API 实查，查询日期 2026-10-23），与核心 0.24.22 同日发布
• 开源许可证：Apache License 2.0（官方仓库声明，查询日期 2026-10-23）
• 主语言与技术栈：Java（核心）、Ruby on Rails（KAUI 管理界面）；数据库依赖 MySQL / MariaDB
• 社区活跃度（shields.io 徽章接口实查，查询日期 2026-10-23）：GitHub Stars 5.8k、Forks 971、提交活跃度 29 commits/月

💡 说明：本文引用的 Stars/Forks 数为 2026-10-23 实时快照，会随时间变化；选型时建议重新实查 https://img.shields.io/github/stars/killbill/killbill 徽章或仓库主页。

二、软件概述

Kill Bill 是一款面向订阅制商业模式的开源计费与支付平台：它把「客户订阅了什么（Catalog/订阅）→ 该收多少钱（发票）→ 钱怎么收回来（支付）→ 没收到怎么办（逾期/催收/坏账）→ 收错了怎么退（退款/退单）」这条完整的收入生命周期抽象成可编程的系统，通过 REST API 驱动，供 SaaS、电信、会员制、数字内容等业务系统集成。

与「只能生成账单」的轻量级发票工具不同，Kill Bill 的核心价值在于订阅状态机与自动化收入流程：

• 定价目录（Catalog）：用 XML/JSON 描述产品、计划、周期、试用期、阶梯价与多币种价格清单，计费引擎据此自动出账；
• 订阅生命周期（Entitlement/Billing）：处理创建、暂停、恢复、升级、降级、取消与对齐日（Alignment）等复杂状态迁移；
• 收款自动化：发票生成后按支付方法自动扣款，失败时按可配置的重试计划（Payment Retry）与逾期状态机（Overdue）执行催收；
• 支付网关无关：通过支付插件（Payment Plugin）对接 Stripe、PayPal、Adyen、Braintree 等网关，平台自身不碰真实资金通道，只做编排与记账。

Kill Bill 采用「开源核心 + 商业支持」模式：核心平台以 Apache-2.0 许可开源（官方仓库声明，查询日期 2026-10-23），官方同时提供商业托管与支持服务（Kill Bill Cloud，官网 killbill.io 自述）。在 GitHub 上有 5.8k Stars、971 Forks（shields.io 实查，查询日期 2026-10-23），属于计费赛道的成熟开源项目。

2.1 一句话理解 Kill Bill 的位置

如果把业务系统分层为「业务前台（你的应用）→ 计费中台（谁该付钱、付多少、付没付）→ 资金通道（Stripe/PayPal 等网关）」，Kill Bill 占据的是计费中台这一层：

• 向上通过 REST API 与 Java API 供业务系统调用（创建账户、订阅、查询发票余额）；
• 向下通过插件机制把实际扣款动作委托给支付网关插件执行；
• 旁路提供 KAUI 管理界面（Ruby on Rails 编写）供运营人员查账、调价、处理退款。

同平台已收录的 《FOSSBilling 0.8.8 介绍与选型指南》 处理的是「主机商/服务商的客户管理 + 开票 + 自动开通」场景，定位偏业务前台 + 简单账单；而 Kill Bill 定位是API 优先的订阅计费引擎，不含客户门户、工单、托管产品开通等业务功能，两者在计费深度与集成方式上差异明显，可对照阅读。

三、核心架构

Kill Bill 的架构可以概括为「一个 Java 核心 + 一个插件运行时 + 一个管理界面 + 一个数据库」，信息来源为官方文档站架构与部署章节（killbill.io/docs，查询日期 2026-10-23）。

3.1 总体分层

┌─────────────────────────────────────────────────────┐
│  你的业务系统 / KAUI 管理界面 / kb-cli 客户端          │
│         （经 REST API 或 Java API 调用）              │
└──────────────────────┬──────────────────────────────┘
                       │ HTTP :8080（路径前缀 /kb/）
┌──────────────────────▼──────────────────────────────┐
│              Kill Bill 核心（Java 进程）              │
│  ┌───────────┬───────────┬───────────┬───────────┐  │
│  │ 目录与订阅 │ 发票引擎   │ 支付编排   │ 逾期/账务  │  │
│  └───────────┴───────────┴───────────┴───────────┘  │
│  ┌─────────────────────────────────────────────┐    │
│  │       OSGi 插件运行时（支付/通知/汇率插件）     │    │
│  └─────────────────────────────────────────────┘    │
└──────────────────────┬──────────────────────────────┘
                       │ JDBC
              ┌────────▼────────┐
              │ MySQL / MariaDB │
              └─────────────────┘

各层职责：

• REST API 层：Kill Bill 以 HTTP 服务对外提供完整 REST API（默认监听 8080 端口、路径前缀 /kb/），覆盖账户、订阅、发票、支付、目录、插件等全部资源，官方维护 OpenAPI/Swagger 规范（官方文档 API 章节自述，查询日期 2026-10-23）；
• Kill Bill 核心：Java 单体进程，内含目录与订阅引擎、发票生成引擎（Invoice Generator）、支付编排器（Payment Orchestration）、逾期状态机（Overdue）与账务审计（Invoice/Payment Audit Log）等子系统；
• OSGi 插件运行时：Kill Bill 内嵌 OSGi 运行时，支付插件、通知插件、汇率插件等以 OSGi Bundle 形式热插拔加载（官方插件文档自述，查询日期 2026-10-23）；
• 存储层：MySQL 或 MariaDB 单库存储，官方发布 DDL 与升级脚本，无额外中间件依赖（官方部署文档自述）。

💡 技术拓展：OSGi 是 Java 生态的一种模块化框架标准（代表实现 Equinox、Felix），每个模块（Bundle）有独立类加载器与生命周期，支持运行时安装、启停、升级。与常见的「静态依赖 + 重启生效」的插件模型（如很多 Java 应用的 SPI）相比，OSGi 换取了热插拔与强隔离，代价是概念较重；与「独立进程插件」（如 HashiCorp go-plugin 那种子进程模型）相比，OSGi 插件与主进程同 JVM、调用无序列化开销，但故障隔离弱（插件异常可能影响宿主进程）。Kill Bill 选用 OSGi 是为了让支付网关插件可独立于核心发版升级。本文所述的 Kill Bill 即采用 OSGi 模型。

3.2 计费模型核心概念

Kill Bill 的领域模型是理解其架构的关键（概念定义来源：官方文档「Subscription Billing」与「Catalog」章节，killbill.io/docs，查询日期 2026-10-23）：

💡 说明：这些概念全部通过 REST API 操作与查询，且每个资源都有对应的 History 与审计记录，满足财务对账与合规追溯诉求（官方文档「Invoice」「Audit」章节自述，查询日期 2026-10-23）。

3.3 插件体系

Kill Bill 的扩展点几乎全部以插件形式提供（来源：官方插件目录 killbill.io/plugins 与文档「Plugin Development」章节，查询日期 2026-10-23）：

• 支付插件（Payment Plugin）：对接真实资金通道。官方维护的插件包括 Stripe、PayPal（Express Checkout / Payments Pro）、Adyen、Braintree、Klarna 等，另有「Bridge Plugin」用于自建通道；
• 通知插件（Notification Plugin）：订阅核心领域事件（发票生成、支付成功、订阅取消等），推送 Webhook 或执行自定义逻辑；
• 汇率插件（Currency Plugin）：多币种场景提供动态汇率；
• 权限/身份插件：对接外部认证体系。

插件以 OSGi Bundle（jar 包）形式上传部署，可独立于核心版本迭代，这是 Kill Bill 区别于多数同类开源计费项目的显著工程优势。

3.4 管理界面与客户端

• KAUI（Kill Bill Admin UI）：Ruby on Rails 编写的官方管理界面，支持账户/订阅/发票/支付的可视化管理、目录上传与插件管理，与 Kill Bill 同为开源项目（GitHub killbill/kaui 相关仓库，Docker Hub 官方标签 4.0.31，查询日期 2026-10-23）。KAUI 登录使用 Kill Bill API 凭据，官方示例环境的默认超级管理员为 admin/password（官方 Docker 部署文档默认值，查询日期 2026-10-23；生产环境必须修改）；
• kb-cli：官方命令行客户端，封装常用 REST 调用，用于脚本化运维与调试（官方 GitHub 组织发布）；
• Swagger UI：核心进程内置 API 文档与调试页（官方部署形态中位于 http://<主机>:8080/swagger/，官方文档自述）。

四、功能特性

以下特性清单综合官方文档站功能页与插件目录整理（killbill.io，查询日期 2026-10-23）：

1. 订阅计费引擎

   • 目录支持多版本并存、按时间生效切换，XML 与 JSON 两种描述格式；
   • 计费周期支持日/周/月/季/年，支持按月对齐（Billing Alignment）与按年折扣（年付价）；
   • 阶段化定价：试用期免费/打折、固定期限合同、折扣期、长期自动续费；
   • 升级/降级立即或周期生效，按比例计算退补（Pro-rated）。

2. 发票与账务

   • 自动按订阅生成发票，支持合并出账、外部关联发票（如从旧系统迁移的历史账）；
   • 账户级 Credit（账户余额抵扣）、发票调整、退款与退单全流程；
   • 发票模板可定制（HTML/XSL 模板），支持多语言与税号等字段；
   • 全量账务审计日志（每次余额变动/发票操作均有记录）。

3. 支付与催收

   • 支付编排：授权—捕获—退款—退单生命周期管理；
   • 失败重试计划可配置（官方默认三档重试节奏）；
   • 逾期状态机：逾期天数/金额触发「限制/取消」动作，可按账户禁用；
   • 支持银行转账等离线支付方式（手工核销）。

4. 平台能力

   • 多租户（Tenant）：一套部署服务多个业务线，目录/插件配置按租户隔离；
   • 多币种与动态汇率（Currency Plugin）；
   • 事件总线：领域事件可被通知插件消费，驱动业务系统联动；
   • 完整 REST API + Java API 双形态，所有界面可见操作均可 API 化。

五、快速开始（最小可用示例）

本节内容溯源自官方文档与官方部署材料，未做本地实测（本文为认知篇，实测部署与逐条命令回显见本专栏同批发布的部署篇），供读者预览最小可用形态。

5.1 最小部署形态

官方推荐的最快上手方式是使用官方发布的一键编排材料，同时启动三个服务（来源：Kill Bill 官方文档 Docker 部署指南，killbill.io/docs，查询日期 2026-10-23）：

• killbill/killbill：计费核心（Java 进程，REST API 监听 8080）；
• killbill/mariadb：官方维护的 MariaDB 数据库（含初始化 DDL）；
• killbill/kaui：管理界面（Ruby 进程，Web 界面监听 8080，部署时通常映射为其他端口）。

三个服务组成一个内部网络，Kill Bill 与 KAUI 通过 JDBC/HTTP 连接数据库与核心，数据落盘 MariaDB。官方编排文件同时提供了目录样例与默认管理员账户，启动后即可用 KAUI 或 REST API 创建第一个账户与订阅。

5.2 首次 API 调用形态

按官方 API 文档（killbill.io/docs API 章节，查询日期 2026-10-23）的示例形态，核心服务的 REST API 采用 HTTP Basic 认证（默认账号 admin，密码 password，生产环境必须修改），创建账户的请求形态如下：

POST /kb/1.0/kb/accounts
Authorization: Basic <base64(admin:password)>
Content-Type: application/json

{
  "name": "示例客户",
  "email": "customer@example.com",
  "currency": "USD"
}

官方默认凭据仅用于首次登录与验证部署，任何对外可达环境都应立即修改（API 凭据通过租户级配置管理，官方文档「Security」章节自述）。

💡 说明：本文不在此展开逐条命令与真实回显——认知篇以溯源为准，请以本专栏部署篇的实测输出为部署依据，避免按记忆抄写命令。

六、适用场景与限制

6.1 适用场景

综合官方文档与社区实践（killbill.io 官网案例页与文档，查询日期 2026-10-23），Kill Bill 适合：

1. SaaS 订阅计费：多档计划、试用期、升降级、年付折扣等典型 SaaS 计费诉求，API 优先便于嵌入自有业务后台；
2. 电信/物联网计费：需要目录化定价、周期出账、欠费停机的传统订阅场景；
3. 会员制/内容订阅：杂志、课程、社区会员等周期性收费，需要试用期与促销折扣；
4. 需要自持计费数据：财务合规、数据主权要求计费账务落在自己可控的数据库与机房；
5. 多业务线共享计费中台：多租户能力允许一套平台支撑多条产品线。

6.2 限制与不适用

• 不含前端业务功能：没有客户自助门户、商品橱窗、工单系统——这些属于业务前台（可对照 《FOSSBilling 0.8.8 介绍与选型指南》 的定位差异）；
• 不处理税务申报：税率计算与合规申报需要第三方税插件或外部服务（官方文档建议通过插件/外部引擎解决）；
• 不碰真实资金：必须至少对接一个支付插件与网关账户，平台自身无法直接收款；
• 有部署与集成成本：Java 进程 + 独立数据库 + 插件开发（Java 编码）对团队有技术要求，不适合只想「开箱即用收款」的小团队；
• 个人/小微记账不适用：家庭或个人收支管理请选用个人财务类工具（本平台已收录的 《Galette》 为会员捐助管理、另有个人记账类组件），Kill Bill 是企业级收入引擎而非记账本。

七、同类选型对比

7.1 开源同类量化对比

选取开源赛道中常被拿来与 Kill Bill 对比的三类项目：用量计费平台 Lago、比特币支付网关 BTCPay Server，以及计费赛道的商业 SaaS 代表。数据来源：shields.io 徽章接口与 GitHub Releases/Docker Hub（查询日期 2026-10-23）：

关键差异与解读：

1. 星数 ≠ 计费深度：Lago Stars 更高（11k），但它 2022 年才起步，主打用量计费；Kill Bill 自 2010 年代持续迭代至今，订阅状态机、逾期催收、审计账务的成熟度是其护城河；
2. BTCPay Server 与 Kill Bill 不是竞品：前者解决「去中心化收款通道」，后者解决「订阅收入生命周期」，支付场景里两者甚至可以共存（BTCPay 收加密货币、Kill Bill 做计费编排）；
3. 商业 SaaS 的对立面是数据主权与通道锁定：Stripe Billing 等免运维但按 GMV 抽成且数据在服务商侧，规模上来后成本与锁定风险显著；Kill Bill 的典型用户正是「要逃离这组约束」的团队。

7.2 版本节奏量化观察

以 Docker Hub 标签时间线为口径（查询日期 2026-10-23）：Kill Bill 在 2024-10 至 2025-08 之间发布间隔偏长（0.24.11→0.24.13 相隔 10 个月），而 2026 年节奏显著加快——4 月至 9 月间发布 0.24.16 至 0.24.22 共 7 个版本，平均每月 1 个以上，且 KAUI（4.0.15→4.0.31，2026-05-14 至 2026-09-29 发布 17 个标签）同步高频更新。对选型者的含义：项目处于活跃维护期且核心与界面双线高频发版，跟进升级的成本与收益都需要纳入运维规划（升级前关注官方 Release Notes 与数据库迁移脚本）。

7.3 「如果…则…」选型建议

• 如果你的核心诉求是 API 优先的订阅计费引擎、需要复杂订阅状态机与催收自动化、要求数据与账务完全自持 → 首选 Kill Bill；
• 如果你的业务是 AI/API 按调用量计费（用量计费为主）、模型经常变化、倾向轻量快速实验 → 优先评估 Lago；
• 如果你是 商家要自托管收款通道（尤其加密货币）、没有订阅计费诉求 → BTCPay Server；
• 如果团队没有 Java 运维能力、希望零运维快速上线、且业务规模愿意支付抽成 → 商业 SaaS（Stripe Billing/Chargebee/Zuora）；
• 如果你是主机商/服务商、要的是「客户区 + 开票 + 主机自动开通」一体化的业务前台 → 《FOSSBilling 0.8.8 介绍与选型指南》 所述的 FOSSBilling 更贴合，Kill Bill 不提供这些业务功能。

八、参考链接

1. 官网与产品介绍：https://killbill.io
2. 官方文档站（架构/目录/订阅/API/部署）：https://killbill.io/docs/
3. 源码仓库：https://github.com/killbill/killbill（许可证与 README 声明，查询日期 2026-10-23）
4. 官方插件目录：https://killbill.io/plugins/
5. 官方 Docker 镜像（核心）：https://hub.docker.com/r/killbill/killbill（版本时间线取证，查询日期 2026-10-23）
6. 官方 Docker 镜像（KAUI 管理界面）：https://hub.docker.com/r/killbill/kaui（查询日期 2026-10-23）
7. KAUI 管理界面源码：https://github.com/killbill/kaui（查询日期 2026-10-23）
8. 社区活跃度取证（shields.io 徽章）：https://img.shields.io/github/stars/killbill/killbill（查询日期 2026-10-23）
9. 同平台相关文档：《FOSSBilling 0.8.8 介绍与选型指南》（业务前台型计费系统的对照阅读）