丨原理faas的兩種進(jìn)程模型及應(yīng)用場(chǎng)景

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