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

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

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

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

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

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

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

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

什么，還能這么玩

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

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

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

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

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

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

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

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

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

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

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

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

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

這種模式的主要弊病有兩個：

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

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

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

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

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

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

那么要不要試試呢？

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

Omnigres 提供的 33 個 PG 擴(kuò)展插件現(xiàn)在可以在 Pigsty 中開箱即用，而 Omnigres 提供的容器鏡像中也包括了 Pigsty 的 300+ 擴(kuò)展，可謂開源生態(tài)互惠共贏之典范。

?

如果你想試試在數(shù)據(jù)庫里寫應(yīng)用，一套 PG 打天下的刺激玩法，確實(shí)可以試試這個！

References

[1] 數(shù)據(jù)庫驅(qū)動未來: https://gamma.app/docs/The-Database-Drives-the-Future-41vma58e3502p70?mode=doc

閱讀原文：原文鏈接