在過去的幾十年里，我們見證了應(yīng)用架構(gòu)以快速的速度演變。當(dāng)我還是一個年輕的程序員時，開始編寫一個簡單的代碼庫，我們可以稱之為單體應(yīng)用。
我記得為前端編寫了一些HTML/CSS，后端用了一些Java。但后來，隨著時代發(fā)展和需求改變，分布式架構(gòu)（我們現(xiàn)在稱之為“微服務(wù)”）應(yīng)運而生。
單體應(yīng)用的衰落
這暫且不談單體應(yīng)用如何變得越來越不受歡迎，但需要開發(fā)者開始鼓吹微服務(wù)卻是事實。
通常，微服務(wù)提供了以下好處：
- 微服務(wù)更小，更容易維護(hù)。
- 減少了團(tuán)隊之間的摩擦。每個團(tuán)隊可以獨立地處理每個微服務(wù)。
- 編寫速度更快（不需要遵循現(xiàn)有且有時繁瑣的架構(gòu)）。
- 團(tuán)隊使用最適合任務(wù)的工具（例如，處理大量JSON數(shù)據(jù)？也許可以使用Node.js。需要高性能？也許可以考慮Rust。只有Ruby開發(fā)者？那么Ruby似乎是解決方案）。
- 減少認(rèn)知負(fù)荷，這意味著每個開發(fā)者只需要了解代碼的一個子集，而不是整個代碼庫。
關(guān)于微服務(wù)的誤解
然而，經(jīng)?；蛘哂袝r，過度使用微服務(wù)也存在一些缺點：
- 代碼重復(fù)：一些代碼（數(shù)據(jù)或函數(shù)）在多個倉庫之間重復(fù)出現(xiàn)，這會導(dǎo)致共享庫與單一倉庫的分歧和爭論。
- 事務(wù)處理復(fù)雜：處理多個微服務(wù)之間的事務(wù)具有一定的挑戰(zhàn)性，并需要額外的模式（Saga、事件溯源等）。
- 增加認(rèn)知負(fù)荷：取決于上下文的不同，可能會極大地增加認(rèn)知負(fù)荷。每個開發(fā)人員不僅需要知道微服務(wù)能夠做什么/應(yīng)該做什么，還需要知道它可以/應(yīng)該與哪些其他微服務(wù)進(jìn)行通信。
- 易受故障影響：在幾乎所有的場景中，都更容易受到故障的影響：數(shù)據(jù)庫連接、網(wǎng)絡(luò)延遲、緩存、異常等。
但是，任何明智的開發(fā)者都會告訴你，對于任何架構(gòu)選擇，答案總是“看具體情況”。
單體與微服務(wù)的平衡
單體與微服務(wù)之爭中，一個設(shè)計良好的、高度解耦的架構(gòu)只需要處理最多四個不同的部分：
- UI，也稱為前端（front-end）
- BFF，即面向前端的后臺（Backend For Frontend），或者說是單一前端的后端（Backend for a Single Frontend, BSF）
- 傳統(tǒng)后端，充當(dāng)前端和數(shù)據(jù)之間的粘合劑。稱之為 BFD (Backend For Database) 或多BSF的后端。
- 數(shù)據(jù)庫，也稱為數(shù)據(jù)庫及其查詢機(jī)制。
從熟悉的模式中，我們已經(jīng)擁有合適的技術(shù)棧：
- 前端框架（Angular、React、Vue、Svelte 等）
- 使用適當(dāng)技術(shù)的 BFF（簡單的 REST API？node.js 中的 GraphQL 服務(wù)器？）
- 一個傳統(tǒng)的后端（暫且稱之為BFD），再次使用適當(dāng)?shù)募夹g(shù)（另一個REST API？一個高性能的gRPC服務(wù)器？）
- 最后是所需的最小數(shù)據(jù)庫數(shù)量（關(guān)系數(shù)據(jù)庫和/或文檔數(shù)據(jù)庫和/或圖數(shù)據(jù)庫和/或搜索引擎）
如果我們重視簡單性，還有改進(jìn)的空間。我們還應(yīng)該商定需要技術(shù)棧的每個部分的比例：
- 至少一個前端，但你可以無限擴(kuò)展這個數(shù)字，無論是在編寫微型前端、大量的 web 應(yīng)用程序，還是兩者兼而有之
- 一個前端 = 一個 BFF，如果我們遵循邏輯
- 一個傳統(tǒng)的后端，你可以根據(jù)需要將其拆分成 N 個微服務(wù)。但是，如果我們使用單體架構(gòu)，那就說 1 個吧。
- 每個類型的數(shù)據(jù)庫至少一個。假設(shè)我們需要 3 種類型的數(shù)據(jù)庫來滿足中等規(guī)模的應(yīng)用程序。
N = (2 * UI) + (1 * BFD) + (3 * DB)
正如俗話所說，“少即是多”，因此我們的目標(biāo)是嘗試將這個數(shù)字 (N) 減少到絕對最低。
進(jìn)入Serverless單體架構(gòu)時代
前端元框架的興起
過去我們見證了一個令人難以置信的演變，那就是誕生了眾多前端元框架。其中最著名的有 Next.js、Remix 和 SvelteKit。
一個元框架的目標(biāo)是同時處理前端的前端和后端（是的，當(dāng)你這樣說的時候，這聽起來并不聰明）。換句話說，這意味著使用單一技術(shù)構(gòu)建 UI + BFF。
而且，由于如今的云和托管解決方案，我們可以輕松以無服務(wù)器模式部署元框架。
N = META-FRAMEWORK + (1 * BFD) + (3 * DB)
從這里開始，我們?yōu)槊總€前端減少了 1 個技術(shù)！
Serverless數(shù)據(jù)庫時代
目前，圍繞數(shù)據(jù)庫作為服務(wù)（DaaS）的解決方案或者說后端作為服務(wù)（BaaS）正在興起。BaaS的目標(biāo)是提供應(yīng)用程序所需的所有功能，以便你無需在后端編寫一行代碼。你只需要在你的BFF中編寫查詢，就完成了。
最著名的BaaS無疑是Firebase，它提供了許多功能，如實時文檔數(shù)據(jù)庫、身份驗證服務(wù)、數(shù)據(jù)庫之上的權(quán)限機(jī)制、文件系統(tǒng)存儲等等。
然而，F(xiàn)irebase也有一些嚴(yán)重的限制：
- Firebase 數(shù)據(jù)庫，無論是 Realtime 數(shù)據(jù)庫還是 Firestore，都是單模型數(shù)據(jù)庫（文檔數(shù)據(jù)庫）。
- 它只能作為一個單向圖進(jìn)行遍歷（如果我們可以將其視為圖的話）。
還有另一個叫做Supabase的著名BaaS，試圖與Firebase相媲美。使用類似PostgreSQL的關(guān)系型數(shù)據(jù)庫消除了Firebase的一些限制，但它仍然是單模型數(shù)據(jù)庫…
最近引起我注意的一個項目是SurrealDB。它是一個帶有內(nèi)置后端的數(shù)據(jù)庫，具有許多許多功能（我覺得“許多”這個詞寫得還不夠）。作為一個真正的多模型數(shù)據(jù)庫，并且有一種新的查詢語言，他們能夠提供應(yīng)該讓你寫一些代碼的功能。
最近，這種類型的數(shù)據(jù)庫被越來越廣泛地稱為元數(shù)據(jù)庫。
N = META-FRAMEWORK + META-DATABASE
從那里開始，我們在另一個層面上大大減少了技術(shù)數(shù)量。
附加內(nèi)容：利用單一倉庫架構(gòu)
與微服務(wù)一樣，編寫單體應(yīng)用意味著擁有正確的工具箱。這個工具箱可以解決我們通常遇到的約束，比如：
- 太龐大以至于無法失敗，一個簡單的錯誤可能會導(dǎo)致整個服務(wù)崩潰。
- 長時間部署，編譯大型項目通常需要很長時間。
- 無法跨團(tuán)隊隔離和共享的單一代碼庫。
使用這種架構(gòu)，對純凈和全面的單體架構(gòu)（前端 + 后端）的需求就不再存在。然而，元框架是超過 80% 的代碼將駐留的部分。為此，現(xiàn)在有一些工具可以使用，例如 turborepo。文章來源：http://www.zghlxwxcb.cn/news/detail-759690.html
我們還沒有提到的一個不可避免的需求是數(shù)據(jù)庫腳本遷移。當(dāng)然，這些腳本需要存儲在單獨的倉庫中，沒有什么復(fù)雜的。文章來源地址http://www.zghlxwxcb.cn/news/detail-759690.html
到了這里，關(guān)于Serverless單體架構(gòu)的崛起的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
