我记得为前端编写了一些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。
我们还没有提到的一个不可避免的需求是数据库脚本迁移。当然，这些脚本需要存储在单独的仓库中，没有什么复杂的。
