商业和开源的faas伸缩性比较

Problem motivation

最近faas越来越火，将来或许会成为主流，因为faas让开发者更关注于代码开发，不用负责服务器的管理，并且易于拓展和伸缩。为了与时俱进，跟上时代洪流，我想要调查并研究已经存在的faas实现方案，并对它的伸缩性等性能做测试、分析和总结。

Related work

调查发现Faas有商用的平台的和开源的方案，因此我觉得在商用和开源各选择一个比较有代表性的faas作品来做测试、分析。

市面上目前faas商用做的比较好的有Aws lambda，google cloud funtions，azure functions，开源做的比较好的是openfaas，因此商用我选用azure functions，开源选择openfaas的。

我们准备调查研究商业用的azure faas和开源的openfaas在性能，伸缩性等有什么区别。

商用faas（azure functions）的相关工作

登录azure，使用了学校的订阅，并使用了学校分配的资源组，创建了funtion，选择的语言是python，为了方便开发和测试，我可以使用两种方式连接和部署azure function。第一种：本地下载visual studio code，通过拓展库的azure function连接azure，然后编写python函数代码；第二种是直接通过azure提供的平台去编写python代码。

Openfaas的相关工作

在azure创建一个k8s服务，研究如何部署openfaas，并对外暴露端口，如何远程拉取docker hub的镜像，如何使用metrics server对流量监控，实现自动伸缩的能力，对docker，k8s等命令和原理做了解，研究如何使用faas-cli。

Experimental design

本次实验主要是对商用的faas（选用azure function）和开源的openfaas做性能测试（主要是对伸缩性做测试），实验会测试两个方面，一个是测试cpu的伸缩性；第二个是测试内存的伸缩性。

对于测试cpu

我会选择做nxn的矩阵乘法，并且n会固定传1000，矩阵随机生成，每个请求耗时都在500-600毫秒之间，我会通过jmeter开启多线程在1200秒内一共会有24000个线程一起请求对应的function地址；因为是在大流量的情况下，可能会出现响应失败的情况，这个时候我会着重观察是否在一段时间后可以恢复响应；如果成功返回，那么我会在返回的主体中，返回当前主机的mac地址，以便让我知道faas是否做了自动伸缩，以保证它的稳定性，可用性。

对于测试内存

我会选择写文件，通过开启jmeter多线程并发访问对应的function，function做的主要工作是，使用io流对文件进行写入，字符的数量是20000000，和测试cpu时的类似，字符串长度和字符串本身的字符都是随机生成的，但是为了避免大批量的写文件导致文件过度堆积或者避免手动删除的负担，我会选择写入/tmp里，因为linux对这块区域使用了定时清理，所以让我更放心的去测试，同时我也会观察是否正常响应，如果正常响应我也还是会打印出它的mac地址，已确认是否扩容，扩容的量是多少；如果没有正常返回，我还是会继续多线程访问，直到它扩容到足够能成功响应的时候，并记录它的时间。

共同的部分：

为了保证函数的健壮性，需要对可能异常的代码块做好try except防止程序异常导致崩溃。对于程序的出入口，出现异常跳转的代码块都要做好日志埋点，方便跟踪整个链路，以便还原发生的事件。

为了测试伸缩性，我会使用apache的Jmeter，通过设置线程组，http请求来并发的发送请求，通过增加监听器：观察树，聚合报告，响应图来检验和分析整个过程，最终得出结论。

Implementation

Azure function

我们通过vs code安装azure function的拓展插件，通过跳转网页登录后，选择function，并在本地构造一个工作区后，可以开始编写function了，按照上述说的，我主要选择两种方式测试它的性能（主要是伸缩性），第一是cpu密集型的任务，第二是对内存和磁盘io的。cpu密集型任务我编写的两个1000x1000矩阵相乘，计算任务做完后，我会返回当前机器的mac地址，以便让我确认是否有扩容的操作，并且整体时间我控制在500-600毫秒返回，当大并发的情况下，它不得不扩容才能成功的返回响应。对于内存和磁盘io做伸缩性测试，主要是做写文件的操作，因为磁盘非常大，挺难做扩容的，所以主要还是对内存做压力测试，看看是否有扩容操作，python有一个库专门是针对每个系统的临时存储区做一些io操作的，这个库名是tempfile，通过tempfile我们就不用手动定位临时文件区的位置，直接通过这个库就能实现，我固定往里面写入20000000个字符串，相信20000000字符串就算存入内存中也是一笔开销，并且我还通过并发去请求，几千几万流量打进来，内存再大肯定也顶不住，得做扩容才行。通过vs code很容易就把代码上传到azure function即可调用测试，非常方便。

Openfaas

要部署openfaas就比azure function要困难和麻烦的多了，首先我们需要借助k8s的能力，在azure建立了一个k8s服务，并且选择自动扩容（这是很关键的一步），我选择的最小节点池大小为1，最大为105，通过azure本地的shell登录进了k8s机器里，通过helm下载了openfaas服务，并且通过kubectl命令部署了openfaas，并且对外提供访问的能力，接下来我们下载faas-cli，这个是openfaas的客户端，我们可以把代码通过faas-cli去和openfaas做交互并部署函数。通过faas-cli新创建一个函数，faas-cli会帮我们生成好handler.py, yaml文件，requirements.txt文件等，然后通过faas-cli build构建好整个环境，faas-cli push把function打包成镜像上传到docker hub上保存，然后可以通过faas-cli deploy把上传到docker hub上的镜像拉下来部署，并且会返回部署成功的ip地址和端口号。比较方便的一点是k8s自带了metrics server，所以流量监控这块已经做好准备，我们只需要设置触发扩容的阈值就可以了，通过kubectl hpa可以设置对外暴露服务的扩容阈值，并且最大和最小节点数都会打印出来。代码和azure function所部署的类似，所以就不做再次说明了，不同的可能是返回体，因为azure在python上有自己的库，也有自己的返回类型，而在openfaas我可能只是简单的返回str类型。

