下载掌阅APP，畅读海量书库
立即打开
《我们从何处来？我们是谁？我们向何处去？》——高更
随着云计算的大规模推广，我们经常听到一个名词：Cloud Native（云原生）。而在 Cloud Native 中被提及得最多的概念之一，莫过于 Serverless 了。然而，到底什么是 Serverless？它的标准定义是什么？怎样的架构才算 Serverless 架构？它的价值和优势是什么？我们探讨得很多，但实践得太少。这也许和 Serverless 长久缺乏标准规范有一定关系。不过，更主要的原因可能是作为普通研发人员的我们，很难从零开始实践 Serverless，并且更难以规模化地加以应用。实际上，Serverless 与现有的云计算各种技术体系并不是取代关系，而是一种补充关系。也就是说，当我们在讨论 Serverless 技术的应用时，并不是希望用它来替代原有的某些技术，而是结合业务的实际情况，将它融合到当前的技术架构中，最终有效提高生产力。要做到这一点，需要具有一定的架构经验，同时还需要具备对业务的深入理解和思考。就像我们在前后端分离中实践的 BFF（Backend For Frontend，即服务于前端的后端）架构一样，Serverless 更像在云端与终端之间的“BFF”。通过它，将云端与终端更好地“黏合”，最终实现“端云一体”的研发流程。
关于本书的由来，主要有以下三方面的原因。
据各大云计算供应商对 Serverless 使用情况的数据统计显示，目前各 FaaS（Function as a Service，函数即服务，是 Serverless 的两大能力之一）平台中，主要的编程语言是 Node.js。其在所有支持的语言中，占比甚至超过 80%。也就是说，Serverless 的使用者几乎都是 Node.js开发者。而在 Node.js 开发者中，又以前端研发人员为主。
为什么是 Node.js？又是什么原因导致了这一现象？作为前端研发人员中的一员，我们是否应该使用 FaaS 平台来构建应用？另外，Serverless 的另一分支 BaaS（Backend as a Service）又是什么？FaaS 和 BaaS 是什么关系？上述这些问题，正是我希望与读者进行探讨和交流的。
我认为，随着前端技术和业务复杂度的不断上升，以及 Cloud Native 技术的普及，Serverless架构对于前端研发人员来说，是一个十分有利的基础设施，因为它可以极大程度地降低云端服务的研发成本。在云端我们经历了从传统大型机到服务器集群的演化，其间，虚拟化技术从虚拟机的方式演化到容器化的方式。可以看出，我们正在“走向”那些更加轻量、更具灵活性的解决方案，以便可以采用更细粒度的方式去调度自己需要的计算资源。另外，伴随着基于前后端分离的 BFF 架构在 Web 应用开发中的流行，不同的终端也都有了属于自己的 BFF 层。在BFF 架构的普及之下，前端需要面临 3 个新的问题：
◎ 增加的 Node.js 应用，带来了更多的运维成本。
◎ 中长尾应用导致 Node.js 应用的计算资源长期闲置。
◎ 大量类似的基础服务（如身份认证、权限管理、消息推送等能力）需要在多个 Node.js应用中实现。
如何能从这些重复且烦琐的工作中解放出来，更聚焦于业务中，同时又能有效地提高资源利用率、降低成本，是我们迫切希望解决的问题。
于是，我以前端研发人员的身份，带着对上面这些问题的思考，在业务中进行了探索。经过两年时间的摸索与沉淀，我所在的团队完成了从基于 Node.js 应用的 BFF 架构演进到基于Serverless 的 BFF 架构的工作。随后又经过两年，我们将其应用在了更多的领域中（如传统的移动应用的服务端、面向生态的开放平台以及针对 AIoT （人工智能物联网）设备的能力建设等方向）。其间，我同时有幸牵头、建设了阿里巴巴公司内部服务于全体前端研发人员的Serverless 统一研发工作台项目，推进了集团前后端一体化解决方案的落地工作。通过这几年的观察和实践，我对 Serverless 的价值和方向有了深刻理解，对其架构的优劣势及其应用场景和局限性有了进一步的认知。
我购买并阅读了市面上几乎所有探讨Serverless的相关图书，但令人遗憾的是，这些图书的大多数篇幅都在介绍如何使用由云计算供应商提供的 Serverless 平台（如 Amazon AWS Lambda），描述如何创建、发布和维护一个基于该平台的应用，而对于 Serverless 的起源、发展、价值以及意义则一带而过。我认为，技术的发展历史和演化过程才应该是作为研发人员的我们，真正需要关心的内容。
知往鉴今，才有可能把握未来技术的发展方向。
另外，Serverless 的最大受益方是前端研发人员，但市面上却鲜有一本专门面向这一群体来介绍 Serverless 技术的图书，这不禁令人感到诧异。因此，我将从前端研发人员的视角，全面介绍 Serverless的原理及应用，希望更多的前端研发人员能因 Serverless 而受益。
本书除了介绍基本的 Serverless 基本理念和规范标准，还会对我个人在 Serverless 架构改造中总结的一些经验和教训进行阐述。希望通过对本书的介绍，能够解答读者的上述问题，让前端研发人员对 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 相关技术。
下面谈一下对研发岗位的一些看法。我比较反对用不同岗位（如前端研发工程师、后端研发工程师、测试工程师、运维工程师等）来区分研发人员。
之所以需要分工，实际上是因为软件研发的复杂度上升，并且研发团队希望保持一个较高的研发效率造成的。也就是说，如果软件研发的所有工作都通过同一个团队完成，那么他们需要掌握的知识就会十分庞杂。这涉及软件研发的方方面面，需要一个漫长的学习过程，并必将导致研发效率的降低。因此，我们通过分工协作，降低了这种学习成本，提高了软件研发人员的效率。
我们不妨思考一下，前端研发工程师岗位是怎么出现的。
前端研发工程师这个岗位大概出现于 10 多年前，因为业务上的需要（给用户提供更好的终端体验），导致前端工作的复杂度快速上升，以致一个人无法同时负担前端和后端的研发工作，所以细分出来一个独立的岗位。
那么，是否能通过工具或基础设施的升级，降低研发的复杂度，从而不再需要这个独立的岗位呢？实际上，在软件研发领域，最早提出类似想法并且实施的，恐怕是专职的测试工程师。通过研发各种自动化测试工具来保障项目的质量，降低测试成本，从而可以不再需要单独的 QA团队。同样，通过研发自动化运维的产品，让研发人员具备运维能力（即现在的 DevOps），简化运维的复杂度，从而可以不再需要专职的运维人员。
而现在，前端通过搭建平台的建设，简化了页面开发，又通过 AI 能力的运用，实现了从设计稿到页面代码的自动化生产，因此我们还需要专职的前端研发人员吗？而我们基于Serverless 极大地降低了运维门槛，这使得我们从 DevOps 演进到了 NoOps，当所有前端研发人员都掌握了这一能力后，我们真的还需要专职的后端研发工程师吗？
因此，我认为随着技术和配套工具的迭代，我们无须再因为技术栈不同而去区分不同的岗位，不会再有前端研发工程师、后端研发工程师、测试工程师、运维工程师之分，今后软件研发领域将只会有两种岗位：基础设施研发工程师（Infrastructure Engineer）和应用研发工程师（Application Engineer）。基础设施研发工程师将致力于提供更易于使用的计算资源，并使得计算资源的利用就像水电煤的使用那样便利；而应用研发工程师则将专注于业务研发，以便更快、更好、更容易地开发出让用户满意的产品。
可见，技术的不断演进迭代，让我们不再需要按技术栈来区分研发的岗位。
虽然 Serverless 帮助我们隐藏了运维背后的工作，但是否就代表我们无须了解其背后的原理，只需要学会使用就可以了呢？
从全球各行各业的工作来看，软件研发是一个颇奇怪的岗位。其他行业随着科技的不断发展，生产工具也在不停地演进和进化，最终工具会变得越来越便利、越来越易于使用。从业人员直接使用这些工具，无须理解其内部原理，就能比以前更好、更快地完成工作。
比如，对负责将乘客从出发地送往目的地的司机来说，他无须了解内燃机原理，也能很好地驾驶车辆，到达目的地；同时，摄影师也无须了解光学原理，在完成构图后，只需要简单地按下快门，就能拍出优美的照片。然而在软件研发领域，无论目前使用的语言有多么先进，研发人员却仍然需要理解计算机硬件的工作原理、操作系统的运行原理、互联网是如何链接的、程序是如何编译的。
是什么原因导致了这一现象？我想大概是因为对于司机来说，如果车辆发生了故障，可以送到 4S 店来维修；对于摄影师，如果相机发生了故障，可以送至相机生产厂商去更换。然而对于软件研发人员来说，若程序发生了故障，由于时间上的紧迫性，并没有谁能够立即提供帮助，只能研发人员自己解决。因此，如何能快速地定位和解决问题，这就依赖研发人员的相关经验和对底层原理的理解程度了。
平台做的事情越多，屏蔽的内部细节越多，研发人员使用起来就越方便。只有理解和掌握了底层原理，并通过更加深刻的思考和分析，才能设计出合理的架构。如果研发人员只是简单地使用云计算供应商提供的各种服务，那么当这些服务出现异常时，将无从下手来解决具体问题。所以，对于 Serverless 来说，其内部的原理研发人员仍然有必要了解。
因此，希望本书的读者通过对 Serverless 技术原理的学习，从而不再将自己局限于前端或特定领域，而是站在更高的角度看待软件研发。正如本章开头高更的名画——《我们从何处来？我们是谁？我们向何处去？》暗喻的那样，本书将从原理到实践、架构起源，再到发展方向，对 Serverless 进行全方位的解读，从而让读者把握软件研发的发展方向。
让我们进入云计算背景下的下一代软件架构——Serverless 的世界，一起感受它的魅力吧。