揭秘Neon的湖基架构：无状态计算与单元隔离如何在AWS宕机中存活

Neon的解法是，将所有持久化状态转移到一个独立的、跨可用区冗余的存储层。Neon的Postgres计算节点在本地磁盘上不保留任何数据；它们仅负责处理查询，并将预写日志（WAL）实时流式传输给一组负责持久化存储的Safekeeper和Pageserver节点 。这意味着计算节点宕机只会导致片刻的查询中断，而绝不会丢失任何数据。一个全新的计算实例可以瞬间挂载到相同的存储历史记录上，从中断处无缝接管工作，完全无需等待卷挂载或漫长的崩溃恢复 。

这在AWS无法分配新实例时，带来了极其务实的优势：Neon不必在压力峰值时拼命呼叫EC2 API来替换死掉的节点。它只需从预热的、已经处于运行态的实例池中取出一个替换品，然后将其连接到现有的存储状态即可。云厂商的控制面受损，降格为一个运维上的小麻烦，而非数据可用性上的紧急危机。

细胞化隔离：一个区域不再等同于一个故障域

Neon的区域部署并非铁板一块。每个区域由一个或多个规格相同的“细胞（Cell）”构成，每一个细胞都捆绑了自有的Kubernetes控制平面、计算池和存储资源 。这种隔离设计意味着，某个细胞内发生的故障——不论是由云厂商宕机引起、还是由软件缺陷或资源耗尽导致——都不会传播到同一区域内的其他细胞。

在2026年5月AWS us-east-1宕机期间，云厂商的故障具体体现在无法分配新实例和IP地址 。对于单体架构而言，这无疑是一次区域级全灭。但在Neon的细胞化设计中，只有那些预先分配的计算缓冲区耗尽了的细胞受到了影响。其他保有充足预分配实例缓冲区的细胞，则继续保持平稳运行 。

这一结果正源自深思熟虑的设计抉择：细胞被精确地规划大小，以确保没有任何单个细胞的资源瓶颈会成为整个区域的瓶颈。早先架构演进的教训也印证了这一点。在转向细胞化架构之前，Neon在每个区域运行单个Kubernetes集群，测试表明，一旦并发数据库超过1万个，服务就会因EKS etcd内存上限（8GB）、网络配置限制（us-east-1约能承载1.2万个并发库）、以及Kubernetes API速率限制而出现严重退化 。细胞化架构则通过将负载分散到多个独立、互不交互的细胞，彻底移除了这种单集群天花板。

通过预分配与自定义虚拟化降低云依赖

Neon与底层云厂商之间刻意保持着一种“安全距离”。当需要启动一个数据库时，Neon并不会实时呼叫EC2的API，而是预先分配好由大型实例（通常是裸金属）组成的资源池，并保持充足的缓冲容量，以平稳吸纳云厂商的分配中断 。这个缓冲池不是为了给大客户走后门用的小型温热池，而是整个系统调度计算资源的结构性基石。

在这些预分配的实例之上，Neon运行着一套自研的、支持垂直自动伸缩的虚拟化层，用以将多个Postgres实例紧凑地打包在一台物理宿主机上。此举同时绕开了两类云厂商依赖：虚拟机分配API（实例已经是开机运行的）和块存储挂载路径（Neon的计算节点根本不使用云厂商的块存储卷） 。

数据持久性也遵循相同的逻辑。所有数据库内容都驻留在Neon自建的、跨可用区容灾的存储服务中，底层依托的是Amazon S3或Azure Blob Storage这类对象存储，而非云厂商的块设备 。对象存储的API在故障模式上与虚拟机分配API截然不同，而在历次区域级控制面宕机中，对象存储的持久性已被实践证明要稳定得多。当某个Pageserver或Safekeeper节点挂掉时，不会有任何持久化数据丢失——另一节点可以立即通过WAL和对象存储重建出所需的数据页 。

跨可用区存储是标配，而非增值付费项

在许多托管数据库服务中，多可用区存储复制是一项需要额外掏钱并显式配置的高级功能。而在Neon，无论用户身处哪个定价层级，每个数据库底层都是依托于分布式的、跨可用区冗余的对象存储，并配有遍布多个可用区的NVMe SSD缓存 。这解除了跨区物理复制作为一个独立痛点的存在，因为存储层本身就内建了复制。

WAL复制的设计提供了具体的持久性保障：写入操作会以仲裁模式同步复制到Safekeeper集群（一种已对外披露的配置是六副本写入，四副本确认即可达成仲裁），这意味着即使整整一个可用区加上一台额外副本同时宕机，也能保证数据不丢 。这种保障并非纸上谈兵，而是写路径上硬性的先决条件——只有满足了仲裁写入，事务才能向客户端回应“成功”。

