,,

數(shù)據(jù)庫(kù)即架構(gòu)：將數(shù)據(jù)庫(kù)作為業(yè)務(wù)架構(gòu)本身，將業(yè)務(wù)邏輯甚至 HTTP Server 都放入數(shù)據(jù)庫(kù)中

當(dāng)前位置：點(diǎn)晴教程→知識(shí)管理交流 →『技術(shù)文檔交流』

admin

2025年1月26日 9:0 本文熱度 2159

數(shù)據(jù)庫(kù)是業(yè)務(wù)架構(gòu)的核心，是不言自明的共識(shí)。但如果我們更進(jìn)一步，將數(shù)據(jù)庫(kù)作為業(yè)務(wù)架構(gòu)本身，將業(yè)務(wù)邏輯甚至 HTTP Server 都放入數(shù)據(jù)庫(kù)中，又會(huì)有怎么樣的火花？

在1月4日舉辦的第七屆PG生態(tài)大會(huì)上，我邀請(qǐng)尤里來(lái)中國(guó)，進(jìn)行了題為《數(shù)據(jù)庫(kù)驅(qū)動(dòng)未來(lái)》的主題分享。他拋出了這個(gè)觀點(diǎn) —— 數(shù)據(jù)庫(kù)就是業(yè)務(wù)架構(gòu)。簡(jiǎn)單說(shuō)，他的開(kāi)源 PostgreSQL 項(xiàng)目 —— Omnigres ，嘗試把所有應(yīng)用的業(yè)務(wù)邏輯，甚至是 HTTP 服務(wù)器都放入 PostgreSQL 數(shù)據(jù)庫(kù)中。

如果你覺(jué)得這聽(tīng)上去有點(diǎn)不靠譜，先別急著下結(jié)論 —— 我也曾親眼目睹過(guò)這樣的成功實(shí)踐，所以今天就來(lái)和大家探討下這個(gè)有趣的話題。

數(shù)據(jù)庫(kù)是架構(gòu)的核心

“If you show me your software architecture, I learn nothing about your business. But if you show me your data model, I can guess exactly what your business is.”。

數(shù)據(jù)庫(kù)祖師爺邁克·石破天（Michael Stonebraker）有句名言：“如果你給我看軟件架構(gòu)，我對(duì)你的業(yè)務(wù)一無(wú)所知；但如果你給我看數(shù)據(jù)模型，我就能精準(zhǔn)知道你的業(yè)務(wù)是干嘛的”

無(wú)獨(dú)有偶，微軟的 CEO 納德拉也公開(kāi)表示：我們今天所稱的軟件，其實(shí)只是數(shù)據(jù)庫(kù)上的一個(gè)華麗界面。他將其簡(jiǎn)化為一個(gè)叫“CRUD”的概念：創(chuàng)建（Create）、讀取（Read）、更新（Update）和刪除（Destroy）。

也就是說(shuō)，你喜歡的那些應(yīng)用程序，不過(guò)是包裝精美的數(shù)據(jù)庫(kù)操作界面而已。BTW， Nadella 還提出 SaaS is Dead：因?yàn)橐院?Agent 可以直接繞過(guò)中間商，代替前后端去讀寫數(shù)據(jù)庫(kù)了。

即使在 GenAI 爆火的當(dāng)下，絕大多數(shù)信息系統(tǒng)的整個(gè) IT 技術(shù)棧依然是以數(shù)據(jù)庫(kù)為核心設(shè)計(jì)的。無(wú)論業(yè)務(wù)架構(gòu)怎么折騰，底層的東西永遠(yuǎn)是萬(wàn)變不離其宗。所謂的分庫(kù)分表，幾地幾中心，異地多活這些架構(gòu)花活，說(shuō)到底也就是數(shù)據(jù)庫(kù)的不同使用方式罷了。

數(shù)據(jù)庫(kù)是業(yè)務(wù)架構(gòu)的核心，是不言自明的共識(shí)。但如果我們更進(jìn)一步，將數(shù)據(jù)庫(kù)作為業(yè)務(wù)架構(gòu)本身，又會(huì)如何？

什么，還能這么玩

