本篇概览
- 本文是《OpenFaaS实战》系列的第六篇,前文咱们了解了watchdog,在懂得原理之后又引发了担忧:每次响应web请求都要fork一个进程,这种方式可能会有性能问题;
- 如果每个请求都要创建进程,做为一个Java程序员是无法接受的,Java之父马士兵老师在B站的谆谆教诲犹在耳畔想起:线程池、异步响应、NIO...
- 前文的文末也剧透过,上述性能问题已被解决,而具体的解决方式就是本文的主要内容:of-watchdog;
上古秘籍的启示
2020年3月出版的《深入浅出Serverless》一书中,陈耿老师提到为了优化watchdog性能,OpenFasS正在孵化一个全新的watchdog实现:of-watchdog,如下图:
不要过于乐观
- 目前官方对of-watchdog的态度,是乐观又小心谨慎,因此,要提前把风险暴露出来,请您在决策是否用于生产环境时作为参考;
- 首先是指出of-watchdog正在变得普及:
- 以下是支持of-watchdog的模板,如下图红框,仅仅是可用于测试(avilable for testing),看来里生产环境可用还是有段距离的:
初探
- 有了陈耿老师的提示,就去of-watchdog官网了解详情,地址是:https://github.com/openfaas/of-watchdog ,下图红框中的话是最简单形象的解释:
- 虽然欣宸的英语很渣,但还是看懂了上图红框里的意思:of-watchdog是函数和微服务之间的反向代理
- 大多数人和我一样秒懂了,但我还是想解(mai)释(nong)一下,先看看典型的反向代理,如下图,浏览器访问电商网站时,订单服务和购物车服务的请求都发到同一个Nginx,Nginx根据请求URL将请求转发到不同的Tomcat上去,浏览器只知道Nginx,不知道正真执行任务的是Tomcat,此时的Nginx就是反向代理:
- of-watchdog是
函数和微服务之间的反向代理,我这边脑补出的效果如下:
- 而且官方提到了微服务,我这边本能的感觉就是:前文的watchdog转发请求是走STDIN,而of-watchdog这里应该不走STDIN了,而是http,毕竟martinfowler对微服务的定义中就指出要处理http请求,如下图红框:
- 事实证明,of-watchdog的实际情况比我的脑补结果复杂,因为of-watchdog有模式(mode)的概念,接下来细看各种模式下的of-watchdog到底是什么?
http mode
- of-watchdog的默认模式是http模式,部署服务时of-watchdog会fork一个进程(假设为进程A),进程A会监听一个端口,of-wahtchdog收到的所有请求都会转发到进程A监听的端口,官方架构图如下:
- 看完上述架构图有种如释重负的感觉,咱们写的代码是在右侧的child里面执行的,这个child从3000端口收到of-watchdog转发过来的外部请求,然后内部处理掉,这不就是tomcat的做法么,前文留下的担忧此时烟消云散了;
- 官方对of-watchdog的优点描述如下(请原谅我的不入流翻译):
- 第一,并发性能和吞吐量最优;
- 第二,相比watchdog,对内存的使用更高效;
- 第三,建好的数据库连接可以反复使用;
- 第四,容器操作系统的临时文件夹(/tmp/目录),是所有请求共用的,例如可以做临时缓存用;
- 第五,好像是关于Node和Python的,我实在读不懂,请您自己看原文吧:
Does not require new/custom client libraries like afterburn but makes use of a long-running daemon such as Express.js for Node or Flask for Python
- 尽管咱们的问题已经找到了答案,但除了http模式,of-watchdog还有其他几种模式也建议您简单了解,有的场景下还是用得上的;
serializing mode
使用了该模式,of-watchdog就和前面的watchdog没啥区别了,就是用来和watchdog保持兼容的;
streaming mode
- 该模式下,每收到一个请求,会fork一个进程来处理;
- 该模式的特点是可以处理比容器内存还大的请求body,例如容器内存只有512兆,但是能处理上G的请求body(这么大的body一般是多媒体内容,例如视频)
- 从名称streaming可见,处理文件流的函数,适合使用此模式;
static mode
- static模式下,of-watchdog扮演的角色和nginx类似:收到请求后去指定目录读取静态文件返回(例如xxx.html文件),官方给出详细demo的参考地址:https://www.openfaas.com/blog/serverless-static-sites/
afterburn mode
最后一个是afterburn模式,正在我精疲力尽的时候,发现官方宣布此模式已经废弃(如下图),太好了,可以不用关心这个模式了!
- 嘴上说不关心,但是忍不住多看一眼afterburn模式的架构图,如下图,被fork的进程与父进程之间有HTTP通道,并且of-watchdog还能通过STDIN输入,并且能接收子进程的STDOUT,这个架构有点烧脑,不过可以不用关心了,因为它被废弃了: