开发者平台Unkey近日撰文介绍了他们如何从零开始彻底重构整个API认证服务，从无服务器的 Cloudflare Workers 迁移至有状态的 Go 服务器。这一决策源于对无服务器架构限制的重新评估，这次重构最终带来了六倍的性能提升，并消除了此前占据工程团队大量精力的各种临时变通方案。
Unkey 联合创始人 Andreas Thomas 解释说，此次迁移的核心动因是延迟。他指出，当一项服务位于数千个应用的请求路径中时，“每一毫秒都至关重要”。团队发现，根本问题出在缓存上：Cloudflare 缓存在第 99 百分位的延迟超过 30 毫秒，远未达到其“总响应时间低于 10 毫秒”的目标。
由于无服务器函数本质上是无状态的，每次调用都会启动、处理请求、然后销毁，任何缓存数据都必须存储在外部并通过网络获取。Unkey 曾尝试多种缓解措施，包括构建多层的缓存系统、利用多种 Cloudflare 服务、优化缓存键设计、调整过期时间等，但始终无法绕开基本的物理现实。Thomas 总结说，“零次网络请求永远比一次更快。再多的外部缓存堆叠也无法突破这一根本限制。” 有状态服务器默认将热点数据保留在内存中，这是无服务器架构无论如何优化都无法比拟的优势。
此外，Unkey 还需要从无服务器函数中提取事件数据用于分析和日志记录。在传统服务器中，典型做法是在内存中批量收集事件，每隔几秒统一刷出。但在无服务器环境中，函数可能在完成调用后立即消失，因此必须在每次调用时立即刷出数据。
这促使 Unkey 开发了一个名为chproxy的自定义 Go 代理，用于在发送至分析服务 ClickHouse 前缓冲分析事件，这是因为 ClickHouse 在面对成千上万的小批量插入时性能极差。团队还为指标和日志构建了独立管道，通过中间Cloudflare Workers对事件进行解析和拆分后再转发。
最终，Unkey 发现自己不得不依赖 Durable Objects、Logstreams、Queues、Workflows 以及多个自建的有状态服务。Thomas 坦言，团队花在评估和集成各类 SaaS 产品上的时间，远超开发实际功能的时间。他们解决的是无服务器架构自身带来的问题，而非客户真正的需求。新系统现运行于 AWS Fargate 之上，并前置 Global Accelerator 以实现全球流量分发。不同之处在于，如今长期运行的 Go 进程可将数据保留在内存中，并自然实现事件的批处理。Thomas 表示，支撑原无服务器架构的所有辅助服务都不再需要，代码因此大幅简化，同时云账单也显著下降。
零次网络请求永远比一次更快。再多的外部缓存堆叠也无法突破这一根本限制。
— Andreas Thomas，Unkey 联合创始人
Thomas 强调，Cloudflare Workers 本身稳定可靠，平台表现如宣传所述。问题在于他所称的“无状态性带来的复杂性税”，Unkey 不得不自行构建和维护那些在有状态应用中本应免费获得的基础能力。
此次迁移还解锁了此前难以实现的功能。在 Cloudflare Workers 上，客户自托管几乎是不可能的，尽管它的运行时理论上开源，但本地部署极为复杂。如今，凭借单一的 Go 应用，客户只需一条 Docker 命令即可启动服务，不仅操作更简单，还能灵活满足企业严格的数据驻留要求。工程师现在可在笔记本电脑上数秒内运行完整的技术栈，无需再适配 Cloudflare 特有的 API。Unkey 计划明年推出一个部署平台，让客户能将服务部署在任意位置，进一步强化其产品的可移植性与简洁性。
Unkey 的转型恰逢多家知名公司开始质疑无服务器计算是否真能胜任高要求的生产负载。例如，Amazon Prime Video近期将其视频质量监控系统从分布式无服务器架构整合为单一进程，基础设施成本降低逾 90%。这一案例引发广泛关注，因为其出自推动微服务和无服务器（通过 AWS Lambda）普及的亚马逊云科技自身。该架构与 Unkey 高度相似：高吞吐、组件间紧密耦合。随着规模扩大，按调用付费的无服务器模式在经济上不再划算，而无状态设计反而使简单操作变得过度复杂。
在 LinkedIn 上，无服务器顾问Yan Cui针对Unkey的公告提出了疑问：“无服务器何时不能再带来助益？”他认为，无服务器适合早期增长阶段的架构，后期可能反而成为桎梏。在 Unkey 的案例中，他们遭遇了 Cloudflare Workers 平台固有的缓存与延迟瓶颈。工程师Luca Maraschi则更为直白，建议团队仔细审视自身流量模式，不要想当然地认为边缘计算或无服务器函数适用于所有工作负载。社区其他声音则更具同理心，Ten10 的 DevOps 顾问Max Hayward承认，内部常面临构建分布式架构的压力，但也坦言事后看来，更简单的方案或许才是更好的选择。
总而言之，Unkey的经历表明：无服务器仍是一种有价值的设计模式，特别适用于事件驱动或真正间歇性的工作负载。对于流量突发且无需持久化状态的服务，它能带来显著成本优势。然而，Unkey 与 Amazon Prime Video 的实践共同表明，对于高吞吐、低延迟要求严苛的服务，无状态模型可能并非最优解。
原文链接：
API Platform Unkey Ditches Serverless After Performance Struggles
