serverless是容器化之后的下一个趋势吗?

  • 回答 (3)
  • 关注 (0)
  • 查看 (259)

最近看到很多书籍、开源框架、大量产品都在强推serverless,Serverless会成为终极形态吗?

在什么场景下Serverless可以落地?

真假二十一真假二十一提问于
御姐万岁回答于

Serverless架构,或者称为无服务器架构,是最近几年新冒出来的一种架构风格。这究竟是一种什么样的架构?无服务器,就是真的没有服务器了么?其实,对于Serverless来说,只是用户不用更多的去考虑服务器的相关内容了,无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题了;同时,也无需再对服务器进行运维了,无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。

但是没有服务器,如何来将程序、应用运行起来呢?这里要介绍的是Serverless下包含的两个概念:函数即服务,Function as a Service FaaS,后端即服务,Backend as a Service BaaS。

函数即服务 FaaS

函数即服务 FaaS,作为一种新的计算能力提供方式,让用户抛弃了对服务器的配置和管理,仅需编写和上传核心业务代码,交由平台完成部署、调度、流量分发、弹性伸缩等能力。FaaS的出现,会从底层开始变革计算资源的形态,提供了一种新的方式来提供计算资源,同时也会给软件架构与应用服务部署带来新的设计思路,进一步降低云计算的使用门槛,推动全行业在服务架构上的创新步伐。

后端即服务 BaaS

后端即服务 BaaS,其实大家已经使用很久了,这里的后端,指的就是各种云产品和云服务,例如对象存储COS,消息队列CMQ,云数据库CDB、TDSQL,云缓存CRedis、CMemcached,甚至到各种以 API 形式提供的服务如万象优图 CI,视频处理 VC。这些产品或服务,用户直接开通即可使用,无需考虑部署、扩容、备份、优化、安全等各种运维工作,做到了开箱即用,无需自己去进行服务器或应用的维护和管理,因此同样也是Serverless的一部分。

为什么要 Serverless

介绍了什么是Serverless,但是为什么会出现 Serverless,或者为什么要使用 Serverless 呢?我们这里可以从三个方面来看看,这三个方面可以类比为:天时,地利,人和。

天时,这里突出的时,即时间。传统的服务器模式,应用上线前,还得完成服务器准备,环境部署,数据库准备,存储准备等各种工作;上线后,还得面临计算扩容,存储扩容,数据库维护和扩容等各种运维工作。这这个过程中,应用上线和迭代的时间、节奏,受限于各种准备和维护工作。而利用Serverless,通过使用SCF产品,专注于完成业务相关的核心代码,通过直接使用COS,CDB,CMQ,CRedis等产品,解决数据存储,数据库,消息队列,缓存等问题,不再费心运维,而专注在业务开发和迭代上,能更快的完成应用上线,在这个互联网加速发展的时代,做到一步领先,步步领先。

地利,这里突出的利,即费用支出。传统的服务器模式,无论有没有用户正在访问,应用始终要保持运行,而在有用户访问时,又要关注服务器的资源使用率,在使用率达到一定程度时就要考虑扩容,避免突发访问量导致的资源不足。在这个过程中的费用,始终是有一部分为未使用的计算资源而支付。而 Serverless 架构,能确保所有的费用,都是用在了实际的程序运行、数据存储、用户访问中。SCF 云函数的计费方式,就是通过函数的调用次数和执行时间来统计费用,有用户访问或事件产生,才会有函数执行,才会有费用计算;相反,没有函数执行时,则没有费用支出。同理,其他的相关云产品,也是类似,例如 COS 仅收取存储、外网流量的费用,CMQ 仅收取请求次数、外网流量费用,CRedis 仅按实际使用内存大小收费。据测算,根据不同用户的应用压力情况,SCF 能为用户带来 30%~70% 的费用节省程度。

