Serverless单体架构的崛起

在过去的几十年里，我们见证了应用架构以快速的速度演变。当我还是一个年轻的程序员时，开始编写一个简单的代码库，我们可以称之为单体应用。

我记得为前端编写了一些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 种类型的数据库来满足中等规模的应用程序。

img

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。

我们还没有提到的一个不可避免的需求是数据库脚本迁移。当然，这些脚本需要存储在单独的仓库中，没有什么复杂的。