歡迎訪問我的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