人和,这里突出的是人。传统的服务器模式,运维人员要投入大量的精力去维护服务器、数据库、存储等各种基础设施,解决各种集群、分布式系统的搭建问题,而实际运维解决自身应用问题的时间,可能只会占到很小一部分,而开发人员除了对自身业务应用的开发外,也需要投入时间,解决可能存在的各种外围系统的问题。而 Serverless 架构,无需运维人员再投入到基础设施中去了,而开发人员也可以全面关注业务系统的开发。SCF 产品,可以让开发人员直接编写业务逻辑核心代码,利用微服务架构,快速上线应用。CMQ,CDB,COS,CRedis 各种云产品,无需搭建配置,开通即可使用,而将基础运维工作交由云来完成。在这种情况下,脱离了基础运维的运维人员,可以提升自身视野,从更高角度来看待运维工作,实现业务运维;而开发人员,可以充分利用 CICD、DevOps能力,提升整个应用或业务的集成能力。

怎么用 Serverless

COS、CMQ、CDB、CRedis 这类 BaaS 型云产品,由于面世的时间已经很长,对其使用的方式,基本和原有使用 MySQL、Redis等产品相同,或者通过产品提供的 API、SDK直接访问使用。而 SCF 云函数,作为 FaaS 产品,有着稍有不同的使用方式。

  • 事件触发:SCF 的工作模式为事件触发,因此要考虑好触发方式。例如,利用 SCF 来处理图片生成缩略图,就可以利用 COS 事件,在图片文件上传 COS 后,上传事件就能自动触发函数执行,来生成新的缩略图并再次存入 COS 中。
  • 无状态服务:函数需要是无状态(stateless)的,缓存、日志、数据库等全部通过CRedis、COS、CDB这类云产品来支持,这样才能保证在业务请求突增时服务能迅速扩展。
  • 微服务:事件驱动(event-driven)和无状态(stateless)属性正是微服务架构所需要的。因此,在一开始就将自身的应用设计为微服务架构,解耦各模块间关联,使得应用成为可生长可进化的系统。

无服务器云函数 SCF 实现独立开发、简化测试和加速部署,能够助力公司在关键时期快速上线和迭代,为初创期的产品提供了很好的解决方案。

Maybe回答于

尽管 Serverless 在编写传统的 Web 应用上,有一定的缺点。然而,它的事件驱动及运行时计算,使得它在某些场景上相当的合适。

发送通知

由我们在上一节中提到的,对于诸如 PUSH Notification、邮件通知接口、短信,这一类服务来说,他们都需要基础设施来搭建。并且,他们对实时性的要求相对没有那么高。

即使在时间上晚来几秒钟,用户还是能接受的。在我们所见到的短信发送的例子里,一般都会假设用户能在 60 秒内收到短信。因此,在这种时间 1s 的误差,用户也不会恼火的。而对于 APP 的消息推送而言,这种要求就更低了,用户反而不太希望能收到这样的推送

WebHook

当我们没有服务器,又想要一个 Webhook 来触发我们一系列的操作的时候。我们就可以考虑使用 Serverless,我们不需要一直就这么支付一个服务器的费用。通过 Serverless,我们就可以轻松完成这样的工作,并且节省大量的费用。

一个比较明显的例子,就如 GitHub Hooks

GitHub 上的 Webhook 允许我们构建或设置在 GitHub.com 上订阅某些事件的 GitHub 应用程序。当触发这些事件之一时,我们将向 webhook 配置的 URL 发送 HTTP POST 有效内容。

比如说,当我们 PUSH 了代码,我们想触发我们的持续集成。这个时候,就可以通过一个 Webhook 来做这样的事情。

轻量级 API

Serverless 特别适合于,轻量级快速变化地 API。

其实,我一直没有想到一个合适的例子。在我的假想里,一个 AutoSuggest 的 API 可能就是这样的 API,但是这种 API 在有些时候,往往会伴随着相当复杂的业务。

于是,便想举一个 Featrue Toggle 的例子,尽管有一些不合适。但是,可能是最有价值的部分。

