降本增效利器之 Serverless

1 引言

近年来，Serverless 成为云计算领域热门词汇。早在 2014 年，亚马逊就在 AWSre:Invent 2014 大会上推出了 AWSLambda，赢得了开发者的广泛好评。2018 年，国内云服务厂商相继开始跟进，阿里云、腾讯云也推出了自己的 Serverless 云服务。今天我们就通过国内云厂商的案例来了解，Serverless 是什么？为什么需要 Serverless？它是如何降低软件开发成本，同时增加软件开发效率的？

2 What - 什么是 Serverless

Serverless^[1]的概念简单易懂，Serverless 顾名思义即 “无服务器”。开发者只需要把源代码发布到 Serverless 平台，而无需关心如何部署与维护，也不需要关心 Serverless 如何启动、如何接受请求、有多少个执行机、如何自动扩缩容。为了实现 Serverless 这一目的，云平台通常会提供 FaaS 和 BaaS 两种服务的支持——

• FaaS（Function as a Service），函数即服务。如阿里云的函数计算、AWS 的 Lambda 等。

• BaaS（Backend as a Service），后端即服务，如云数据库、对象存储、消息队列等。

我们可以把 Serverless 理解为运行在 FaaS 中的，使用了 BaaS 的函数^[2]。

相比于传统服务依赖于基础设施（如云服务器）搭建，Serverless 开发者不需要关心基础设施建设，而基础设施提供的集群监控、服务治理、配置管理、日志等能力，已经包含在了 Serverless 提供的服务当中。

传统服务

Serverless 服务

3 Why - 为什么需要 Serverless

3.1 现状和痛点

前后端分离的开发流程

前后端分离是目前主流的开发模式，后端开发 RESTfulAPI 供前端调用，需要专业的后端开发人员，搭建复杂的开发环境，例如 SpringBoot、MySQL、Redis、RabbitMQ、Docker 等。后端开发完成之后，前后端需要进行联调工作。开发成本和运维成本较高。绝大多数业务场景其实并不复杂。例如，我们需要一个 HTML 转 PDF 服务，在传统的后端开发环境下，搭建环境、针对稳定性、高并发进行优化等工作，要花费数倍于业务开发的时间，费时费力。我们需要一套解决方案，降低非业务需求的开发难度，把精力投入到业务开发中。

3.2 Serverless 的特点

3.2.1 降本增效

Serverless 可以从 3 个方面节约项目成本。

1.   节约开发成本。无需搭建开发环境。创建项目、编写代码、配置、测试、运行、部署、管理数据库，统统可以在浏览器中完成。开发者可以将开发重点关注到更有价值的业务代码，而不是浪费时间在其他事情上。

2.   节约运维成本。日志管理、监控告警等运维工作，同样可以在浏览器中完成。

3.   节约计算成本。用多少，收多少。传统服务器需要为闲置 CPU 和闲置内存付费，而 Serverless 只会在请求到来时计费。

3.2.2 支持多种编程语言

以阿里云函数计算为例，几乎兼容所有的主流编程语言。

Serverless 支持多种编程语言

3.2.3 高可用

1.   分布式。函数计算可以在不同的地域运行，无论用户在何处，都能快速响应请求。

2.   自动扩容。以阿里云函数计算为例，高并发请求来临时，函数计算会自动启动数百个实例同时处理，业务高峰期也不会宕机。

3.2.4 无状态

函数是无状态的，也就是说，多个运行中的函数实例不会共享内存，不会相互干扰。

4 Where - Serverless 适合场景

说了这么多 Serverless 的好处，具体在哪些业务场景可以用 Serverless 开发呢？

4.1 开发简单的后端接口

在小规模项目中，后端只有一些简单的接口，例如 CRUD，此时熟悉 Node.js 的前端开发人员利用 Serverless 即可完成接口的开发，无需后端开发人员介入，降低了项目的成本。

以一个仓库库存管理小程序为例，开发者只需在浏览器中写几行代码，即可搞定数据库查询接口。

使用 Serverless 开发的仓库库存管理小程序

4.2 基于 Serverless 的 SSR（Server-Side Rendering，服务端渲染）

对 SEO 要求较高的 SPA 项目，往往会选择使用服务端渲染的方式应对搜索引擎爬虫程序，爬虫程序访问间隔长，服务端渲染消耗的服务器资源少，为此专门购买服务器就显得没有必要了，编写 Serverless 应对爬虫请求，可以节省服务器资源成本。

4.3 内容管理系统（CMS）

传统动态 CMS（如 WordPress）成本高、访问速度慢、资源消耗大，传统静态生成器 CMS（如 Hexo）维护门槛高，不支持动态内容。为了解决二者的缺点，Jamstack 出现了。使用网站生成器（例如 Hexo）预渲染整个网站，使用 Headless CMS（无头 CMS）管理动态内容，使用 HTTPAPI 增强网站的功能^[3]。这种技术的出现很大程度上依托于各大云厂商提供的 Serverless Function 能力。我们可以在 Serverless 上部署无头 CMS（例如 Ghost），以及评论系统等插件，动态扩展网站功能，构建集快速、稳定、低成本、易于维护为一体的网站。

Serverless 部署的 Ghost 内容管理系统

4.4 触发式场景

