Serverless單體架構的崛起

作者：二師兄 2023-12-09 14:33:05

使用這種架構，對純凈和全面的單體架構（前端 + 后端）的需求就不再存在。然而，元框架是超過 80% 的代碼將駐留的部分。為此，現(xiàn)在有一些工具可以使用，例如 turborepo。

在過去的幾十年里，我們見證了應用架構以快速的速度演變。當我還是一個年輕的程序員時，開始編寫一個簡單的代碼庫，我們可以稱之為單體應用。

我記得為前端編寫了一些HTML/CSS，后端用了一些Java。但后來，隨著時代發(fā)展和需求改變，分布式架構（我們現(xiàn)在稱之為“微服務”）應運而生。

單體應用的衰落

這暫且不談單體應用如何變得越來越不受歡迎，但需要開發(fā)者開始鼓吹微服務卻是事實。

通常，微服務提供了以下好處：

微服務更小，更容易維護。
減少了團隊之間的摩擦。每個團隊可以獨立地處理每個微服務。
編寫速度更快（不需要遵循現(xiàn)有且有時繁瑣的架構）。
團隊使用最適合任務的工具（例如，處理大量JSON數(shù)據(jù)？也許可以使用Node.js。需要高性能？也許可以考慮Rust。只有Ruby開發(fā)者？那么Ruby似乎是解決方案）。
減少認知負荷，這意味著每個開發(fā)者只需要了解代碼的一個子集，而不是整個代碼庫。

然而，經常或者有時，過度使用微服務也存在一些缺點：

代碼重復：一些代碼（數(shù)據(jù)或函數(shù)）在多個倉庫之間重復出現(xiàn)，這會導致共享庫與單一倉庫的分歧和爭論。
事務處理復雜：處理多個微服務之間的事務具有一定的挑戰(zhàn)性，并需要額外的模式（Saga、事件溯源等）。
增加認知負荷：取決于上下文的不同，可能會極大地增加認知負荷。每個開發(fā)人員不僅需要知道微服務能夠做什么/應該做什么，還需要知道它可以/應該與哪些其他微服務進行通信。
易受故障影響：在幾乎所有的場景中，都更容易受到故障的影響：數(shù)據(jù)庫連接、網絡延遲、緩存、異常等。

但是，任何明智的開發(fā)者都會告訴你，對于任何架構選擇，答案總是“看具體情況”。

單體與微服務之爭中，一個設計良好的、高度解耦的架構只需要處理最多四個不同的部分：

UI，也稱為前端（front-end）
BFF，即面向前端的后臺（Backend For Frontend），或者說是單一前端的后端（Backend for a Single Frontend, BSF）
傳統(tǒng)后端，充當前端和數(shù)據(jù)之間的粘合劑。稱之為 BFD (Backend For Database) 或多BSF的后端。
數(shù)據(jù)庫，也稱為數(shù)據(jù)庫及其查詢機制。

圖片

完全解耦的微服務架構的表示

從熟悉的模式中，我們已經擁有合適的技術棧：

前端框架（Angular、React、Vue、Svelte 等）
使用適當技術的 BFF（簡單的 REST API？node.js 中的 GraphQL 服務器？）
一個傳統(tǒng)的后端（暫且稱之為BFD），再次使用適當?shù)募夹g（另一個REST API？一個高性能的gRPC服務器？）
最后是所需的最小數(shù)據(jù)庫數(shù)量（關系數(shù)據(jù)庫和/或文檔數(shù)據(jù)庫和/或圖數(shù)據(jù)庫和/或搜索引擎）

如果我們重視簡單性，還有改進的空間。我們還應該商定需要技術棧的每個部分的比例：

圖片

N = (2 * UI) + (1 * BFD) + (3 * DB)

正如俗話所說，“少即是多”，因此我們的目標是嘗試將這個數(shù)字 (N) 減少到絕對最低。

過去我們見證了一個令人難以置信的演變，那就是誕生了眾多前端元框架。其中最著名的有 Next.js、Remix 和 SvelteKit。

一個元框架的目標是同時處理前端的前端和后端（是的，當你這樣說的時候，這聽起來并不聰明）。換句話說，這意味著使用單一技術構建 UI + BFF。

而且，由于如今的云和托管解決方案，我們可以輕松以無服務器模式部署元框架。

BFD和元框架單體架構

N = META-FRAMEWORK + (1 * BFD) + (3 * DB)

從這里開始，我們?yōu)槊總€前端減少了 1 個技術！

目前，圍繞數(shù)據(jù)庫作為服務（DaaS）的解決方案或者說后端作為服務（BaaS）正在興起。BaaS的目標是提供應用程序所需的所有功能，以便你無需在后端編寫一行代碼。你只需要在你的BFF中編寫查詢，就完成了。

最著名的BaaS無疑是Firebase，它提供了許多功能，如實時文檔數(shù)據(jù)庫、身份驗證服務、數(shù)據(jù)庫之上的權限機制、文件系統(tǒng)存儲等等。

然而，F(xiàn)irebase也有一些嚴重的限制：

Firebase 數(shù)據(jù)庫，無論是 Realtime 數(shù)據(jù)庫還是 Firestore，都是單模型數(shù)據(jù)庫（文檔數(shù)據(jù)庫）。
它只能作為一個單向圖進行遍歷（如果我們可以將其視為圖的話）。

還有另一個叫做Supabase的著名BaaS，試圖與Firebase相媲美。使用類似PostgreSQL的關系型數(shù)據(jù)庫消除了Firebase的一些限制，但它仍然是單模型數(shù)據(jù)庫...

最近引起我注意的一個項目是SurrealDB。它是一個帶有內置后端的數(shù)據(jù)庫，具有許多許多功能（我覺得“許多”這個詞寫得還不夠）。作為一個真正的多模型數(shù)據(jù)庫，并且有一種新的查詢語言，他們能夠提供應該讓你寫一些代碼的功能。

最近，這種類型的數(shù)據(jù)庫被越來越廣泛地稱為元數(shù)據(jù)庫。

完全單體架構

N = META-FRAMEWORK + META-DATABASE

從那里開始，我們在另一個層面上大大減少了技術數(shù)量。

與微服務一樣，編寫單體應用意味著擁有正確的工具箱。這個工具箱可以解決我們通常遇到的約束，比如：

我們還沒有提到的一個不可避免的需求是數(shù)據(jù)庫腳本遷移。當然，這些腳本需要存儲在單獨的倉庫中，沒有什么復雜的。

責任編輯：武曉燕來源：程序新視界