物联网

当我们谈及物联网的时候,我们会讨论事件触发、传输协议、海量数据(数据存储、数据分析)。而有了 Serverless,那么再多的数据,处理起来也是相当容易的一件事。

对于一个物联网应用的服务端来说,系统需要收集来自各个地方的数据,并创建一个个 pipeline 来处理、过滤、转换这些数据,并将数据存储到数据库中。

对于硬件开发人员来说,对接不同的硬件,本身就是一种挑战。而直接使用诸如 AWS IoT 这样国,可以在某种程度上,帮助我们更好地开发出写服务端连接的应用。

同时,对于物联网应用的客户端来说,则需要从数据库抽取数据进行展示。这部分,可能算不上是一个挑战点。

数据统计分析

数据统计本身只需要很少的计算量,但是生成图表,则可以定期生成。

在接收数据的时候,我们不需要考虑任何延时带来的问题。50~200 ms 的延时,并不会对我们的系统造成什么影响。

Trigger 及定时任务

对于哪些需要爬虫来抓取和生成的程序来说,Serverless 可能是一个不错的舞台。

尽管,这样的工作也可以由云服务器来做,我们只需要定时的启动一下服务器。通过服务器中的自启动脚本来做相应的事,但是当我们完成了一系列的工作之后。我们需要将数据存储在一个远程的服务器上。而为了让系统中的其它应用,也能直接访问这些数据。那么,我们可能会考虑使用一个云数据库。这个时候,Serverless 应用看上去更具有吸引力。

在那篇《CRON 定时执行 Lambda 任务》中,我们也可以看到 AWS Lambda 可以支持 Lambda 计算,定时启动服务,并计算。

精益创业

Landing Page

Serverless 的快速上线、开发,意味着它可以快速验证一个想法 MVP。如 Dropbox 在开始的时候,只创造了一个 Landing Page。作为一个想使用这个服务的用户,我们会在其中填上我们的邮箱。

而如果是使用 Serverless 来构建这样的应用,那么我们只需要创建一个静态页面,然后用一个 Serverless 服务来保存用户的邮箱到数据库中,如我在 GitHub 上的 serverless-landingpage 所做的那样。

Chat 机器人

聊天机器人,也是一个相当好的应用场景。

But,由于国内的条件限制(信息监管),这并不是一件容易的事。因此,从渠道(如微信、blabla)上,都在尽可能地降低这方面的可能性。

但是,我们还可以做一个微信公众号的服务。当用户输入一个关键词时,做出相应的回复,这实质上和聊天机器人是差不多的。只需要结合《基于 Serverless 与 Lambda 的微信公共平台》 就可以轻松实现,并实现快速上线。

节选自《Serverless 架构应用开发指南》

伤旧回答于

它实际上就是允许我们更关注业务代码,因此可以更快速的构建业务然后上线。

现在互联网开发速度越来越快,因此大家期望的是进一步加快开发和业务真正上线的速度,提高迭代的能力。因此,使用Serverless的话可以更快速让业务上线,让我们更快实现我们的想法。

而按需使用是我们这个业务在上线之后,在真正产生请求后,业务才会被调动触发,才会有计算。而如果你的业务产生了爆发式增长,其实也不需要担心平台承载能力或者业务扩展是否跟得上,因为平台提供自动扩展能力,降低了大家对运维的诉求,大家不用关心很底层的东西,而运维人员也可以更偏重流程化和业务相关的运维。这就是Serverless架构给大家带来的一些好处。

而作为Serverless里的核心,函数即服务这种产品,是Serverless中所呈现出来的计算型的组件,大家也可以看到它和触发源和后端的各种产品或服务有紧密关联,它可以更多的被看做是云时代的脚本,类似于黏合剂,把前面的触发源和后端的各种存储,数据,服务进行了黏合,真正实现架构落地,才是真正实现业务逻辑落地的能力。

扫码关注云+社区