就计算可用性而言，共享存储模型还提供了传统主从架构无法比拟的优势：由于所有计算实例共享同一份持久存储历史，替换上来的新计算节点根本不需要通过物理复制来追赶进度。它直接挂载到现有的历史上，并能在几秒到几分钟之内根据工作负载以及缓存数据集的大小快速开始服务 。

可用性目标与实际数据

已公开的可用性SLI显示，Neon湖基架构的可用性落在约99.93%至99.96%的区间内 。这些数字背后，是计算故障通过替换无状态节点（而非向空闲热备作故障转移）来恢复，以及存储持久性通过对象存储支撑的复制（而非同步磁盘镜像）来达成的一整套设计。

Neon自身的事故记录为这些目标提供了有价值的校准参考。2025年5月，在us-east-1先后发生了两次总共持续5.5小时的故障，期间用户无法启动或创建不活跃的数据库，但活跃数据库完全不受影响 。该事故的根因是Kubernetes子网IP地址耗尽，起因是控制面过载叠加了AWS CNI的配置偏差——这暴露了一个当时架构下的规模化瓶颈，而细胞化架构正是为了从设计上消灭此类瓶颈才得以推出 。更早的2024年8月，us-east-1一台EC2实例故障导致Pageserver宕机，约0.4%的客户项目受扰长达两小时；因为Pageserver相当于一层以S3为持久化后端的本地磁盘缓存，丢失Pageserver意味着暂时性的不可用，而非永久性数据缺失 。

这些事故警示我们，无状态计算与共享存储固然能降低故障的严酷程度，却不能完全消灭故障。该架构的核心韧性属性——计算故障零数据丢失、通过重挂载自动恢复、细胞边界的爆炸半径控制——在真实故障条件下经受住了考验，但这套系统也并非免疫于软件缺陷、资源耗尽或那些尚未彻底解耦的云厂商依赖（比如IP地址分配）。

韧性测试：Neon如何验证设计

Neon工程博客称，系统会针对真实故障场景进行测试，包括模拟云厂商分配中断以及整个可用区断连 。这些测试充分锻炼了预分配实例缓冲区和细胞隔离边界，也就是理论上应能限制爆炸半径的机制。Neon描述的混沌工程实践，遵循的是业界通行的范式：先定义系统在故障下应如何表现的“稳态假设”，接着注入受控故障（如断开整个可用区或耗尽计算缓冲池），然后观测假设是否成立，最后根据结果迭代改进架构 。

虽然Neon尚未公布过详尽的混沌工程方法论或超出架构概览博客层面的具体实验结果，但已有证据显示，其测试直指该架构最引以为傲的韧性声明。Neon所描述的测试——模拟云厂商分配中断和可用区故障——正是无状态计算和细胞隔离相较于传统托管数据库架构最能打出压倒性优势的具体场景。而2026年5月AWS宕机，实质上相当于对这些机制进行了一次未经计划的实战验证，其所呈现的受控爆炸半径，与预分配和细胞隔离被设计来达成的效果完全一致。

对评估Serverless Postgres的团队意味着什么

Neon的架构提供了一种明确的韧性取舍：它坦率地接受了计算层的易逝性，并用快速替换来应对，而不是不惜一切代价维持单节点存活；与此同时，它在存储持久性和故障域隔离上投入了巨资。对于那些可以容忍偶尔几秒到几分钟查询中断、且首要关切是数据安全性的工作负载，这种模型消灭了持有热备节点的成本与复杂度。对于要求零中断的连续性查询场景，虽可配置多计算副本的高可用方案，但会伴随更高的成本开销。

该架构也迫使人们对云依赖做一次诚实的清算。没有任何数据库服务能真正脱离底层云厂商而独立存在，但耦合度的深浅却天差地别。Neon决定预分配容量、使用自研虚拟化层、并将数据存入对象存储而非块设备，这些抉择共同大大缩减了数据库层正常运转时，需要云厂商API保持可用的接触面积。这个更窄的依赖面，在2026年5月AWS宕机中收到了回报：那些保有充足预分配缓冲区的细胞，在令耦合更紧密的架构遭遇区域级瘫痪的故障面前，保持了持续服务。

对于正架构在Serverless基础设施上的团队，Neon的实践道路说明了一条关键原则：爆炸半径的控制绝非事后诸葛亮——它是远在宕机发生之前，就镌刻在存算边界与故障域结构里的架构级产物。