Serverless是怎么“无”服务器工作的

2020-06-15 16:14:43 浏览数 (1)

很早就关注serverless了,刚开始关注serverless,不是因为它是新技术,也不是有什么特性吸引我,只是因为他们宣传serverless是“无服务器”,作为一个运维,服务器都没了,还搞毛线

冲着无服务器,就开始了解和接触serverless,serverless总得来说,它不是一种编程框架、类库或者工具,也不是不需要服务器。它是一种软件系统架构思想和方法,它的核心思想是用户无须关注技术支持应用服务运行的底层服务器,我认为它的出现是继docker之后又一个颠覆性的思想和架构

serverless所谓的无服务器,并不是说基于serverless架构的软件应用不需要服务器就能运行,这里指的无服务器,是指不需要开发者关注有关底层服务器等基础设施,开发者开发的应用所需要的计算资源由底层的云平台提供,即便是私有的serverless也是由底层提供计算资源,不需要开发者过多的考虑

传统的应用部署场景里面,当用户完成了应用开发后,软件应用将被部署到指定的运行环境,这个运行环境一般是以服务器的方式体现,可以是物理机、虚拟机、容器。用户需要根据业务规模来申请一定数量、一定规格的服务器以满足应用的需要,应用上线后,根据实际的运营情况、负载情况,用户需要不断的扩缩容以应对高峰、低估的访问量。上面这些都是运维需要去日常做的事情

那么到了serverless架构下,开发完成应用开发后,软件应用将被部署到指定的运行环境,这个运行环境不再是具体的多少台服务器,而是支持serverless的云计算平台,当有客户端请求到达或特定时间发生时,serverless平台负责将应用部署到平台的某台服务器或主机中,由serverless平台提供保证应用正常运行的计算资源,高访问量时自动增加实例,空闲后自动卸载应用,并回收资源,运维需要干的事情全干了

而且serverless架构中部署和运行不再是一个整体的jar包,或是一整套业务代码,而是以函数作为部署和运行的基本单位

为了防止文字太多,看个云函数的入门案例,或许对serverless会有更明确的理解

图上是云函数中的hello world的示例,对于开发者来说,完全不需要考虑环境的问题,只需要编写业务代码,而云函数在event触发时开始部署执行,返回执行结果,最后面的运行日志中最后有运行时常、资源占用大小等信息供开发者参考

serverless目前按照功能主要分为FaaS(Function as a Service)和Baas(Backend as a Service),上面函数那个属于FaaS,用一张图来简单表示下这两者

FaaS提供了一个计算平台,在这个平台上,应用以一个或多个函数的形式开发、运行和管理,FaaS大多基于事件驱动(Event Driven),可以根据预定义的事件触发指定的函数应用逻辑。

而更为成熟的FaaS,AWS Lambda要更成熟,比较这么多年了

BaaS的应用架构由大量第三方服务器和API组成,使应用中关于服务器的逻辑和状态都由服务提供方来管理,比如一些单页面应用移动app客户端应用等,以及数据库服务,比如DBaaS,就是数据库即服务。只需要调用服务提供方的API即可完成相应的功能,比如常见的身份认证、OOS、消息推送、应用数据分析等,BaaS更多的提供了一个完整的功能

说了这么多,总结serverless优点如下:

  • 一定程度上降低成本
  • 降低架构复杂度
  • 缩短应用上线时间
  • 一定程度提高系统安全性
  • 提高扩展能力

虽然有颠覆性,有点也不少,但目前阶段的serverless仍有局限性,如下:

  • 对资源的控制力

虽然它的理念在于不必考虑底层资源,但也由于底层资源完全由第三方控制,在许多应用中可能不太合适

  • 可移植性

不同的平台的serverless解决方案不一致,目前也没有行业标准

  • 安全性

优点中提到一定程度上提高安全性是考虑在用完卸载的情况,而不管是BaaS还是FaaS,都是在第三方平台上,从这个方面考虑,安全性又有待商榷

  • 性能

因为serverless是基于事件驱动的,它并不是一直部署在相应环境的主机或服务器上,空闲状态下是卸载掉的,当请求到达时,才会重新加载,所以对于性能要求高的应用,serverless目前并不适合

  • 执行时长

serverless的特点就是随用随加载,不用即卸载,那么对于长时间占用主机的应用,不太适合,拿用车来比喻,需要的时候租个车,用完还掉,不需要承担维护成本和车位等费用,而当你需要长期使用车的时候,很多事直接买一辆更合算

  • 调试困难

从目前提供serverless服务的几个公有云平台看,目前提供的调试工具都不太好用,肯定没有自己的服务器调试来的方便

结合serverless的优缺点,目前serverless比较适合的应用场景如下:

  • 音视频等媒体资源处理
  • 简单的web应用
  • 工具类应用
  • AI计算/分析类应用
  • 小程序服务端

实例

平常对于音频、视频的处理,主要是在服务器,结合docker,有音频、视频处理任务的时候,会调用命令启动一个用后删除的容器来处理,音视频的处理大多比较耗CPU资源,所以开服务器还不能开配置低的,不处理音频、视频的时候,资源又有点浪费,正好结合函数计算和OSS来将这部分任务放到云函数中

函数计算中已经有基于FFmpeg的弹性高可用音视频处理的函数应用,直接利用这个模板看下处理效果

模板提供以上几个已经写好的函数,直接通过模板部署,创建一个应用

看一下函数列表

这里就直接看video转gif函数吧,点击函数,可以在线编辑代码

编写好函数后,可以通过编写测试的触发事件进行测试,这里先在OSS上传一个视频,然后看下效果(动图,耐心看)

执行完成或出错都会有友好的错误输出供参考调试

也可以定义触发器,这里由于我只是写个例子,所以直接通过SDK,以HTTP的方式触发,所以这里不创建触发器,触发器能很好的对请求进行统一管理,比如当OSS有资源上传即处理,这种方式,创建触发器来统一管理

SDK的调用也很简单,比如我这里用python调用,只需要安装aliyun-fc2的依赖就可以调用

通过以上实例可以看到,对于开发人员来说,完全没必要管底层环境,对于以前用ffmpeg,需要在服务器安装比较麻烦的环境,即便使用容器,也需要制作镜像,下载镜像,而且对于开发来说有一定的学习成本,而通过serverless这种方式,对于开发人员来说确实提高了效率

也有人说serverless会取代kubernetes,其实不然,Kubeless就是一款基于kubernetes的serverless FaaS平台,Kubeless官方强调,它是Kubernetes原生(Kubernetes native)的serverless实现,它除了Kubernetes原生的组件外,支持用户定制容器镜像来自定义函数的执行环境,所以serverless将来更多的会和kubernetes结合使用,而不是取代

对于运维来说,要做的只能是学习并接受新技术,并尝试应用到实际项目中,会的东西多,自然不会担心被淘汰

0 人点赞