从aws lambda谈serverless

叔牙

发布于 2023-06-21 11:10:13

3680

文章被收录于专栏：一个执拗的后端搬砖工一个执拗的后端搬砖工

内容目录

一、基于aws lambda构建监控告警的思考二、什么是serverless？三、serverless解决了什么问题四、常见serverless应用场景五、为什么serverless淡出视野？六、参考

一、基于aws lambda构建监控告警的思考

最近使用了亚马逊的CloudWatch做资源监控和告警,也初次接触到了aws一个强大的功能lambda。

基于aws自带的CloudWatch对资源基础指标的覆盖上报以及CloudWatchAgent自定义指标监控上报能力,将事件发送到sns,然后编写lambda脚本函数病订阅sns主题,lambda收到sns推送消息时会执行脚本函数执行对应的消息推送逻辑。

整个流程我们并没有专门为接收事件和消息推送部署单独的资源或服务,仅仅通过简单的脚本就行一系列的能力,也从某种程度上打破了传统服务架构的认知,不仅会思考为什么函数能够运行,为什么能够被触发,到底底层原理是什么?

二、什么是serverless？

狭义 Serverless是指 Serverless computing 架构 = FaaS 架构 = Trigger(事件驱动)+FaaS(Function as a Service，函数即服务)+BaaS(Backend as a Service，后端即服务，持久化或第三方服务)=FaaS + BaaS。

广义 Serverless 是指服务端免运维，也就是具有 Serverless 特性的云服务。要想达到 NoOps，需要具备：

无需用户关心服务端的事情(容错、容灾、安全验证、自动扩缩容、日志调试)
按使用量(调用次数、时长等)付费，低费用和高性能并行，大多数场景下节省开支。
快速迭代&试错能力(多版本控制、灰度、CI&CD 等等)。

Baas

Baas 的英文翻译成中文的含义：后端即服务，它的应用架构由大量第三方云服务器和API组成的，使应用中关于服务器的逻辑和状态都由服务提供方来管理的。比如我们的典型的单页应用SPA和移动APP富客户端应用，前后端交互主要是以RestAPI调用为主。只需要调用服务提供方的API即可完成相应的功能，比如常见的身份验证，云端数据/文件存储，消息推送，应用数据分析等。

Faas

FaaS可以被叫做：函数即服务。开发者可以直接将服务业务逻辑代码部署，运行在第三方提供的无状态计算容器中，开发者只需要编写业务代码即可，无需关注服务器，并且代码的执行它是由事件触发的。其中AWS Lambda是目前最佳的FaaS实现之一。

Serverless的应用架构是将BaaS和FaaS组合在一起的应用，用户只需要关注应用的业务逻辑代码，编写函数为粒度将其运行在FaaS平台上，并且和BaaS第三方服务整合在一起，最后就搭建了一个完整的系统。整个系统过程中完全无需关注服务器。

从使用aws lambda的案例来说,其实我们就按照规则编写了一段Faas,在aws强大的云服务平台提供的资源以及背后丰富的Baas能力支撑下,基于事件触发机制就形成了一个小范围的产品能力。

我们基本上可以理解为serverless=Faas+Baas。

三、serverless解决了什么问题

使用serverless架构不是凭空想象,也不是为了使用而使用,一定是处于某种场景的考虑,亦或者为了解决什么问题。

1.简化应用程序部署和管理

基于serverless模式,用户可以将应用程序的代码按照云平台约束的规则打包成函数或者压缩文件,然后上传到云平台,用户就不需要维护服务器和操作系统，也不需要担心硬件资源的配置和分配。

2.实现应用程序的弹性和可伸缩性

Serverless允许应用程序根据实际需求动态调整资源,因此应用程序能够更加弹性和可伸缩。也就意味着，当应用程序的流量突然增加时，它能够自动扩展资源以满足需求；当流量减少时，它也能够自动缩减资源以节省成本。用户需要做的就是按照程序调用次数、资源使用率等付费。

3.提高应用程序的可用性和容错能力

Serverless允许应用程序将代码打包成函数,在多个节点上同时部署,从而即使某个节点出现故障，也可以通过其他节点来执行任务，从而提高应用程序的可用性和容错能力。而不需要开发人员或者运维动态维护可用性以及处理故障恢复。

4.缩短应用程序的上线周期

