单体与微服务：演变与平衡 应用架构的演变 过去数十年来，应用架构的发展日新月异。早期的开发者曾使用单体应用，但在分布式架构（微服务）的冲击下，单体应用逐渐式微。 微服务的兴起 微服务具有以下优势： 粒度更小，维护更便捷。 减少团队摩擦，各团队可独立处理不同微服务。 开发速度更快，无需遵循繁琐的架构。 使用最适合任务的工具。 降低认知负荷，开发者只须了解代码库的一部分。 微服务的误解 过度使用微服务也存在缺陷： 代码重复：同一代码可能在多个仓库中重复出现。 事务处理复杂：协调多个微服务之间的交易有难度。 认知负荷增加：开发者需要了解多个微服务的交互。 故障敏感性：微服务更容易受到数据库连接、网络延迟、缓存和异常等故障的影响。 平衡单体与微服务 单体与微服务之争中，理想的架构应高度解耦，包含以下部分： UI（前端） BFF（面向前端的后台） 传统后端（BFD，前端与数据之间的粘合剂） 完全解耦的微服务架构 采用合适的技术栈，我们可以构建完全解耦的微服务架构： 前端框架（如 Angular、React、Vue、Svelte） BFF（使用 REST API 或 GraphQL） 传统后端（BFD，再次使用 REST API 或 gRPC） 所需数据库（如关系数据库、文档数据库、图数据库、搜索引擎） 简化架构 注重简单性，我们可以进一步改进架构： 前端：至少一个，可根据需要扩展。 BFF：与前端一一对应，遵循逻辑。 传统后端：拆分成微服务（单体架构下为 1）。 数据库：至少一种类型，建议使用 3 种类型满足中型应用需求。 Serverless 单体架构 前端元框架的出现带来了以下变革： 同时处理前端和后台，使用单一技术构建 UI 和 BFF。 利用云和托管解决方案，轻松实现 Serverless 部署。 BFD 和元框架单体架构 通过将元框架与 BFD 结合，我们可以为每个前端减少 1 种技术： N = META-FRAMEWORK + (1 BFD) + (3 DB) Serverless 数据库 围绕数据库的云服务也在不断发展，出现了以下趋势： Serverless 数据库：按需付费，无需管理基础设施。 托管数据库：厂商管理基础设施，开发者专注于数据。 数据库即服务（DBaaS）：完全托管的数据库解决方案，提供高级功能。 将 Serverless 数据库与元框架相结合 将 Serverless 数据库与元框架结合，我们可以进一步简化架构： N = META-FRAMEWORK + (1 SERVELESS DB) 结论 单体与微服务的争论没有绝对的答案，最佳选择取决于具体情况。通过平衡这两个架构，我们可以构建高度解耦、维护便捷、开发速度更快的应用。Serverless 技术的兴起为我们提供了进一步简化的机会，使我们能够使用更少的技术和更低的成本构建复杂的系统。

---

云计算未来将如何发展？

比如容器和Kubernetes 在企业数据中心的兴起；专用硬件的普及；多云将不再是一个流行语；DevOps 的下一阶段发展；无服务器计算（Serverless）不再是一个流行语。 它正在成为发展最快的云服务交付模型之一；云计算带来改变，云计算人才需求增加，作为国内领先的全栈云原生技术服务提供商，时速云特别推出了Kubernetes 培训课程，对于刚接触 Kubernetes 技术、企业计划使用容器及 Kubernetes 集群、以及计划考取 CKA 证书的人群会是一个不错的选择。 大大推荐！

Serverless是什么？是'无服务器'吗？

Serverless，按中文翻译，称为无服务器。

这究竟是一种什么样的形态或产品呢？无服务器，就是真的没有服务器吗？

其实，在行业内，目前对于Serverless有几种解读方法：

在某些场景可以解读为一种软件系统架构方法，通常称为Serverless架构；而在有些情况下，又可以代表一种产品形态，称为Serverless产品。

在说起Serverless架构时，Serverless代表的是利用Serverless形态的产品实现的应用架构，这种架构完全依托于云厂商或云平台提供产品完成系统的组织及构建。在这种架构中，用户无需关注支撑应用服务运行的主机，而将关注点投入在系统架构，业务开发，业务支撑运维上。

而说起Serverless产品时，代表的是无需理解、管理服务器，按需使用，按使用付费的产品。Serverless产品中，其实也可以包含存储、计算等多种类型的产品，而典型的计算产品，就是云函数这种形态。

云函数，或者称为函数即服务FunctionasaService，它和后端即服务BackendasaService一起，都可以称为Serverless产品；而通过组合使用这些产品，开发者可以构建自身的业务Serverless架构。