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

欢迎访问我的GitHub

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

OpenFaaS实战系列文章链接

  1. 部署
  2. 函数入门
  3. Java函数
  4. 模板操作(template)
  5. 大话watchdog
  6. of-watchdog(为性能而生)
  7. java11模板解析

本篇概览

  • 本文是《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函数;

你不孤单,欣宸原创一路相伴

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 数据库+中间件系列
  6. DevOps系列

欢迎关注公众号:程序员欣宸

微信搜索「程序员欣宸」,我是欣宸,期待与您一同畅游Java世界…

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页