丨原理faas的兩種進程模型及應用場景

咱先回想一下上節(jié)課的FaaS的冷啟動過程，我們知道容器和Runtime準備階段都是由云服務商負責的，我們只需要關注具體的函數(shù)執(zhí)行就可以了。而函數(shù)執(zhí)行在FaaS里是由“函數(shù)服務”負責的，當函數(shù)觸發(fā)器通知的“”到來時，函數(shù)服務就會根據情況創(chuàng)建函數(shù)實例，然后執(zhí)行函數(shù)。當函數(shù)執(zhí)行完之后，函數(shù)實例也隨之結束自己的使命，F(xiàn)aaS應用縮容到0，然后開始進入節(jié)能模式。上面這套邏輯是我們上節(jié)課講的，課后有同學就問，函數(shù)執(zhí)行完之后實例能否不結束，讓它繼續(xù)等待下一次函數(shù)被調用呢？這樣省去了每次都要冷啟動的時間，響應時間不就可以更快了嗎？是的，本身FaaS也考慮到了這種情況，所以從運行函數(shù)實例的進程角度來看，就有兩種模用完即毀型：函數(shù)實例準備好后，執(zhí)行完函數(shù)就直接結束。這是FaaS最純正的用法常駐進程型：函數(shù)實例準備好后，執(zhí)行完函數(shù)不結束，而是返回繼續(xù)等待下一次函數(shù)被調用。這里需要注意，即使FaaS是常駐進程型，如果一段時間沒有觸發(fā)，函數(shù)實例還是會被云服務商銷毀。模型示意這兩個模型其實也對應兩種不同的應用場景。我舉個例子，比如你要把我們第一講中的“待辦任務”應用部署上線。還記得小程同學吧，他完成了第一個版本，他用Express.js[1]框架開發(fā)的MVC架構，View層他采用流行的React[2]，并且使用了AntDesignReact件庫。Model據庫采用MongoDB。小程的第一個版本，就是一個典型的傳統(tǒng)Web服務。從可控性和改造成本角度來看Web服務，服務端部署方案最適合的還是托管平臺PaaS或者自己搭服務跑在上。正如我上一講所說，使用FaaS就必須在FaaS的條件限制內使用，最佳的做法應該是一開始就選用FaaS開發(fā)。但是小程的運氣比較好，我們查了一下文檔，發(fā)現(xiàn)FaaS的Node.js的Runtime是支持Express，所以我們只需少量修改，小程的第一個版本就可以使用FaaS常駐進程方案這里我要做個對比，在之前，假設沒有FaaS，我們要將應用部署到托管平臺PaaS上。啟動Web服務時，主進程初始化連接MongoDB，初始化完成后，持續(xù)服務器的80端口，直到端口的句柄關閉或主進程接收到終止信號。當80端口和客戶端建立完TCP，有HTTP請求過來，服務器就會將請求轉發(fā)給Web服務的主進程，這時主進程會創(chuàng)而在FaaS常駐進程型模式下，首先我們要改造一下代碼，Node.js的Server對象采用FaaSRuntime提供的Server對象，然后我們把端口改為HTTP。啟動Web服務時，主進程初始化連接MongoDB，初始化完成后，持續(xù)HTTP，直到當HTTP發(fā)生時，我們的Web服務主進程跟之前一樣，創(chuàng)建一個子進程來處理這個請求。主進程就如我們上圖中繪制的那個藍色的圓點，當HTTP發(fā)生時，它創(chuàng)建的在我看來，常駐進程型就是為了傳統(tǒng)MVC架構部署上FaaS專門設計的。數(shù)據庫也可以使用原來的DB連接方式，不過這樣做會增加冷啟動的時間（我特意在圖中用曲線代表時間增 [第1課]中，講Serverless架構時說的，數(shù)據持久化采用BaaS服務。那么我們能否用用完即毀型來部署小程的MVC構的Web務呢？可以，但是我不推薦你這樣做。因為用完即毀型對傳統(tǒng)MVC改造的成本太大。模型示意說到這里，我們再將上面對比兩個模型的示意圖鏡頭再拉遠一點，加上HTTP觸發(fā)這里我再啰嗦強調下，還是我們上一講說的，F(xiàn)aaS只是做了抽象，云服務商通過技術所以，在用完即毀型中，我們只要將MVC的Control層部署到函數(shù)執(zhí)行就可以了。這也意味著我們要將我們的MVC架構的Control函數(shù)一個個拆解出來部署，一個HTTP請求對應一個Control函數(shù)。Control函數(shù)實例啟動時連接MongoDB，一個請求處理完后直接結束。你如果要提升Control函數(shù)的冷啟動時間，Model層同樣要考慮BaaS化改造?，F(xiàn)在，理解了兩種類型，我們再來看看FaaS是怎么的，以及常駐型進程這種模式是不是會多。云服務商FaaS函數(shù)服務的標準各不相同，但他們都會提供一定的免費額度。我給你歸納下FaaS的標準，主要有兩個維度：調用函數(shù)次數(shù)和函數(shù)耗時。 oWorld例子的index.js文件的handler函數(shù)，它每調用一次，計數(shù)就加一。這種模式因為不占資源，所以資源利用率高、低。函數(shù)耗時，說的是函數(shù)執(zhí)行的運行時長，它的計算單位是CU-S，也就是CPU行了多常駐進程型改造后主要占用的是內存，而FaaS的是CPU計算時間，也就是說常駐進程的模式并不會持續(xù)。但常駐型應用的冷啟動時間會增加，所以我們要盡量避免冷啟這地方就會增加額外的費用了。這樣聽起來，是不是覺得常駐進程型改造MVC應用用起來很別扭？是的，我們前面也說了，常駐進程模式就是為了傳統(tǒng)MVC架構部署上FaaS專門Control函數(shù)的執(zhí)行時間，和MVC部署在FaaS中Control的執(zhí)行時間是一樣的。每個請相信你也可以感覺到，用完即毀型也不太適合傳統(tǒng)MVC架構改造，也是一種權宜之計。我們做開發(fā)的多多少少都知道，目前最成功最廣泛的設計模式就是MVC式。但隨著前端MVVM框架越來越火，前端View層逐漸前置，發(fā)展成SPA單頁應用。后端Control和Model層逐漸下沉，發(fā)展成面向服務編程的后端應用。這種情況下，前后端更加徹底地解耦了，前端開發(fā)可以依賴Mock數(shù)據接口完全脫離后端限制，而后端的同學則可以面向數(shù)據接口開發(fā)，但這也產生了高網絡I/O的數(shù)據網關層。Node.js的異步非阻塞和JavaScript天然親近前端工程師的特性，自然地接過數(shù)據網關層。因此也誕生了Node.jsBFFBackendForFrontend)，將后端數(shù)據和后端接口我們的程序員好朋友小程也跟進了這個潮流，將“待辦任務”Web服務重構成了第二個版本。他將原先的應用拆解成了2個項目：前端項目采用React+AntDesignPro+Umi.js[4]的單頁應用，后端項目還是采用Express。我們本專欄的示例也采用這個技術架構一步一步教你在云上部署SPA+FaaS混合框架演進。BFF示意如上圖所示，BFF層充當了中間膠水層的角色，粘合前后端。加工的數(shù)據，我們稱為元數(shù)據RawData，對于普通用戶來說元數(shù)據幾乎不可讀。所以我們需要將有用的數(shù)據組合起B(yǎng)FF層通常是由處理高網絡I/O的Node.js應用負責。傳統(tǒng)的服務端運維Node.js應用還是比較重的，需要我們虛擬機，或者使用應用托管PaaS平臺。因為BFF只是做無狀態(tài)的數(shù)據編排，所以我們完全可以用FaaS完即毀型模型替換掉BFF層的Node.js應用，也就是最近圈子里老說的那個新名詞SFF（ServerlessFor好，到這兒，我們已經理解了BFF到SFF的演進過程，現(xiàn)在我們再串下新的請求鏈輯。前端的一個數(shù)據請求過來，函數(shù)觸發(fā)器觸發(fā)我們的函數(shù)服務，我們的函數(shù)啟動后，調用后端提供的元數(shù)據接口，并將返回的元數(shù)據加工成前端需要的數(shù)據格式。我們的FaaS函數(shù)完全就可以休息了。具體如下圖所示。SFF示意另外，除了我們自己的后端應用數(shù)據接口，互聯(lián)網上還有大量的數(shù)據供我們使用，比如期間，你要爬取下各個地區(qū)的數(shù)據、天氣數(shù)據，這些工作，也都可以放到FaaS上輕松搞定。并且，基本還能免費，因為目前各大云服務商都提供了免費的額度，這個我剛給你講過了。編排后端接口、編排互聯(lián)網上的數(shù)據，這倆場景你也很容易想到。不過，我覺得，編排云服務商的各種服務才能讓你真正體會到那種觸電的感覺。我第一次體驗之后，就對我同事說，“變天了，真的變天了，喊了這么多年的云計算時代真的來了”。服務編排和數(shù)據編排很像，主要區(qū)別是對云服務商提供的各種服務進行組合和加工。在FaaS出現(xiàn)之前，就有服務編排的概念。但服務編排受限于服務支持的DK語言版本，常見的情況是我們用yaml文件或命令行來編排服務。我們要使用這些服務或API，都要通過自己熟悉的編程語言去找對應的SDK，在自己的代碼中加載DK，使用秘鑰調用DK方法進行編排。就和數(shù)據編排一樣，服務端運維部署成本非常高。而且如果沒有SDK，則需要自己根據平臺提供的接口或協(xié)議實現(xiàn)SDK?，F(xiàn)在有了FaaS，F(xiàn)aaS拓展了我們可以使用SDK邊界。這是什么意思呢？比如小程的“待辦任務”Web服務需要發(fā)送郵件。我們可以用一個用完即毀型FaaS函數(shù)，調用云服務商的SDK發(fā)送郵件，再用一個常駐進程型FaaS函數(shù)生成隨機字符串，生成后記錄這個，并且調用發(fā)送郵件的FaaS將發(fā)給用戶郵箱。用戶驗證時，我們再調用常駐進程型FaaS的方法校驗是否正確。我還是用阿里云來舉例，我們查閱阿里云的郵件服務文檔，發(fā)現(xiàn)它只支持Java、PHP和Python的SDK。都是在講Node.js，這里沒有Node.js的SDK，怎么辦？如果我們根據阿里云郵箱服務的文檔，自己開發(fā)Node.jsSDK，那肯定是饒了彎路，廢了沒因為我們發(fā)送郵件的用完即毀型FaaS函數(shù)功能很單一，所以我們完全可以參考郵件服務的PHP文檔，就用PHP的SDK創(chuàng)建一個FaaS服務來發(fā)送郵件的。你會發(fā)現(xiàn)使用PHP郵件你會看到在這個例子中，我用了我并不太熟悉PHP語言編排了郵件發(fā)送服務。不知道你意識到沒有，這個也是FaaS一個亮點：語言無關性。它意味著你的團隊不再局限于單一的開發(fā)語言了，可以利用Java、PHP、Python、Node.js各自的語言優(yōu)勢，混合開發(fā)出復FaaS服務編排被云服務商特別關注正是因為它具備的這種開放性。使用FaaS可以創(chuàng)造出務甚至我還知道，西雅圖就有創(chuàng)業(yè)團隊利用FaaS服務編排能力做了一套開源框架Pulumi[5]，并且還拿到了融資。感的話，你可以去他們的官網看看好，到這里，我們這節(jié)課的內容就講完了。我再來總結一下這節(jié)課的關鍵FaaS的進程模型有兩種：常駐進程型和用完即毀型。常駐進程型是為了適應傳統(tǒng)MVC架構設計的，它看起來并不自然。如果你從現(xiàn)在開始玩FaaS的話，我當然首選推薦用完即毀型，它可以最大限度發(fā)揮FaaS的優(yōu)勢。追溯歷史，我給你梳理了前后端分離發(fā)展出的BFF，然后BFF又可以被SFF替代。不管是內部的接口編排，還是外部一些數(shù)據的編排，F(xiàn)aaS都可以發(fā)揮出極大優(yōu)勢，你看看我從數(shù)據編排再進一步，我們可以利用FaaS和云服務商云服務的能力，做到服務編排，編排出更加強大的組合服務場景，提升我們的研發(fā)效能。并且通過我這么長時間的體驗，我還想感嘆說，依賴云服務商的各種能力，再通過FaaS編排開發(fā)一個項目時，往往可以做到事半功倍。今天的作業(yè)和上一講類似，我中給你做了個簡單的Demo。你可以隨便找個云平臺去run下試試，百聞不如一見，體驗完之后，你可以在留言區(qū)談談你的感想。另外，如果今我