基于Serverless架构，用户可以快速部署应用程序的代码，因此可以缩短应用程序的上线周期。这对于快速迭代和提供新功能非常有帮助。用户只需要保证程序能够正确运行,而不需要做复杂的上线准备。

总而言之，Serverless可以为用户解决许多云计算技术中的问题，帮助用户简化应用程序部署和管理、实现应用程序的弹性和可伸缩性、提高应用程序的可用性和容错能力、缩短应用程序的上线周期等,让研发人员更多的关注业务能力开发,而不是研发流程和运维管理。

四、常见serverless应用场景

从前边的描述中我们可以知道,serverless更适合以下场景:

组件可独立部署和扩展，对其他服务依赖性不强
应对突发或服务使用量不可预测,动态计算和所扩容成本比较高
短暂、无状态的应用，对冷启动时间不敏感;服务无状态,并且对云平台为程序分配资源、准备环境以及预热不敏感的场景
由快速开发迭代诉求的业务;传统架构上线流程繁琐复杂,有频繁上线和快速迭代诉求的业务场景可以考虑serverless架构

当然我们聊完了serverless适用于哪些应用场景,也简单分析下目前市面上比较常见的serverless产品能力。

1.微信小程序

微信小程序本身不是ServerLess模式，而是微信小程序支持ServerLess模式。

但是如果把小程序单做一套完整的解决方案,包括端上能力以及云服务能力,基于小程序云开发集成在微信小程序中的云服务,那就是serverless模式的,满足了serverless架构免运维、按使用和资源付费以及弹性伸缩等能力。换个角度如果只是把应用侧能力基于小程序规则做开发,而服务端还是传统的服务架构,自己维护服务端的资源和服务,那么就谈不上是serverless架构。

2.云平台监控告警

回调开篇聊到的话题,虽然我们使用lambda函数编写了简单的脚本上传到云平台,就能使用相应的服务和能力,看起来并不像什么serverless架构,这只是表面看到的,只不过云平台封装和屏蔽了这些资源、运维和初始化的能力。对于使用lambda函数监控资源使用情况并做告警推送,我们用到了CloudWatch监控能力,sns订阅推送能力,以及lambda函数运行所依赖的容器资源环境等,并且我们要对所有用到的能力按量或者使用时长付费。也恰恰反映了其所倡导的免运维、部署简单等各项能力。

五、为什么serverless淡出视野？

严格意义上不算淡出视野,只不过概念没有前几年炒的那么火了,相信有很多企业也尝试过部分业务基于serverless机构,但是像一些复杂的业务场景,业务领域之间有比较复杂的穿插交互,并不会摘出某个环节用serverless实现。像一些个人开发者、比较独立以及对成本比较敏感的场景仍然可以考虑使用serverless函数实现。目前主流业务放弃使用serverless主要出于几点的思考和权衡。

1.私有化诉求

有些特定的应用场景或者比较敏感的业务,对私优化部署要求比较高,比如说政府项目,其安全性考量远大于性能、成本和资源共享,基本不会和其他企业的公网项目共用云服务和资源。

2.学习成本

serverless理念很好,只需要关注于业务能力编程即可,但是想要将其应用于生产环境,还是有很多概念和规则需要了解和学习,并且每个云平台提供商的规则和实现方式可能大相径庭,在一些有混合云开发的场景中,学习成本是在太高,并且容易造成混淆。

3.冷启动问题

当函数上传到首次运行，云平台提供商需要初始化平台配置，配置弹性网络，拉取镜像，拉取用户代码，初始化运行等等准备各种资源和预热准备,然后执行函数。整个过程也比较慢。如何避免冷启动,需要对函数资源以及云平台提供商特性了解比较到位,比如设置一些预制并发或者预留实例,这些都需要对云厂商非常了解,并且配置这些资源往往需要额外的成本。

4.费用问题

传统的物理服务器与现在盛行的云服务器,成本基本都是固定的或者说都是可以预知的,而serverless函数服务是按量付费的,不同的厂商计算规则不太一样,但是基本都是围绕调用量、运行时长、占用资源、预留实例以及扩缩容等指标计算,如果配置和使用方式不合理,未必比自己持有和维护服务器成本低,并且随着服务器利用率的提升,成本差越来越少,把服务器各项资源利用率维持在一个比较平稳的水准并且能够应对突发流量,那么serverless函数编程在成本维度就没有那么大的优势了。