换个角度聊聊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等可能会有更为广阔的前景。