作者:灵轮（阿里云前端技术专家）

作为前端工程师，我们的使命是为用户提供良好的前端用户体验。随着云原生时代的到来，显而易见的，我们能做的更多了。Serverless 产品的特点是免运维、按量付费和自适应弹性，所以我们可以利用云上的各种 Serverless 能力，用相对更低的成本开发出更酷的产品，为我们的客户创造更多价值。

如何构建云原生现代化的 Web 应用？

让我们先回顾一下，我们是如何把一个静态网站发布出去的。

在云原生时代之前，我们想到的可能是需要先找一台服务器，安装 Nginx，然后上传静态文件，再经过一系列的配置，最终完成网站的发布。完成这些以后，发现已经花掉了小半天的时间，实际上这些花在运维上面的时间其实并没有为我们的客户创造价值。但这其实还只是一个开始，随着业务的发展，稳定性、弹性、安全和成本等问题，我们都要逐一解决，我们花在运维上的时间和精力会越来越多。否则，这个网站可能只是一个玩具。

但是随着云原生时代的到来，发布静态网站简单了很多，我们可以通过云产品，轻松地托管我们的网站。例如，可以将网站通过阿里云对象存储 OSS 提供的工具，将静态资源上传到 OSS，然后开启一键托管。此外，为了让客户能够更快地打开页面，还可以通过阿里云 CDN，将 OSS 设置为 CDN 的源站，从而让静态资源离客户更近，让客户的使用体验更好。这两款产品都是按量付费的免运维 Serverless 产品，它们大大地减少了我们各种繁杂的运维成本。我们可以把更多的时间花在研发和体验上，为我们的客户创造更多价值。

但是随着业务的发展，我们的网站如果并不只是一个静态网站了呢？

●对外服务的 API（需要对接缓存，数据库，消息队列，文件存储等）

●定时执行任务，甚至是执行海量任务

●发送电子邮件/短信/即时消息（钉钉，微信，飞书），拨打智能语音电话

●对用户上传的图片，音视频等进行处理（转码，缩略图，鉴黄，加水印，GPU 推理）

●服务端渲染 SSR 页面

●大促，秒杀

面对这些需求，难道我们又要去找服务器？为了保证服务的稳定性，弹性，安全和成本，难道我们又要把大量的时间花在运维上？有没有云产品可以像 OSS/CDN 解决静态网站的运维问题一样，解决我们的这些后端需求呢？

面对这些挑战，阿里云的 Serverless 产品函数计算 FC是一个不错的选择。除了通过函数计算 FC 处理 API 请求和大规模任务之外，还可以在函数计算 FC 中访问阿里云的 RDS、SLS、Tablestore、NAS 等丰富的云服务或者是其他第三方服务，从而满足对存储，计算，网络，安全，大数据，人工智能等各种业务的需求。

各种 Serverless 云产品就像是前端工程师的“武器库”，我们可以使用这些云产品来为我们的客户提供高质量的服务。

函数计算 FC 的优势和相关原理介绍

极致弹性，轻松应对流量洪峰

函数计算 FC 会根据请求量自动进行毫秒级弹性扩容，快速调度计算资源。从而使我们可以轻松应对海量 API 请求和大规模的并发任务。

在使用函数计算时，可以为函数配置一个“实例并发度”，这个并发度代表一个函数实例最多可以同时处理多少个请求。函数实例本质上是一个 Linux 安全容器，它是函数对外提供服务的最小单元。

例如，在“实例并发度”设置为 20 时，如果函数计算平台同时收到了 100 个请求，则会拉起 5 个函数实例来处理这些请求。处理完这些请求后函数实例会被冻结，如果在接下来的 2～5 分钟内（实例冻结以后就不再计费了）如果没有新的请求，函数实例将被自动销毁。在某些场景下，如果业务对延迟非常敏感，或者业务代码启动很慢，可以通过配置弹性规则，设置最小函数实例数量，这样函数计算 FC 会预先启动好函数实例，从而保证用户的使用体验。也可以通过设置函数实例的最大数量，限制函数实例的最大数量，从而保护下游服务，并控制成本。

