Neon Lakebase 架構拆解：無狀態計算同細胞隔離點樣頂住 AWS 大死機

Neon 就掉轉玩法：所有需要長期保留嘅狀態，都搬去一個獨立嘅、跨可用區嘅儲存層。Neon 嘅 Postgres 計算節點本地 disk 係唔會 hold 任何數據嘅；佢哋淨係負責處理查詢，並將 WAL（Write-Ahead Log）記錄串流送去一組叫做「safekeeper」同「pageserver」嘅節點，由呢啲節點去長期保存每一個改動 。咁樣代表計算節點死咗，頂多係查詢停一停，零數據損失。一隻全新嘅計算 instance 可以即刻掛載返同一條儲存歷史，由死之前嗰刻繼續做嘢，完全唔使等 detach/attach volume 或者跑 crash recovery 。

喺 AWS provisioning 死機嘅實際場景度，呢個設計嘅好處就好明顯：Neon 唔需要喺壓力下仲去 call EC2 API 嚟換走死咗嘅計算節點。佢可以喺一個預先煲定嘅、已經行緊嘅 instance pool 度，抽一隻替補出嚟，掛返去現有嘅儲存狀態就搞掂。雲端供應商 control plane 出事，對佢嚟講只係運作上唔方便，而唔係一個數據可用性嘅緊急災難 。

細胞式隔離：一個區域唔等於一個故障域

Neon 嘅區域部署絕對唔係 monolithic。每個 region 係由一個或者多個形狀一樣嘅「細胞」（cell） 組成，而每個細胞都會綁定自己嗰套 Kubernetes control plane、計算池同儲存資源 。呢種 compartmentalization，代表一個細胞入面嘅 failure——無論係雲死機、軟件 bug 定係資源耗盡——都唔會傳染去同一個 region 嘅其他細胞度。

喺 2026 年 5 月 AWS us-east-1 死機嘅時候，雲端供應商嘅故障係集中喺「開新 instance」同「派 IP 地址」呢兩樣嘢度 。如果係 single-cell 架構，呢單嘢就即係成個 region 攬炒。但喺 Neon 嘅細胞式設計入面，只有嗰啲用盡咗預留計算 buffer 嘅細胞先會受影響。其他 keep 住足夠已經行緊嘅 instance buffer 嘅細胞，就繼續無間斷運作 。

呢個結果係反映咗一個深思熟慮嘅設計取捨：每個細胞嘅大細係精心計算過，確保唔會有任何單一細胞嘅資源上限變成全區嘅樽頸。其實呢個轉向細胞式架構嘅決定，背後有之前撞過板嘅教訓。喺轉用細胞式隔離之前，Neon 每個 region 係行緊一個單一嘅 Kubernetes cluster，佢哋嘅測試發現，當同時運行超過 10,000 個資料庫時就會出現服務降級——原因包括 EKS etcd 記憶體上限（8GB）、網絡設定限制（us-east-1 上限約 12,000 個同時活躍嘅資料庫）、同埋 Kubernetes API rate limiting 。細胞式架構就係將負載拆散落多個獨立互不干涉嘅細胞度，徹底斬斷呢啲單一 cluster 嘅天花板。

透過預留容量同自訂虛擬化，減少對雲供應商嘅依賴

Neon 同底下嗰浸雲供應商嘅關係，係刻意保持一種「疏離」嘅狀態。佢唔係每次有 database 要起機就逐次 call EC2 API，而係事先預留晒大規模——多數係 bare-metal——嘅 instance 池，並且長期保持容量 buffer 去吸收 provisioning 死機嘅衝擊 。呢個 buffer 唔係用嚟俾貴賓級租戶嘅小型暖池，而係成個系統調度計算嘅結構性組件。

喺呢堆預留咗嘅 instance 之上，Neon 再行緊佢哋自己嗰套垂直自動擴展嘅虛擬化層（vertically autoscaling virtualization layer），將多個 Postgres instance 打包放喺同一部物理主機度。咁樣做一次過繞過咗兩樣對雲供應商嘅依賴：VM provisioning API（因為 instance 一早已經行緊）同埋 block storage attachment 路徑（因為 Neon 嘅計算節點根本唔使用雲端 block volume）。

數據耐用性都係同一個套路。所有數據庫內容都係寄住喺 Neon 自己嗰套跨區高韌性嘅儲存服務度，底層係靠對象儲存（例如 Amazon S3 或者 Azure Blob Storage），而唔係雲端 block device 。對象儲存嘅 API 同 VM provisioning API，佢哋嘅故障模式係唔同嘅，而且實戰經驗入面，對象儲存喺區域 control plane 死機期間嘅耐用性，係大幅地更加穩陣。當一個 pageserver 或者 safekeeper 節點死咗，係冇長期狀態會損失嘅——另一隻節點可以靠 WAL 同對象儲存重構返需要嘅數據頁面 。

跨可用區儲存係地基，唔係奢侈附加功能

喺好多 managed database 服務度，「Multi-AZ 儲存複製」係要課金先有嘅功能，仲要自己特登去 set。喺 Neon 度，無論你係咩 plan，每個 database 底層都係行緊分佈式、跨可用區嘅對象儲存，再加埋跨多個可用區嘅 NVMe SSD cache 。咁樣根本上就將跨區物理複製呢個 concern 消滅咗，因為儲存層本身就已經自帶複製。

WAL 複製嘅設計提供咗好具體嘅耐用性保證：寫入係同步複製去 safekeepers，並且設有法定人數（quorum）要求（一個公開嘅設定係六向複製，要求四對六嘅寫入法定人數），意思係就算冧咗成個可用區再加多一隻 replica，數據都唔會冇咗 。呢個唔係理論上嘅韌性，而係寫入路徑嘅一個特性，必須滿足咗先會向客戶端確認交易。

