說 FaaS 先要說說 PaaS

平臺(tái)即服務(wù)（Platform as a Service）是一種云計(jì)算服務(wù)次员，提供運(yùn)算平臺(tái)與解決方案堆棧即服務(wù)。在云計(jì)算的典型層級(jí)中王带，平臺(tái)即服務(wù)層介于軟件即服務(wù)與基礎(chǔ)設(shè)施即服務(wù)之間淑蔚。 平臺(tái)即服務(wù)提供用戶能將云基礎(chǔ)設(shè)施部署與創(chuàng)建至客戶端，或者借此獲得使用編程語言辫秧、程序庫與服務(wù)束倍。用戶不需要管理與控制云基礎(chǔ)設(shè)施，包含網(wǎng)絡(luò)盟戏、服務(wù)器绪妹、操作系統(tǒng)或存儲(chǔ)，但需要控制上層的應(yīng)用程序部署與應(yīng)用托管的環(huán)境柿究。

引用自維基百科

簡(jiǎn)單來說邮旷，PaaS 就是把計(jì)算能力放在線上，你只管寫代碼就行了蝇摸，目的也是為了減少后端維護(hù)的成本婶肩，讓開發(fā)者更關(guān)注到開發(fā)本身。國內(nèi)有 Sina App Engine貌夕，國外有 Heroku律歼、Google App Engine、Amazon Web Services啡专，但是這類服務(wù)被真正用來做產(chǎn)品的并不多险毁，大多是當(dāng)作開發(fā)的試驗(yàn)田跑一下，而且跑起來的成本比獨(dú)立部署個(gè)服務(wù)器也差不多们童，你要理解很多服務(wù)的相關(guān)性畔况，應(yīng)用運(yùn)行時(shí)還有提供各種服務(wù)的橋接，就造成你需要去理解一大堆東西才能把他們五花大綁到一起慧库，所以這類服務(wù)并沒有成為真正的主流跷跪，更多的是還是用原生的計(jì)算能力，比如 Amazone EC2齐板、AWS 這類 IaaS 平臺(tái)吵瞻，國內(nèi)的阿里云葛菇、UCloud 等。

PaaS 有不少缺點(diǎn)橡羞。

1熟呛、對(duì)計(jì)算能力不可掌控

PaaS 將自己的運(yùn)行時(shí)封裝成了一個(gè)黑盒子，你要用他你就要基于這些黑盒子的約束和條件去自行判斷尉姨，需要了解每個(gè)模塊或者函數(shù)的可用性和限制是什么，才能更好的開發(fā)吗冤，為了避免應(yīng)用有太高的權(quán)限造成安全問題又厉，服務(wù)商往往的做法是裁剪，將限制的能力來提供給你椎瘟，那么如果你要開發(fā)一個(gè)應(yīng)用覆致，本地能用，部署了可能會(huì)有各種兼容問題肺蔚。

一個(gè)完整的應(yīng)用煌妈，在基于 PaaS 去開發(fā)的時(shí)候，勢(shì)必會(huì)有服務(wù)的依賴宣羊，對(duì)于這些服務(wù)的依賴璧诵，你也是沒有掌控能力的，你只能基于給出的環(huán)境變量是去配置仇冯，但是往往在復(fù)雜應(yīng)用中之宿，對(duì)于服務(wù)的依賴非常深入，可能會(huì)有比較深入的使用和調(diào)優(yōu)苛坚，這個(gè)只能束手無策比被。

2、線上開發(fā)調(diào)試模型復(fù)雜

一個(gè)完整的應(yīng)用就是一個(gè)功能集合泼舱，開發(fā)調(diào)試起來是很麻煩的等缀，想象一下如果一個(gè)很龐大的網(wǎng)站，有一大堆的功能娇昙，你依賴可能十幾個(gè)甚至二十幾個(gè)服務(wù)尺迂，跑在你不太知道的黑盒子，你的調(diào)試該多麻煩涯贞。如果是你自己的環(huán)境枪狂，你可以隨意的開啟 DEBUG 參數(shù)、去查看系統(tǒng)調(diào)用棧宋渔、去看硬件參數(shù)州疾、去看系統(tǒng)優(yōu)化參數(shù)、去分析運(yùn)行時(shí)的細(xì)小問題皇拣、而在 PaaS 你能做的僅僅是通過服務(wù)商提供的一個(gè)后臺(tái)來做一些簡(jiǎn)單的查看严蓖，日志的分析薄嫡。這個(gè)決定了 PaaS 不適合一個(gè)有規(guī)模的產(chǎn)品去使用。

FaaS - 函數(shù)即服務(wù)

FaaS 最終目的和 PaaS 類似颗胡，讓開發(fā)者關(guān)注在開發(fā)本身毫深，服務(wù)由服務(wù)商提供。那 FaaS （Function as a Service）是什么呢毒姨？我為什么覺得它是未來開發(fā)的一個(gè)趨勢(shì)⊙颇瑁現(xiàn)在 FaaS 的說法還不太一致，但是可以明確的是** FaaS 是 PaaS 能力的一種縮放弧呐，縮放到 Function 級(jí)別**闸迷。FaaS 可以將函數(shù)作為一個(gè)線上服務(wù)胃榕、遠(yuǎn)程計(jì)算服務(wù)心铃，可以通過 API 執(zhí)行、通過郵件執(zhí)行漾狼、通過 Iot 執(zhí)行鸠蚪，通過隊(duì)列執(zhí)行今阳。你只需要寫統(tǒng)一的函數(shù)就行了。FaaS 的入口是事件茅信，下面是 AWS Lambda 的事件流圖盾舌。