对比传统服务器模式下需要自己进行服务器的扩容缩容的操作，函数计算 FC 这种自动弹性的方式不仅可以减少此类繁锁的扩缩容运维操作，也可以避免传统服务器模式下由于扩容不及时导致的业务不可用，从而提高系统的稳定性。

降低成本，提高资源利用率

函数计算 FC 中可以自由配置 CPU，内存，GPU 等实例的规格。最小可以创建 0.05 核，128 MB 的函数，并提供了极小梯度的规格选择，基本可以做到应用需要什么规格就配置什么规格。

函数计算 FC 的计费是毫秒级别的，比如我们的代码业务逻辑执行的时间为 5 毫秒，那么我们只需为这 5 毫秒进行付费。并且在无流量时，函数计算 FC 会将函数实例缩容到 0。这对业务量还没有起来的新业务，或者是一些调用本身就很少的中长尾业务非常友好，我们无需为它们付出固定的服务器费用。

自由配置规格，毫秒级别计费，缩容到 0 等特点可以帮助我们大幅提升资源利用率，极大的降低成本。

免运维，更安全

在传统的服务器架构中，我们时刻需要关心运行应用的物理机的资源使用情况。在函数计算 FC 中，我们无需关心底层物理机的资源使用情况，函数计算 FC 平台会自动调度并运维资源。但是如果是我们的业务代码消耗了过度的资源，例如发生OOM 等，函数实例会自动重启，请求会失败，这时我们需要根据监控指标和日志找出代码中的问题，或者修改函数的规格，给函数实例更多的资源。

函数计算 FC 也提供了函数默认的 HTTP/HTTPS 域名，从而方便我们访问函数。同时也支持绑定自己的域名到函数。所以相对于传统的服务器架构，在使用函数计算时，我们就免去了对应用服务器和负载均衡服务器的运维和购买成本。

从安全的角度出发，由于传统服务器需要一直运行着，在安全配置不合理时，或是没有及时修复代码漏洞时，黑客可以通过扫描 IP 和端口，发现并攻入服务器。函数计算FC因为不会一直起着实例，也不会直接将 IP 暴露在公网上，因此可以避免此类被扫描攻破的问题发生。

除此之外，操作系统的安全漏洞我们也无需关心，在出现安全漏洞时函数计算 FC 会第一时间完成修复。

在需要访问其他服务时，函数计算 FC 也会根据配置，自动生成临时密钥，这个临时密钥的有效期是 36 小时，所以无需将重要的访问密钥写在代码里或配置文件中，从而降低由于密钥泄漏产生的风险。

随着业务的不断发展，也可以额外购买阿里云的 Web 应用防火墙 WAF 产品来保护函数安全。

零改造，研发效率高

函数计算支持创建 3 种类型的函数，“内置运行时”，“自定义运行时”和“容器镜像”。并且提供了 API，SDK，控制台和 Serverless Devs 工具，帮助我们完成应用的开发、构建、部署和观测。

在使用“内置运行时”时，我们需要按照函数计算 FC 定义的接口规则编写代码处理请求。例如，下面为一个 Node.js 的 API 示例，使用这几行代码创建完函数之后，我们就可以立刻在我们的网站中使用这个 API 了。

使用“自定义运行时”时，我们无需改造代码就可以将 SpringBoot、Flask、Express、NextJS、NestJS、Gin 等 Web 框架开发的应用跑在函数计算上。只需在函数计算中配置应用监听的“端口号”和“启动命令”即可。它和使用传统服务器的部署方式非常类似。下图中的代码，对熟悉 Express 框架的同学来说，应该是再熟悉不过了。

使用“容器镜像”时，我们可以完全定制应用的执行环境，不用学习如何更新函数计算运行环境中的 Linux 版本，GCC 版本，安装各种依赖，字体等问题。此外，因为容器镜像的可移植性极好，我们不用担心被云厂商绑定，同一个容器可以运行在云上或本地数据中心的服务器上，或者是云上或本地数据中心的 Kubernetes 集群里。甚至您可以同时将一个镜像部署在服务器、Kubernetes 集群和函数计算里，通过几款不同的产品完成灾备。