特別係講到計算可用性嘅時候，呢個共享儲存模型有一個傳統「主-備援」架構冇得比嘅優勢：就係因為所有計算 instance 都係共享同一條耐久之儲存歷史，一隻替補嘅計算節點唔需要靠物理複製去追趕進度。佢只需要駁返去現有嘅歷史，然後喺幾秒到一兩分鐘之內（取決於工作負載同快取工作集嘅大細）就可以開始 serve queries 。

可用性目標同實際數據

Neon 公開嘅 lakebase 架構可用性 SLI 大約係 99.93% 至 99.96% 呢個範圍 。呢個數字反映出嘅設計哲學係：計算故障透過更換無狀態節點嚟恢復，而唔係做 failover 去一隻 hea 緊嘅熱備援機；儲存耐用性係靠對象儲存 backed 嘅複製去實現，而唔係同步 mirror 磁碟。

Neon 自己嘅事件記錄可以俾我哋對呢啲目標校準一下。2025 年 5 月喺 us-east-1 發生嘅事故，總共造成咗 5.5 個鐘嘅 database 啟動同建立操作中斷，但係已經行緊嘅 database 完全冇受影響 。根本原因係 Kubernetes subnet 嘅 IP 地址用晒，觸發點係 control plane overload 同 AWS CNI 設定錯誤——呢次事件暴露咗一個規模限制，而細胞式架構正正就係為咗防止呢種情況而設計出嚟 。早少少，喺 2024 年 8 月，us-east-1 嘅一次 pageserver 故障影響咗大約 0.4% 嘅客戶 project，最長中斷兩個鐘頭；原因係有一部 EC2 instance 死咗。因為 pageserver 本質上係一個背後有 S3 做靠山嘅本地磁碟快取，冇咗一個 pageserver 只係代表暫時嘅不可用，而唔係永久數據損失 。

呢啲事件講緊嘅重點係：無狀態計算同共享儲存的確可以減低故障嘅嚴重性，但唔係令系統金剛不壞。個架構嘅韌性特質——計算死機唔會冇咗數據、可以即刻掛返新計算節點自動恢復、爆炸範圍受細胞界限困住——係頂得住真實故障環境考驗嘅，但個系統仲係會受到軟件缺陷、資源耗盡、或者未完全斬纜嘅雲端供應商依賴（例如 IP 地址分配咁）所影響。

韌性測試：Neon 點樣驗證個設計

Neon 嘅工程 blog 度講過，系統係會測試對住真實世界嘅故障場景，包括模擬雲端供應商 provisioning 死機同成個可用區斷線 。呢啲測試就係用嚟 chur 嗰啲預留 instance buffer 同細胞隔離邊界，睇下係咪真係限制到爆炸半徑。Neon 描述嘅混沌工程（Chaos Engineering）套路，同業界嘅普遍做法係一致嘅：先定義系統喺故障下應該點樣表現嘅「穩態假設」（steady-state hypothesis），注入一個受控嘅故障（例如 disconnect 成個 AZ、chur 爆計算 buffer），觀察個假設企唔企得住，唔掂就修改架構 。

雖然 Neon 冇公開好詳細嘅混沌工程方法論或者特定實驗結果（除咗嗰篇架構 blog overview 之外），但現有證據顯示，佢哋嘅測試係直接瞄準咗嗰啲令個系統零舍唔同嘅韌性宣稱。Neon 描述嘅測試——模擬 provisioning 死機同 AZ 故障——就正正係無狀態計算同細胞隔離理應比傳統 managed database 架構有最大優勢嘅場景。而 2026 年 5 月嗰次 AWS 死機，就變相成為一次冇計劃過嘅驗證，出到嚟嘅受控爆炸半徑結果，同預留容量與細胞隔離嘅設計目標完全一致 。

對考慮用 Serverless Postgres 嘅團隊有咩啟示

Neon 嘅架構提出咗一種特定嘅韌性取捨：佢接受「計算」呢樣嘢係朝不保夕嘅，目標係死咗就極速換過隻，而唔係不惜一切 keep 住佢唔死；與此同時，佢喺儲存耐用性同故障域隔離度落咗重注。對於嗰啲間唔中頂得順 sub-minute 級別嘅查詢中斷，但首要任務係數據安全嘅工作負載，呢個模型消滅咗養住熱備援機嘅成本同複雜度。至於要求查詢服務完全唔可以斷嘅工作負載，Neon 都有多計算節點配置揀，但成本自然就會更高 。

呢個架構仲迫人誠實面對「雲端依賴」呢樣嘢。冇一個 database 服務係真正獨立於底下嘅雲端供應商，但耦合嘅程度可以差天共地。Neon 嘅決定——預留容量而唔靠即時呼叫、用自己嘅虛擬化層而唔靠雲 VM API、將數據放喺對象儲存而唔係 block volume——實實在在咁減少咗要雲端供應商 API 正常運作先至得嘅表面面積。呢個收窄咗嘅依賴表面，喺 2026 年 5 月 AWS 死機度即刻見到成效：有足夠預留 buffer 嘅細胞 keep 住行得走得，換轉係一個同雲 API 耦合得好緊嘅架構，嗰次死機好可能已經係全區攬炒 。

對於喺 serverless infrastructure 上面起樓嘅團隊嚟講，Neon 嘅做法示範咗一樣嘢：爆炸半徑控制絕對唔係事後諗嘅補鑊措施——佢係由儲存同計算割裂、由故障域結構呢啲建築學決策度，一早喺死機發生之前就已經決定咗嘅產物。