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的后端。
  • 数据库,也称为数据库及其查询机制。

Serverless单体架构的崛起_第1张图片

从熟悉的模式中,我们已经拥有合适的技术栈:

  • 前端框架(Angular、React、Vue、Svelte 等)
  • 使用适当技术的 BFF(简单的 REST API?node.js 中的 GraphQL 服务器?)
  • 一个传统的后端(暂且称之为BFD),再次使用适当的技术(另一个REST API?一个高性能的gRPC服务器?)
  • 最后是所需的最小数据库数量(关系数据库和/或文档数据库和/或图数据库和/或搜索引擎)

如果我们重视简单性,还有改进的空间。我们还应该商定需要技术栈的每个部分的比例:

  • 至少一个前端,但你可以无限扩展这个数字,无论是在编写微型前端、大量的 web 应用程序,还是两者兼而有之
  • 一个前端 = 一个 BFF,如果我们遵循逻辑
  • 一个传统的后端,你可以根据需要将其拆分成 N 个微服务。但是,如果我们使用单体架构,那就说 1 个吧。
  • 每个类型的数据库至少一个。假设我们需要 3 种类型的数据库来满足中等规模的应用程序。

Serverless单体架构的崛起_第2张图片

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

正如俗话所说,“少即是多”,因此我们的目标是尝试将这个数字 (N) 减少到绝对最低。

进入Serverless单体架构时代

前端元框架的兴起

过去我们见证了一个令人难以置信的演变,那就是诞生了众多前端元框架。其中最著名的有 Next.js、Remix 和 SvelteKit。

一个元框架的目标是同时处理前端的前端和后端(是的,当你这样说的时候,这听起来并不聪明)。换句话说,这意味着使用单一技术构建 UI + BFF。

而且,由于如今的云和托管解决方案,我们可以轻松以无服务器模式部署元框架。

Serverless单体架构的崛起_第3张图片

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。它是一个带有内置后端的数据库,具有许多许多功能(我觉得“许多”这个词写得还不够)。作为一个真正的多模型数据库,并且有一种新的查询语言,他们能够提供应该让你写一些代码的功能。

最近,这种类型的数据库被越来越广泛地称为元数据库。

Serverless单体架构的崛起_第4张图片

N = META-FRAMEWORK + META-DATABASE

从那里开始,我们在另一个层面上大大减少了技术数量。

附加内容:利用单一仓库架构

与微服务一样,编写单体应用意味着拥有正确的工具箱。这个工具箱可以解决我们通常遇到的约束,比如:

  • 太庞大以至于无法失败,一个简单的错误可能会导致整个服务崩溃
  • 长时间部署,编译大型项目通常需要很长时间
  • 无法跨团队隔离和共享的单一代码库

使用这种架构,对纯净和全面的单体架构(前端 + 后端)的需求就不再存在。然而,元框架是超过 80% 的代码将驻留的部分。为此,现在有一些工具可以使用,例如 turborepo。

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

你可能感兴趣的:(架构,serverless,架构,云原生)