并且不管是openfaas还是azure function我都做好了日志输出，在函数被调用的时候，出现异常的时候，正常返回的时候，都做了日志埋点，方便跟踪整个链路。

Results

[贴图]（感兴趣的可以通过私信向我要源码和过程截图）

Quality of evaluation

前言

Azure function和openfaas都是用于构建无服务的工具，本实验其实有非常多的局限性，所以只能做参考。因为尽管openfaas和azure function都有着伸缩性，可以根据当前请求量等做自动缩放，但是azure functions毕竟是一个完全托管的服务，并且有着强大的azure平台支撑，是按照流量计算消费，所以伸缩性在理论上可以理解成无限大。但是我们的openfaas需要借助k8s的自动扩缩容能力，通过metrics server收集cpu使用率和内存使用率也可以做到自动缩放（根据需要增加或减少资源），如果只是瞬间的高并发，可能就不会实现扩容，并且扩容需要一定的时间，在这段时间里，如果生产者远远慢于消费者，那么还是会出现服务不响应的问题。所以对于openfaas的测试我会在一段时间内持续的访问，以便看到它扩容的过程。

cpu

对于openfaas的cpu伸缩性测试来说，我们可以发现，在没有通过网络访问之前，cpu的指标维持在比较低的一个水平，在我们开始启动多线程，不断的进行加压访问后（比如一秒启动10个线程），马上就开始出现崩溃的情况，频繁的出现socket连接问题，k8s过了一段时间才逐渐反应过来，我们可以从图片中看到，k8s在控制节点池的增加，pod也在开始不断的扩容。过了一段时间后（大约4分钟），k8s已经扩容到了足够接纳我访问的地步，渐渐的能响应我的访问，我们可以看到cpu一开始维持在比较高的水平，在扩容节点后，节点池中的每一个节点都承受了一部分访问压力，做到了负载均衡，同时我们可以看到响应时间一开始非常高，后面就在某个区间来回波动了。并且在我断开jmeter的压力测试，节点池和pods根据当前cpu的情况都在不断的缩容，最终缩到一个节点池和一个pod。

而azure function令我比较惊讶的是，对于同一个function它一开始承受的压力远远比我对openfaas施加的压力大2倍，但一开始也没有报错，通过图片可以看出来，所有的http请求都得到正面的回应，并且我们看到返回的mac地址，都是不同的主机做的返回，也就是说azure function的扩容能力非常强大，同时我也尝试了过了半个小时后使用一个线程不断的同步访问，发现都是返回的同一个mac地址，所以azure function一开始就只部署在了一台主机上，并且在一开始就做到了应对如此大的流量，并且它的扩容时间非常的短暂，非常的令我惊讶，同时我们可以发现响应时间图一直在某个区间波动，比较的平稳。

Memory

对于openfaas的内存伸缩性测试，我们可以看到，在访问之前，我们先部署到了k8s上，并且在jmeter创建好脚本，准备做并发访问，当前的内存使用率维持在35%左右，随后我们开始做并发压力访问，很快的出现了测试cpu伸缩性时候出现的问题，刚开始或许能成功的做一些返回，但是随后随机流量的加大，很快就出现了请求失败的问题，一方面是因为访问一次所需要的时间的确比较久，大概1-2s才能返回，第二个是因为它的扩容需要时间，我们能发现过了一端时间后，大概5分钟，他就能承受住我们的流量，访问后开始逐步的能返回结果了，我们可以看到内存值在不断的波动，并且达到设置的阈值后，不断的扩容节点池和pods，使得每个pod都维持在阈值以下，并且时间响应图能看出来，响应时间在某个时间达到了高峰，后面就下降到一个区域，维持成了一条平稳的直线。在关闭了脚本，关闭了多线程后，我们发现节点池在变少，pods也在不断缩容。

Azure function的内存伸缩性测试和cpu伸缩性测试一样，让人非常的赞叹，持续的正常响应，它的毫秒级内存波动也是挺大的，时间响应在一开始达到了巅峰，但是在短短20秒内做到了快速的下降，并且维持一条直线，实在是令我惊讶不已。

总结

总的来说，azure function有着强大的平台做支撑，伸缩能力强，扩容时间短，文档全面，并且有实时的技术支持，各方面都做到比较完善，但是毕竟是商用，所以收费是需要的。

Openfaas也有着自己的社区和全面的文档，但是在技术实现上，可能需要借助k8s或者使用openfaas pro实现自动伸缩的能力，并且扩容缩容的时间还需要配置好，以免出现流量过大导致扩容不及时，更好的做法可能是在一开始就部署一部分的节点，以应对一开始的大流量。同时openfaas是开源的，所以如果想要寻求帮助，解决可能没有azure专人解答高效。但毕竟是开源的，在大家的努力下，将来或许会成为一款性能顶级的faas实现方案。

Code/scripts

[贴代码]（感兴趣的可以通过私信向我要源码和过程截图）

【b站和微信都可搜Knight洪爵】

愿每个人都能带着怀疑的态度去阅读文章并探究其中原理。

道阻且长，往事作序，来日为章。

期待我们下一次相遇！