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

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

單體應用的衰落

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

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

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

關于微服務的誤解

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

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

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

單體與微服務的平衡

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

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

圖片

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

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

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

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

• 至少一個前端，但你可以無限擴展這個數字，無論是在編寫微型前端、大量的 web 應用程序，還是兩者兼而有之
• 一個前端 = 一個 BFF，如果我們遵循邏輯
• 一個傳統的后端，你可以根據需要將其拆分成 N 個微服務。但是，如果我們使用單體架構，那就說 1 個吧。
• 每個類型的數據庫至少一個。假設我們需要 3 種類型的數據庫來滿足中等規模的應用程序。

圖片

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

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

進入Serverless單體架構時代

前端元框架的興起

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

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

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

BFD和元框架單體架構

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

從這里開始，我們為每個前端減少了 1 個技術！

Serverless數據庫時代

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

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

然而，Firebase也有一些嚴重的限制：

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

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

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

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

完全單體架構

N = META-FRAMEWORK + META-DATABASE

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

附加內容：利用單一倉庫架構

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

• 太龐大以至于無法失敗，一個簡單的錯誤可能會導致整個服務崩潰。
• 長時間部署，編譯大型項目通常需要很長時間。
• 無法跨團隊隔離和共享的單一代碼庫。

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

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