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 。
而且，由于如今的云和托管解决方案，我们可以轻松以无服务器模式部署元框架。