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

很早就关注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结合使用，而不是取代

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