Serverless 不仅支持通过 HTTP 调用，还支持定时触发、消息队列等触发方式。因此，智能家居控制、定时任务、持续集成、持续部署、消息队列的消费者等场景，都可以使用 Serverless 实现。互联网自动化（IFTTT）是“If This Then That”的缩写，是一个典型的事件驱动型工具，帮助人们利用各网站的开放 API，实现跨服务联动、硬件联动等好玩的玩法，唯一的门槛在于，你需要一台服务器来处理各种事件，Serverless 能够完美地胜任这个角色。

4.5 图像和视频处理

Serverless 可以构建应用程序的图像和视频处理服务。可以使用 Serverless 服务来执行诸如动态调整图像大小或更改不同目标设备的视频转码之类的操作。

Serverless 实现身份证识别

5 How - Serverless 开发最佳实践

5.1 控制成本

使用 Serverless 前，要清楚了解 Serverless 的收费模式，无论是测试，还是生产，都需要特别留意资源用量，针对业务，设置合适的监控告警和资源用量上限。Serverless 费用通常由以下几部分构成：

• 函数计算资源（FaaS）

• 调用次数

• 资源使用量 [单位 GBs，等于函数配置内存（GB） × 运行时长（s）]

• 外网出流量

• 数据库、对象存储等资源（BaaS）

5.2 优化冷启动时间

在开发过程中，我们会发现，云函数首次调用很慢。这就要从云函数的执行机制说起了。云函数存在两种启动：

• 冷启动：需要平台分配计算资源、加载代码、启动进程，耗时较长；

• 热启动：函数实例、执行进程都被复用，耗时很短。

Vercel 云函数的冷启动时间

云函数如果在一定时间内（几十分钟）没有被调用，那么平台会收回分配的计算资源，直到函数被调用前，再分配计算资源，这种情况下，会发生冷启动。

冷启动在某些场合会影响用户体验，比如，在一个评论系统中，读取评论接口的调用频率会远高于提交评论接口的调用频率，以单独的云函数实现提交评论接口，会导致提交评论接口屡次冷启动，用户提交评论缓慢。这种场景下我们可以使用“单一云函数”原则，由同一个云函数实现读取和提交，使用路由分发请求，消除不同业务逻辑间的重复冷启动时间^[4]。

消除提交评论冷启动时间

除了以上方法，我们还可以为必要的函数插入一段心跳（heartbeating）逻辑，使用特定的参数触发，不进行任何操作，直接返回，然后为该函数添加定时触发器，每隔一段时间调用心跳逻辑，通过牺牲少量函数资源，阻止函数的运行资源被回收。

5.3 使用“层”分离依赖代码

如果云函数拥有较多的依赖库或公共代码文件，会给在线编辑和部署带来不便。因此，为了管理这些依赖，诞生了函数层这一概念。和 Dockerlayer 相似，使用层管理，可以将依赖放在层中而不是部署包中，可确保部署包保持较小的体积。加快部署，方便在线编辑。

腾讯云云函数层创建页面

5.4 私有部署 Serverless

除了公有云服务提供商提供的 Serverless 云服务外，我们还可以在私有云中部署 Serverless，这在项目不方便部署到公有云时非常有用。Nuclio 即是这样的平台，只需一行命令，即可启动 Nuclio。

一行命令启动 Nuclio

私有部署 Nuclio 服务

5.5 Serverless 的局限

Serverless 不能完全取代传统后端服务，在业务选择使用 Serverless 开发之前，我们还需要了解 Serverless 有哪些“坑”。

1.   自动扩容也会带来高额的账单。历史上的真实案例，一个看似不起眼的递归调用，在谷歌函数计算平台引发滚雪球式自动扩容，一夜之间产生了 7.2 万美元的账单，令一家小规模国外公司面临破产^[5]。

2.   难以测试，难以调试。多数函数计算厂商仍未提供可靠的测试和调试方案。

3.   不适合复杂度高的服务，不适合密集计算型服务。云厂商一般会为函数限制最长运行时间（一般为 10 秒 ~ 30 秒），因此函数难以处理大量的计算。

4.   冷启动时间较长。相比长期运行的服务，函数计算接收请求时，额外经历了启动容器、拉取代码、加载运行时等阶段，函数资源被回收之后的首个请求往往需要等待 3 ~ 5 秒的冷启动时长。

5.   绑定云厂商。不同云厂商的 API 写法不同，原生开发的函数难以迁移到其他云厂商执行。对此，我们可以选择 Serverless Framework 框架来适配不同的云厂商。

6 总结

Serverless 架构的诞生，降低了软件开发成本，提升了软件开发效率。使用 Serverless，我们不再需要过多关注服务端的运维等不熟悉的领域，只需要专注于业务的开发、专注于产品的实现。我们需要关心的事情变少了，但我们能做的事情更多了。如果要用一句话来总结 Serverless，那就是 Less isMore。

7 参考

[1] CNCF Serverless Whitepaper v1.0 - https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview

[2] Serverless 掀起新的前端技术变革 - https://zhuanlan.zhihu.com/p/65914436

[3] Jamstack，下一代 Web 建站技术栈？ - https://zhuanlan.zhihu.com/p/281085404

[4] 腾讯云云开发云函数 之 代码共用 - https://www.imaegoo.com/2020/tcb-functions-dry/

[5] We Burnt $72K testing Firebase+ Cloud Run and almost went Bankrupt - https://blog.tomilkieway.com/72k-1/

本文转载自原银科技

原文链接：https://mp.weixin.qq.com/s/xDGc_3ax55HsOvLgT6brUw