目录
一、Serverless 简介
根据 CNCF 的定义,Serverless 是指构建和运行不需要服务器管理的应用程序的概念。(serverless-overview)
Serverless computing refers to the concept of building and running applications that do not require server management. --- CNCF
其实 Serverless 早已和前端产生了联系,只是我们可能没有感知。比如 CDN,我们把静态资源发布到 CDN 之后,就不需要关心 CDN 有多少个节点、节点如何分布,也不需要关心它如何做负载均衡、如何实现网络加速,所以 CDN 对前端来说是 Serverless。再比如对象存储,和 CDN 一样,我们只需要将文件上传到对象存储,就可以直接使用了,不需要关心它如何存取文件、如何进行权限控制,所以对象存储对前端工程师来说是 Serverless。甚至一些第三方的 API 服务,也是 Serverless,因为我们使用的时候,不需要去关心服务器。
从技术角度来说,Serverless 就是 FaaS 和 BaaS 的结合。
Serverless = FaaS + BaaS。
简单来讲,FaaS(Function as a Service) 就是一些运行函数的平台,比如阿里云的函数计算、AWS 的 Lambda 等。
BaaS(Backend as a Service)则是一些后端云服务,比如云数据库、对象存储、消息队列等。利用 BaaS,可以极大简化我们的应用开发难度。
Serverless 则可以理解为运行在 FaaS 中的,使用了 BaaS 的函数。
二、Serverless 的主要特点
1、事件驱动
2、函数在 FaaS 平台中,需要通过一系列的事件来驱动函数执行。
3、无状态
4、因为每次函数执行,可能使用的都是不同的容器,无法进行内存或数据共享。如果要共享数据,则只能通过第三方服务,比如 Redis 等。
5、无运维
6、使用 Serverless 我们不需要关心服务器,不需要关心运维。这也是 Serverless 思想的核心。
7、低成本
8、使用 Serverless 成本很低,因为我们只需要为每次函数的运行付费。函数不运行,则不花钱,也不会浪费服务器资源
三、Serverless 服务中的前端解决方案架构图
上图是当前主要的一些 Serverless 服务,以及对应的前端解决方案。
从下往上,分别是基础设施和开发工具。
基础设施主要是一些云计算厂商提供,包括云计算平台和各种 BaaS 服务,以及运行函数的 FaaS 平台。
前端主要是 Serverless 的使用者,所以对前端来说,最重要的开发工具这一层,我们需要依赖开发工具进行 Serverless 开发、调试和部署。
框架(Framework)
如今还没有一个统一的 Serverless 标准,不同云计算平台提供的 Serverless 服务很可能是不一样的,这就导致我们的代码,无法平滑迁移。Serverless 框架一个主要功能是简化 Serverless 开发、部署流程,另一主要功能则是屏蔽不同 Serverless 服务中的差异,让我们的函数能够在不改动或者只改动很小一部分的情况下,在其他 Serverless 服务中也能运行。
常见的 Serverless 框架有 Serverless Framework、ZEIT Now、Apex 等。不过这些基本都是国外公司做的,国内还没有这样的平台。
Web IDE
和 Serverless 紧密相关的 Web IDE 主要也是各个云计算平台的 Web IDE。利用 Web IDE,我们可以很方便地在云端开发、调试函数,并且可以直接部署到对应的 FaaS 平台。这样的好处是避免了在本地安装各种开发工具、配置各种环境。常见的 Web IDE 有 AWS 的 Cloud9、阿里云的函数计算 Web IDE、腾讯云的 Cloud Studio。从体验上来说,AWS Cloud9 最好。
命令行工具
当然,目前最主要的开发方式还是在本地进行开发。所以在本地开发 Serverless 的命令行工具也必不可少。
命令行工具主要有两类,一类是云计算平台提供的,如 AWS 的 aws
、 Azure 的 az
、阿里云的 fun
;还有一类是 Serverless 框架提供的,如 serverless
、now
。
大部分工具如 serverless
、fun
等,都是用 Node.js 实现的。
四、基于 Serverless 的前端开发模式
在开始具体的案例之前,先看一下传统开发流程。
在传统开发流程中,我们需要前端工程师写页面,后端工程师写接口。后端写完接口之后,把接口部署了,再进行前后端联调。联调完毕后再测试、上线。上线之后,还需要运维工程师对系统进行维护。整个过程涉及多个不同角色,链路较长,沟通协调也是一个问题。
而基于 Serverless,后端变得非常简单了,以往的后端应用被拆分为一个个函数,只需要写完函数并部署到 Serverless 服务即可,后续也不用关心任何服务器的运维操作。后端开发的门槛大幅度降低了。因此,只需要一个前端工程师就可以完成所有的开发工作。
当然,前端工程师基于 Serverless 去写后端,最好也需要具备一定的后端知识。涉及复杂的后端系统或者 Serverless 不适用的场景,还是需要后端开发,后端变得更靠后了。
五、Serverless 的应用场景
Serverless 架构或者技术,可以用在什么样的场景下,来充分发挥它的优势呢?如下的场景,都适合使用 Serverless 架构或产品,来实现所需的业务逻辑。
WEB 及移动后端
通过结合使用云函数和 API 网关或 HTTP 触发器,可以对外提供 URL 访问地址,成为 Web、小程序、或移动应用等的后端服务。Serverless 架构既可以直接用于构建后台来服务应用,也可以通过类似 BFF 模式,构建中台和应用间的桥梁。
Serverless 架构提供的强弹性能力,使得可以支撑业务或应用的暴涨;而提供的低运维需求,使得开发者可以专注于业务实现和优化;同时,按实际使用量的付费方式,使得开发者无需预配置资源,无需担心预配置资源的浪费。
消息处理
Serverles 架构的应用本身是由事件触发的,因此极其适合于进行消息处理。无论是消息队列中传递的业务消息,还是 Kafka 中采集应用日志,均可以对接到云函数上,进行实时的消息处理、分析。
对象存储文件处理
在 Serverless 应用场景中,由对象存储中的文件上传事件,来触发云函数的运行,也是一种常见场景。针对图片文件的上传,可以借助云函数完成图片的缩略图生成、二维码或水印标记、图片优化处理;而针对数据文件的上传,可以启动数据的自动化分析,
物联网
物联网意味着成千上万的设备会连入网络,时刻在不断的产生数据,这对数据的分析、处理的及时性提出了很高的挑战。通过使用 Serverless 架构,物联网设备所采集的数据将可以作为云函数的触发事件,而实现数据的实时处理、分析和应用。
随着物联网设备计算能力的进一步提升,云函数作为最小粒度的计算单元,有机会被调度到设备端运行,实现边缘计算,达到端 - 云联合的 Serverless 架构。
运维及集成
通过对接云函数以及云上的各个产品、日志服务、监控告警系统,云时代的运维也都可以用云函数来构建。定时触发的云函数,将可以方便的替代需要在主机上来运行的定时任务;而日志或告警触发的云函数,将可以对云中的事件作出立刻回应及处理。
六、参考资料
经验分享:真正的完整的无服务器架构是什么样子?Serverless最佳实践和核心模式
无服务器Serverless架构(Martin Fowler)
Serverless 入门资料推荐
基础篇
进阶篇
高级篇