說 FaaS 先要說說 PaaS

平臺即服務（Platform as a Service）是一種云計算服務，提供運算平臺與解決方案堆棧即服務。在云計算的典型層級中，平臺即服務層介于軟件即服務與基礎設施即服務之間。 平臺即服務提供用戶能將云基礎設施部署與創(chuàng)建至客戶端，或者借此獲得使用編程語言、程序庫與服務。用戶不需要管理與控制云基礎設施，包含網(wǎng)絡、服務器、操作系統(tǒng)或存儲，但需要控制上層的應用程序部署與應用托管的環(huán)境。

引用自維基百科

簡單來說，PaaS 就是把計算能力放在線上，你只管寫代碼就行了，目的也是為了減少后端維護的成本，讓開發(fā)者更關注到開發(fā)本身。國內(nèi)有 Sina App Engine，國外有 Heroku、Google App Engine、Amazon Web Services，但是這類服務被真正用來做產(chǎn)品的并不多，大多是當作開發(fā)的試驗田跑一下，而且跑起來的成本比獨立部署個服務器也差不多，你要理解很多服務的相關性，應用運行時還有提供各種服務的橋接，就造成你需要去理解一大堆東西才能把他們五花大綁到一起，所以這類服務并沒有成為真正的主流，更多的是還是用原生的計算能力，比如 Amazone EC2、AWS 這類 IaaS 平臺，國內(nèi)的阿里云、UCloud 等。

PaaS 有不少缺點。

1、對計算能力不可掌控

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

一個完整的應用，在基于 PaaS 去開發(fā)的時候，勢必會有服務的依賴，對于這些服務的依賴，你也是沒有掌控能力的，你只能基于給出的環(huán)境變量是去配置，但是往往在復雜應用中，對于服務的依賴非常深入，可能會有比較深入的使用和調(diào)優(yōu)，這個只能束手無策。

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

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

FaaS - 函數(shù)即服務

FaaS 最終目的和 PaaS 類似，讓開發(fā)者關注在開發(fā)本身，服務由服務商提供。那 FaaS （Function as a Service）是什么呢？我為什么覺得它是未來開發(fā)的一個趨勢。現(xiàn)在 FaaS 的說法還不太一致，但是可以明確的是** FaaS 是 PaaS 能力的一種縮放，縮放到 Function 級別**。FaaS 可以將函數(shù)作為一個線上服務、遠程計算服務，可以通過 API 執(zhí)行、通過郵件執(zhí)行、通過 Iot 執(zhí)行，通過隊列執(zhí)行。你只需要寫統(tǒng)一的函數(shù)就行了。FaaS 的入口是事件，下面是 AWS Lambda 的事件流圖。

我認為 FaaS 有以下幾個特點：

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

對于 FaaS 來說，你要寫的就是一個個函數(shù)，它就是一個功能。你要做的只是寫下如下這樣的函數(shù)，然后再用配置文件告訴服務器如何讓他運行，就完事了，你的所有工作都在這個函數(shù)內(nèi)完成。而函數(shù)本身只需要負責處理輸入和輸出。（輸入和輸出是基于事件而不同的。）

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

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

每個函數(shù)都是一個功能，這個功能如何執(zhí)行，依賴是什么，是可以通過配置文件來完的成，如果一個函數(shù)可配置如何執(zhí)行，那么就可以讓他達到共享的目的。試想一下，你寫了一個視頻處理的功能，傳入的是一個視頻地址或者URL，傳出的是一個 GIF，那么這個函數(shù)你只需要先寫好功能，然后用配置文件定義如何運行，如果這是個 API 服務，那么定義出來 HTTP 請求什么路徑，什么方法來實現(xiàn)它；如果他需要基于隊列去執(zhí)行，那我只需要定義用什么隊列來執(zhí)行。

這是一個通過隊列讀取 S3 的 ZIP 文件解壓縮成 PNG 并上傳 S3 的例子，源代碼可以點原文看

對于 AWS Lambda 來說，可以抽象為以下配置（這是一個基于 AWS Lambda 的一個框架的配置）。正是這種機制，可以真正的實現(xiàn)函數(shù)級別的共享。

3、初始化非常容易

如果要寫一個簡單的 API 服務，就寫一個函數(shù)就夠了，省去了以前去折騰框架，弄路由、搞一大堆配置，這還不夠簡單么。

4、FaaS 不確定的缺點：基礎和 PaaS 是一致的

如果真算缺點，就是和 PaaS 是類似的：FaaS 對資源的掌控是不夠的。但是，PaaS 的缺點導致掌控性是一個較大的問題；而 FaaS 本身函數(shù)運行是比較獨立的，所有的成本都涵蓋在一個函數(shù)內(nèi)，復雜性就大大降低。

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

相關資源

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

如果覺得平臺本身復雜性略高，可以通過以下幾個框架去玩：APEX、Serverless 等