0.2 Serverless更应该是一种价值观

如今 Serverless 在云计算背景下十分火热，似乎任何研发问题都能通过 Serverless 解决。但是，我在这里要给大家“泼一盆冷水”。从过去50年的软件研发历程来看，我们知道软件研发领域是没有“银弹”（No Silver Bullet）的。显然 Serverless 也不是“银弹”。它只是我们在云计算探索道路中的重要一环。Serverless 的核心思想是让用户直接运行应用，而不用关注它们的底层机制。但是，与各大云计算供应商提供的 Serverless 产品相比起来，我们更应该理解它的理念：无感知，即用户不应该知道那些他无须知道的内容。

在我从事软件研发的十多年时间里，经历过多种类型的应用开发。最初使用 ASP，与 IE 6“做斗争”；随后在 Windows 平台下，为我国的某重要机构编写过信息管理系统；在这之后，又为某电商平台完成了内部服务的治理工作。这些项目，让我深刻地认识到了统一以及自动的重要性。

IE 6 时代很难避免兼容性痛苦，相信对于有过这种经历的前端研发人员来说，这会是一段难忘的回忆。当时由于 IE 6 与 W3C 标准间的矛盾，以及 IE 6 极高的市场占有率而导致各种事实标准（即一种已经获得大众接受，或是已有市场主导地位的习惯）的存在，前端研发人员不得不从研发阶段开始就针对 IE 6 编写各种兼容代码，以致前端研究人员对于 JavaScript 和CSS（Cascading Style Sheet）在 IE 6 下的各种 hack 写法了然于心。这一问题一直持续了数年。直到 IE 8 发布以及更后面 Chrome 的诞生，这个问题才得到缓解。可以看出，因为缺乏或未遵循统一的标准，研发人员不得不去了解不同浏览器间的细节差异，这导致了当时前端研发领域人员极低的生产力。

后来，我转到了 Windows 应用研发，做桌面客户端应用程序的研发工作。桌面应用程序，通常需要通过安装包进行部署。因此，我们交付给终端客户的是一个安装程序。鉴于项目的复杂性，我们为了减少安装包的大小，针对客户中不同的用户群体和使用场景提供了九个不同的安装包。然而，由于当时缺乏相关的构建工具，每个团队都需要手工构建交付产物。而且，涉及的系统众多，导致各系统的构建流程并不一致；它们都依赖于不同的构建环境，甚至由于依赖软件的复杂配置而导致有些系统只能在特定的计算机中构建。最终，整个项目完成一次构建，通常需要一周时间。对于软件应用研发的交付周期来说，需要一周时间才能完成构建显然是太令人难以接受了。因此，为了解决这一问题，我们提出了通过持续集成（CI，Continuous Integration）和持续交付（CD，Continuous Delivery）的方式来改善整个交付流程。经过一系列改造，九大系统统一了构建流程，并实现了在服务器中的自动化构建。最终，我们在每一次的 git提交时，都将自动交付一个安装包，经由 QA（Quality Assurance）简单验证后即交付客户，将原来数天才能完成的交付缩短到了半天以内。通过将构建流程标准化，我们不再需要关心构建中的细节，这使得软件的交付效率得以大大提高。

我在某电商平台工作时，同样遇到了因统一标准的匮乏而导致的种种问题。那时不同的系统（如商品中心、订单系统、用户中心）由不同的团队维护，它们之间的相互调用，出于性能方面的考虑，是通过直接读/写对方的数据库来实现的。由于各团队对对方的数据结构并不熟悉，这导致了各种因错误的调用而引起的异常频发，且难以排查。同时，由于数据结构的变更未送达依赖团队，线上问题也时有发生。由于这些问题造成了较多的负面影响，我们决定建设 API中心，通过服务注册、发布、订阅、消费的方式解决团队间的依赖关系问题，团队之间的服务只允许通过 API 进行调用。最终，我们通过改造，统一了跨团队系统的调用标准，整体系统的稳定性得以显著提升。

在这之后，我便专职于前端开发工作。当时前后端分离的思想十分火热，而 BFF 架构则是前后端分离思想的最佳实践之一。然而，在我们实现 BFF 架构后却发现，随着 BFF 的应用，我们将面临日渐上升的研发和运维成本。尽管BFF应用通常是用于裁剪和聚合的十分简单的应用，但作为服务端应用，我们仍然需要关注这些应用实例的集群负载情况，需要随时了解各种系统监控和日志信息。此外，针对每一个应用的部署和发布也会消耗一笔不菲的时间成本。另外，如果存在多个 BFF 层，那么我们还将面临重复建设的研发开销。我们需要为每一个应用提供账户登录、功能鉴权、邮件发送、消息推送等各种服务。

而通过 Serverless，基于 FaaS 和 BaaS 能力，我们能很好地解决这些问题。

关于具体的实现方式，我将在本书中详细探讨。这里想要说明的是，无论是浏览器标准的统一、应用的打包构建、服务的注册与发现，还是 BFF 的上述问题，所有与业务无关的重复性工作，都不应该暴露给应用的研发人员，而应该由平台自动化完成。

因此，本书与其他 Serverless 图书的最大不同，是本书不会大篇幅介绍如何使用云计算供应商所提供的 Serverless 产品，而会更多地讲解 Serverless 的理念和思想。因为我相信，随着云原生技术的不断发展，当前云计算供应商所提供的 Serverless 产品不一定是最终形态，过多介绍如何在云计算供应商的控制台中使用这些产品，只会让书中的内容快速过时。我希望的是，从 Serverless 的本质出发，通过探讨并理解其背后的深远意义和价值，读者能够结合自身的业务场景，更加灵活地选择或构建 Serverless 相关技术。