一個SQL文件+薄SDK,沒有獨立服務、沒有編譯器插件、沒有完整運行時——這是Earendil團隊去年11月放出的Absurd。當時很多人當它是玩具,直到他們真把它塞進生產環境跑了5個月。
2024年4月的數據:系統沒崩,設計沒塌,開發者甚至有點上癮。
從"能跑"到"敢用":生產環境逼出的7個補丁
作者Gavin在博客里說,過去5個月的更新"都是你會對真實依賴系統期待的東西"。翻譯一下:用戶真的來了,邊罵邊用,把邊緣情況一個個喂給了他們。
認領機制(claim-based scheduling)被加固了。之前worker掛掉可能留下僵尸認領,現在看門狗會掐死失聯進程。死鎖預防、租約管理、事件競態條件——這些詞聽著枯燥,但任何一個在生產環境炸過的人都知道,它們是區分"演示代碼"和"能用的系統"的分水嶺。
最狠的一課:用戶比你更會用你的產品。
團隊原本以為ctx.step()——傳個函數、拿到持久化結果——就夠用了。結果用戶需要在提交結果前檢查步驟狀態,用來建模"故意失敗"和條件邏輯。于是有了beginStep()/completeStep()這對API。
這讓我想起Notion早期被用戶逼出database功能的故事。你以為自己在造錘子,用戶拿它造了艘船。
三個被低估的設計決策
任務結果(Task results)。最初是純fire-and-forget,現在可以spawn一個任務、干別的、回來取結果。聽起來像基礎功能?但就是這個" hindsight obvious"的改動,讓Absurd能支持父工作流等子任務完成——這對調試AI agent尤其有用。
absurdctl。從腳本集合進化成正經CLI:初始化schema、跑遷移、創建隊列、spawn任務、emit事件、重試失敗項。作者的原話是"proper CLI tool",帶著一種終于把草臺班子收拾利索的釋然。
多語言SDK。TypeScript、Python、實驗性Go。注意順序:不是從系統語言往下鋪,而是從業務開發者最順手的地方開始。這很產品經理思維——先讓用的人爽,再考慮炫技。
Postgres作為唯一依賴:大膽還是懶惰?
Absurd的激進之處在于:所有狀態、調度、事件、檢查點,全塞進Postgres。沒有Redis,沒有Kafka,沒有專門的持久化層。
反對者會說這是單點故障。支持者會算一筆賬:你的團隊已經在運維Postgres了,再多一個系統的認知負荷和故障面,真的值得嗎?
Gavin沒直接回應這個爭論,但給了數據:5個月生產運行,設計hold住了。換句話說,對于Earendil的規模和使用場景,Postgres的可靠性邊界還沒摸到。
這讓我想起SQLite的復興。不是因為它比Postgres強,而是因為"少一個東西在夜里報警"本身就是一種架構優勢。
誰在偷偷用?
博客沒披露客戶名單,但提到"other people seem to agree"——GitHub倉庫有外部貢獻,Discord有人討論生產部署。最有趣的信號是:團隊開始收PR了,而且是在" hardened claim handling"這種臟活領域。
愿意給你寫死鎖預防代碼的人,通常是真在用、真被卡過的人。
一個細節:作者特意提到"before call"和"after call"類型的hook API。這是支付、Webhook、第三方集成的典型模式——暗示Absurd正在滲入錢流過的系統。
最后的問題:如果持久化執行(durable execution)可以壓縮成一個SQL文件,Temporal、Cadence這些重運行時系統,有多少復雜度是為了覆蓋1000人公司的場景,而非10人團隊的?當你選擇它們時,買的是能力,還是提前支付的規模稅?
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.