在 PG 生態(tài)大會(huì)上，尤里展示了一個(gè)思路：把所有業(yè)務(wù)邏輯，甚至是Web服務(wù)器都塞進(jìn) PostgreSQL 里。比如可以通過(guò)寫存儲(chǔ)過(guò)程，把原本后端的一部分功能直接放到數(shù)據(jù)庫(kù)里執(zhí)行。為此，他還基于 PG 擴(kuò)展做了很多“標(biāo)準(zhǔn)庫(kù)”，從 HTTP、vfs、os 到 Python 模塊，都可以內(nèi)嵌在 PostgreSQL 中。

讓我們來(lái)看一個(gè)有趣的例子，在 PostgreSQL 中執(zhí)行以下 SQL，將會(huì)啟動(dòng)一個(gè) Web 服務(wù)器，將 /pg/bin/ （或者其他任何目錄）作為一個(gè) Web 服務(wù)器的根目錄對(duì)外提供服務(wù)。

是的，夭壽啊，PostgreSQL 數(shù)據(jù)庫(kù)竟然拉起來(lái)了一個(gè) HTTP 服務(wù)器，默認(rèn)跑在 8080 端口！你可以把它當(dāng)成 Nginx 用！

但更重要的是，你還可以將任意的 PostgreSQL 函數(shù)（支持 20 多種存儲(chǔ)過(guò)程語(yǔ)言）掛載到 HTTP 端點(diǎn)上，實(shí)現(xiàn)你想要的任何東西。像這樣的 Omni 擴(kuò)展總共有 33 款，當(dāng)然也不要忘了 PG 生態(tài)里還有接近 400 個(gè)開(kāi)箱即用的擴(kuò)展插件可以提供各種功能

這一套擴(kuò)展全家桶，提供了在 PostgreSQL 中進(jìn)行 Web 開(kāi)發(fā)的能力！

在數(shù)據(jù)庫(kù)中跑Web服務(wù)器是餿主意嗎？

PostgREST 和 Postgraphile 這樣的工具，可以將設(shè)計(jì)良好的 PostgreSQL Schema 直接轉(zhuǎn)化為開(kāi)箱即用的 RestAPI，而類似 Omnigres 這樣的工具干脆百尺竿頭更進(jìn)一步，直接讓 HTTP 服務(wù)器運(yùn)行在了 PG 數(shù)據(jù)庫(kù)內(nèi)部！

目前來(lái)說(shuō)，這種實(shí)踐絕對(duì)算不上主流。站在一個(gè) DBA 的角度來(lái)講，我肯定認(rèn)為這是一個(gè)給 DBA 找麻煩的餿主意。但站在一個(gè)開(kāi)發(fā)者，特別是前端開(kāi)發(fā)者的角度來(lái)說(shuō)，我認(rèn)為這個(gè)主意還是很有意思，值得探索的！因?yàn)榇_實(shí)很省事 —— 前端一套 Next.js 一把梭，后端一個(gè)數(shù)據(jù)庫(kù)全部搞定了，架構(gòu)簡(jiǎn)單無(wú)比。

早先在探探在使用 PostgreSQL 時(shí)，幾乎所有的業(yè)務(wù)邏輯（甚至推薦算法）都在 PostgreSQL 里實(shí)現(xiàn)，后端只負(fù)責(zé)很輕的一層封裝只不過(guò)，這種做法對(duì)開(kāi)發(fā)者、DBA 的綜合技能要求較高，畢竟寫存儲(chǔ)過(guò)程、維護(hù)復(fù)雜的數(shù)據(jù)庫(kù)邏輯不是一件輕松活兒。而且那個(gè)時(shí)候，數(shù)據(jù)庫(kù)通常也是整個(gè)架構(gòu)中的性能瓶頸，哪有余量給這些花活。

但現(xiàn)在隨著兩個(gè)關(guān)鍵要素的變化（AI 的出現(xiàn)與硬件性能的嚴(yán)重過(guò)剩），利弊權(quán)衡發(fā)生了改變。GPT 顯然已經(jīng)達(dá)到了能夠熟練編寫存儲(chǔ)過(guò)程的中高級(jí)開(kāi)發(fā)者的水準(zhǔn)，而遵循摩爾定律發(fā)展的硬件直接把單機(jī)性能推到了一個(gè)匪夷所思的地步。

數(shù)據(jù)庫(kù)中跑Web服務(wù)器的利弊

在數(shù)據(jù)庫(kù)中跑Web Server這種模式有一些好處：

