歡迎訪問我的GitHub
https://github.com/zq2599/blog_demos
內容：所有原創文章分類匯總及配套源碼，涉及Java、Docker、Kubernetes、DevOPS等；
OpenFaaS實戰系列文章鏈接
- 部署
- 函數入門
- Java函數
- 模板操作(template)
- 大話watchdog
- of-watchdog(為性能而生)
- java11模板解析
- OpenFaaS實戰之八：自制模板(maven+jdk8)
- OpenFaaS實戰之九：終篇，自制模板(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函數；
你不孤單，欣宸原創一路相伴
你不孤單，欣宸原創一路相伴
歡迎關注公眾號：程序員欣宸
微信搜索「程序員欣宸」，我是欣宸，期待與您一同暢游Java世界...
https://github.com/zq2599/blog_demos