OpenFaaS实战之六：of-watchdog(为性能而生)

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

OpenFaaS实战系列文章链接

1. 部署
2. 函数入门
3. Java函数
4. 模板操作(template)
5. 大话watchdog
6. of-watchdog(为性能而生)
7. java11模板解析
8. 自制模板(maven+jdk8)
9. 终篇，自制模板(springboot+maven+jdk8)

本篇概览

• 本文是《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，这个架构有点烧脑，不过可以不用关心了，因为它被废弃了：

展望

• 看完of-watchdog的设计后，咱们已经知道，之前的实战写的代码以微服务的形态提供服务，这一点引起了我的好奇，下一篇文章，欣宸会以一个普通Java开发者的身份去探索这个秘密：OpenFaaS环境下，咱们写的Java类为何会以微服务形态运行？
• 这不是刨根问底或者吹毛求疵，而是为了后面可以更加随心所欲的开发OpenFaaS函数；