换个角度聊聊FaaS

Serverless/FaaS伴随着k8s的热度增加，也成为了热门话题。相关文章介绍了很多，这里笔者不一一赘述，而是从个人见解上聊聊关于FaaS的架构和意义。

FaaS可能的架构优化

从AppEngine到docker的演变启发

在笔者上学时，云计算刚刚火热，IaaS/PaaS/SaaS的基础概念已经逐渐深入人心。其中PaaS平台的代表形式就是App Engine，其中最知名的当属google的GAE。GAE可以说取得了一定的成功。但是与后来的docker的巨大成功相比，就略逊一筹了。docker中以镜像为代表的标准化交付方式，较之于GAE的源码式交付，可以得到更为灵活和广泛的应用，对使用各种语言和框架开发的应用也更加友好，许多运行环境的问题如依赖等也更容易得到解决。

谈FaaS为什么会谈到这个。主要是因为笔者看到目前的FaaS平台很多都是通过上传源码来进行支持的，比如支持python/java等。这不由得让笔者想起GAE的使用。诚然，这种方式更容易管理和标准化。但是如果考虑到很多应用已经使用不同的语言和框架进行了大量的开发。那么这样的方式很可能也会局限FaaS的应用范围，使得很多应用的迁移成本增加，甚至导致难以迁移。笔者认为，未来的一个可能方式就是参考docker，以镜像的方式进行function的交付。对其输入输出配置等进行规约标准，使得应用的迁移主要关注于架构的调整，而非代码的重构。同时，这样的交付方式也更容易摆脱对于平台或者厂商的依赖，得到更为广泛的支持。

镜像系统的优化

假使都使用镜像来进行交付，那么带来的一个问题就是镜像的种类多样、镜像拉取时间过长的问题。大量的镜像可能会带来一些管理方面的工作。另外，容器的启动时间也会严重依赖于镜像的拉取时间。使得镜像拉取成为需要重点优化的一个过程。

镜像拉取其实主要是两部分，一部分是从镜像仓库中将镜像文件下载下来，另一部分则是将镜像文件进行解压并拷贝到对应层的过程。在内网环境下，前者的速度其实非常快。而由于大量小文件的原因，后者的速度往往会成为实际的镜像拉取瓶颈。以笔者看来，可以考虑将镜像存储直接存储于分布式文件系统中。这样容器启动无需再去拉取镜像，而可以直接启动，将大大缩短容器的启动时间。分布式的镜像存储可以有多种实现方式，这个以后有时间再做专题讨论。

FaaS的调度意义

FaaS的优点如简化运维、提高开发效率等，在许多文章中都已经提到了。这里主要提的是在私有云中，FaaS对于提升数据中心的调度质量，也有巨大的意义。

通过FaaS的改造，应用的运行方式从long running的任务转变成为batch job。在原有的架构中，由于应用的负载难于预测（不确认任务会何时到来），出于安全方面等原因，会导致资源的空置。改造为FaaS后，可以实现资源的随取随用。且由于function的容器拥有计算资源需求较小、延迟不敏感等特点，可以将容器用以充塞各个节点上的资源碎片，加以充分利用。并辅以驱逐系统，可以充分保证业务的资源使用。这样以来，可以提升整个数据中心的资源使用效率，达到节约成本的目的。而且由于FaaS的延迟容忍、时间可控的特性，在调度规划方面也会有很大帮助。

至于FaaS的应用场景，在笔者接触的领域，目前其可以使用的范围较窄，主要集中于图片预处理等环节。以笔者的猜测，在一些延迟交互的领域，如短视频、AI等可能会有更为广阔的前景。