?你的業(yè)務(wù)邏輯，業(yè)務(wù)模型，業(yè)務(wù)數(shù)據(jù)放在一個(gè)地方，用統(tǒng)一的方式來(lái)管理。?你的業(yè)務(wù)代碼就是一個(gè)放著 Python / JS / Java 等存儲(chǔ)過(guò)程的目錄，更新發(fā)布，CI/CD 都非常簡(jiǎn)單。如果負(fù)載高要降級(jí)，把非關(guān)鍵的存儲(chǔ)過(guò)程刷新或在數(shù)據(jù)庫(kù)里設(shè)置標(biāo)記就實(shí)現(xiàn)了。?存儲(chǔ)過(guò)程避免了應(yīng)用后端與數(shù)據(jù)庫(kù)的多次網(wǎng)絡(luò)RT，通常有更好的延遲表現(xiàn)（總吞吐量會(huì)下降，但以當(dāng)下的硬件水平與性能余量，Who cares！）?你所需要的只有一個(gè) PostgreSQL 數(shù)據(jù)庫(kù)，后端融入到數(shù)據(jù)庫(kù)里，運(yùn)維管理極為便利，方便進(jìn)行單元化部署與敏捷交付。

這種模式的主要弊病有兩個(gè)：

1.互聯(lián)網(wǎng)時(shí)代，數(shù)據(jù)庫(kù)是瓶頸，難以伸縮，大家希望通過(guò)讓應(yīng)用承擔(dān)更多，數(shù)據(jù)庫(kù)退后的方式解決 scale 的問(wèn)題。2.對(duì)開(kāi)發(fā)者水平的要求太高了，用好數(shù)據(jù)庫(kù)對(duì)開(kāi)發(fā)者本身已經(jīng)是一件很有挑戰(zhàn)的事情，而寫存儲(chǔ)過(guò)程的技能在年輕一代開(kāi)發(fā)者中幾乎已經(jīng)失傳了，維護(hù)管理更是對(duì) DBA 提出了極高的要求。

但隨著時(shí)代發(fā)展，這兩個(gè)主要問(wèn)題得到了解決：硬件的發(fā)展讓數(shù)據(jù)庫(kù)的性能重新出現(xiàn) 巨大的富余。AI 的出現(xiàn)讓開(kāi)發(fā)者的水平（AI加持下）得到了突飛猛進(jìn)的發(fā)展。

前者讓數(shù)據(jù)庫(kù)性能余量重新回到了一個(gè)可以在大多數(shù)場(chǎng)景下容納業(yè)務(wù)邏輯的地步，后者解決了開(kāi)發(fā)者不會(huì)寫存儲(chǔ)過(guò)程的問(wèn)題。因此在當(dāng)下，數(shù)據(jù)庫(kù)即架構(gòu)（DBaaA）成為了一種非常值得探索的實(shí)踐。

數(shù)據(jù)庫(kù)即架構(gòu)理念有一個(gè)非常成功的案例 —— Supabase —— 可能有 80% YC 創(chuàng)業(yè)公司都在使用它。Supabase 號(hào)稱自己是一個(gè) Backend as a Service，將 PostgreSQL，對(duì)象存儲(chǔ)，以及 EdgeFunction 封裝成為一整個(gè)運(yùn)行時(shí)，然后將后端與傳統(tǒng)意義上的數(shù)據(jù)庫(kù)整體打包成為一個(gè) “新的數(shù)據(jù)庫(kù)”。

但 Supabase 本身仍然是一系列容器組件縫合拼接起來(lái)的，如果這種架構(gòu)走到極致，大概會(huì)變成 Omnigres 的樣子 —— 一個(gè)運(yùn)行著 HTTP 服務(wù)器的 PostgreSQL，Nothing Else。

這也許意味著軟件架構(gòu)的鐘擺重新回歸簡(jiǎn)單 —— 繞開(kāi)花里胡哨的中間件，前端直接訪問(wèn)數(shù)據(jù)庫(kù)，甚至連傳統(tǒng)移動(dòng)/Web前端也許最終也會(huì)被 LLM Agent 與其他 Interface 替代。最后直接由 Agent 代理訪問(wèn)數(shù)據(jù)庫(kù)。

那么要不要試試呢？

順便一提，我們已經(jīng)與 Omnigres 達(dá)成了合作。昨天在 Omnigres 創(chuàng)始人 Yurii 的幫助下，我為 Omnigres 構(gòu)建了主流 Linux 上的 RPM/DEB 包，包含了了以下 33 個(gè)擴(kuò)展插件，開(kāi)箱即用。（https://ext.pigsty.io/#/omni）