关于我们
我们在造一个自己一直想买却没买到的边缘层
AnyLB 的起点很简单：我们认识的每一个平台团队，最后都会在 Cloudflare 之上重写同一套调度、故障切换与日志代码——写得勉强，写的时间是凌晨三点，而且比真正的需求早了半年。我们把这段代码做成了产品。
让全球 API 基础设施变成一个配置项，而不是一个项目
过去十年里，想让 API 面向全球用户，基本只有两条路：要么接受单地域部署，要么花掉一个季度去做 Anycast、BGP 和跨地域故障切换。当你的客户分布在二十个国家、延迟预算只有几十毫秒时，这两条路都不可接受。
AnyLB 把这件事压缩成一次 CNAME 变更加一份配置文件。我们不自己铺硬件——Cloudflare 已经运营着我们需要的网络。我们真正构建的是网络之上的判断力：这个请求该由哪个源站响应、什么时候该果断放弃它，以及事后如何精确证明当时发生了什么。
今天的我们
- 120 亿
- 每日调度的请求量
- 99.99%
- 近 12 个月网络可用性
- 125+
- 边缘网络服务的国家和地区
- 7×24
- 跟随太阳的工程支持
我们的工作方式
我们坚持的四条原则
任何一个功能要上线，都得先通过这几道检验。
在关键之处保持朴素
负载均衡属于基础设施。我们交付可预期的行为、写清楚每一条文档，绝不在季度中途推翻模型。
默认可观测
如果仅凭日志无法解释一次调度决策，这个功能就不算完成。可解释性和能力本身一起交付。
克制边界，而非堆叠功能
我们只做面向 API 的 HTTP/HTTPS 负载均衡。把四件事做到极致，胜过把四十件事做得勉强。
延迟本身就是产品
我们增加的每一毫秒，用户都能感知。我们衡量增量延迟的认真程度，和衡量可用性一样。
我们的历程
从内部工具到托管平台
在成为产品之前，AnyLB 先是一种被反复验证的做法。
- 2023
同一个模式
创始团队长期负责 API 平台，每加入一家公司，都会在 Cloudflare 之上重写一遍同样的调度与故障切换逻辑。
- 2024
内部工具
第一个版本以内部服务的形式在三家公司运行，每月安静地调度数十亿次请求。
- 2025
走向平台化
健康检查、故障切换策略与逐请求日志被整合为一个托管产品，并提供 API、命令行与 Terraform Provider。
- 2026
正式开放
AnyLB 面向所有客户开放，提供免费版、带 SLA 的商务版，以及有完整文档支撑的企业版接入路径。