我認(rèn)為 FaaS 有以下幾個(gè)特點(diǎn)：

1、函數(shù)粒度小易于調(diào)試

對(duì)于 FaaS 來說汹押，你要寫的就是一個(gè)個(gè)函數(shù)矿筝，它就是一個(gè)功能。你要做的只是寫下如下這樣的函數(shù)棚贾，然后再用配置文件告訴服務(wù)器如何讓他運(yùn)行窖维，就完事了，你的所有工作都在這個(gè)函數(shù)內(nèi)完成妙痹。而函數(shù)本身只需要負(fù)責(zé)處理輸入和輸出铸史。（輸入和輸出是基于事件而不同的。）

在 FaaS 中函數(shù)的執(zhí)行是無狀態(tài)的怯伊，函數(shù)運(yùn)行時(shí)本身是封裝在一個(gè)容器內(nèi)琳轿，執(zhí)行完后所有的的狀態(tài)都會(huì)被銷毀（當(dāng)然為了優(yōu)化，可能會(huì)緩存一段時(shí)間）耿芹，但是最終不要期望通過有狀態(tài)的方式來運(yùn)行函數(shù)崭篡，這是對(duì)于函數(shù)本身的限制。試想只需要定義好輸入吧秕，就能來調(diào)試函數(shù)了琉闪，測(cè)試來說會(huì)非常方便，而 PaaS 是一個(gè)復(fù)雜的合集砸彬，你的調(diào)試的方便性由你的寫法決定颠毙。

2斯入、函數(shù)可配置性

每個(gè)函數(shù)都是一個(gè)功能，這個(gè)功能如何執(zhí)行蛀蜜，依賴是什么刻两，是可以通過配置文件來完的成，如果一個(gè)函數(shù)可配置如何執(zhí)行滴某，那么就可以讓他達(dá)到共享的目的磅摹。試想一下，你寫了一個(gè)視頻處理的功能霎奢，傳入的是一個(gè)視頻地址或者URL偏瓤，傳出的是一個(gè) GIF，那么這個(gè)函數(shù)你只需要先寫好功能椰憋，然后用配置文件定義如何運(yùn)行，如果這是個(gè) API 服務(wù)赔退，那么定義出來 HTTP 請(qǐng)求什么路徑橙依，什么方法來實(shí)現(xiàn)它；如果他需要基于隊(duì)列去執(zhí)行硕旗，那我只需要定義用什么隊(duì)列來執(zhí)行窗骑。

這是一個(gè)通過隊(duì)列讀取 S3 的 ZIP 文件解壓縮成 PNG 并上傳 S3 的例子，源代碼可以點(diǎn)原文看

對(duì)于 AWS Lambda 來說漆枚，可以抽象為以下配置（這是一個(gè)基于 AWS Lambda 的一個(gè)框架的配置）创译。正是這種機(jī)制，可以真正的實(shí)現(xiàn)函數(shù)級(jí)別的共享墙基。

3软族、初始化非常容易

如果要寫一個(gè)簡(jiǎn)單的 API 服務(wù)，就寫一個(gè)函數(shù)就夠了残制，省去了以前去折騰框架立砸，弄路由、搞一大堆配置初茶，這還不夠簡(jiǎn)單么颗祝。

4、FaaS 不確定的缺點(diǎn)：基礎(chǔ)和 PaaS 是一致的

如果真算缺點(diǎn)恼布，就是和 PaaS 是類似的：FaaS 對(duì)資源的掌控是不夠的螺戳。但是，PaaS 的缺點(diǎn)導(dǎo)致掌控性是一個(gè)較大的問題折汞；而 FaaS 本身函數(shù)運(yùn)行是比較獨(dú)立的倔幼，所有的成本都涵蓋在一個(gè)函數(shù)內(nèi)，復(fù)雜性就大大降低字支。

還有一個(gè)缺點(diǎn)凤藏，如果開發(fā)一個(gè)復(fù)雜的應(yīng)用奸忽，函數(shù)之間的調(diào)用和管理是一個(gè)棘手的問題，現(xiàn)在已經(jīng)有框架在著手解決這些問題揖庄，可以看下面相關(guān)資源的推薦栗菜。

相關(guān)資源

現(xiàn)在已經(jīng)有不少知名服務(wù)商提供此類服務(wù)，大家的實(shí)現(xiàn)各不相同蹄梢，但是思路是一致的疙筹。比如最著名的 AWS Lambda、Azure Functions禁炒、Google Cloud Functions而咆、IBM OpenWhisk。

如果覺得平臺(tái)本身復(fù)雜性略高幕袱，可以通過以下幾個(gè)框架去玩：APEX暴备、Serverless 等