FaaS，將來的後端服務開發之道

說 FaaS 先要說說 PaaS

平臺即服務（Platform as a Service）是一種雲計算服務，提供運算平臺與解決方案堆棧即服務。在雲計算的典型層級中，平臺即服務層介於軟件即服務與基礎設施即服務之間。 平臺即服務提供用戶能將雲基礎設施部署與建立至客戶端，或者藉此得到使用編程語言、程序庫與服務。用戶不須要管理與控制雲基礎設施，包含網絡、服務器、操做系統或存儲，但須要控制上層的應用程序部署與應用託管的環境。

引用自維基百科

簡單來講，PaaS 就是把計算能力放在線上，你只管寫代碼就好了，目的也是爲了減小後端維護的成本，讓開發者更關注到開發自己。國內有 Sina App Engine，國外有 Heroku、Google App Engine、Amazon Web Services，可是這類服務被真正用來作產品的並很少，大可能是看成開發的試驗田跑一下，並且跑起來的成本比獨立部署個服務器也差很少，你要理解不少服務的相關性，應用運行時還有提供各類服務的橋接，就形成你須要去理解一大堆東西才能把他們五花大綁到一塊兒，因此這類服務並無成爲真正的主流，更多的是仍是用原生的計算能力，好比 Amazone EC二、AWS 這類 IaaS 平臺，國內的阿里雲、UCloud 等。

PaaS 有很多缺點。

一、對計算能力不可掌控

PaaS 將本身的運行時封裝成了一個黑盒子，你要用他你就要基於這些黑盒子的約束和條件去自行判斷，須要瞭解每一個模塊或者函數的可用性和限制是什麼，才能更好的開發，爲了不應用有過高的權限形成安全問題，服務商每每的作法是裁剪，將限制的能力來提供給你，那麼若是你要開發一個應用，本地能用，部署了可能會有各類兼容問題。

一個完整的應用，在基於 PaaS 去開發的時候，勢必會有服務的依賴，對於這些服務的依賴，你也是沒有掌控能力的，你只能基於給出的環境變量是去配置，可是每每在複雜應用中，對於服務的依賴很是深刻，可能會有比較深刻的使用和調優，這個只能一籌莫展。

二、線上開發調試模型複雜

一個完整的應用就是一個功能集合，開發調試起來是很麻煩的，想象一下若是一個很龐大的網站，有一大堆的功能，你依賴可能十幾個甚至二十幾個服務，跑在你不太知道的黑盒子，你的調試該多麻煩。若是是你本身的環境，你能夠隨意的開啓 DEBUG 參數、去查看系統調用棧、去看硬件參數、去看系統優化參數、去分析運行時的細小問題、而在 PaaS 你能作的僅僅是經過服務商提供的一個後臺來作一些簡單的查看，日誌的分析。這個決定了 PaaS 不適合一個有規模的產品去使用。

FaaS - 函數即服務

FaaS 最終目的和 PaaS 相似，讓開發者關注在開發自己，服務由服務商提供。那 FaaS （Function as a Service）是什麼呢？我爲何以爲它是將來開發的一個趨勢。如今 FaaS 的說法還不太一致，可是能夠明確的是** FaaS 是 PaaS 能力的一種縮放，縮放到 Function 級別**。FaaS 能夠將函數做爲一個線上服務、遠程計算服務，能夠經過 API 執行、經過郵件執行、經過 Iot 執行，經過隊列執行。你只須要寫統一的函數就好了。FaaS 的入口是事件，下面是 AWS Lambda 的事件流圖。

 

 

我認爲 FaaS 有如下幾個特色：

一、函數粒度小易於調試

對於 FaaS 來講，你要寫的就是一個個函數，它就是一個功能。你要作的只是寫下以下這樣的函數，而後再用配置文件告訴服務器如何讓他運行，就完事了，你的全部工做都在這個函數內完成。而函數自己只須要負責處理輸入和輸出。（輸入和輸出是基於事件而不一樣的。）

 

 

在 FaaS 中函數的執行是無狀態的，函數運行時自己是封裝在一個容器內，執行完後全部的的狀態都會被銷燬（固然爲了優化，可能會緩存一段時間），可是最終不要指望經過有狀態的方式來運行函數，這是對於函數自己的限制。試想只須要定義好輸入，就能來調試函數了，測試來講會很是方便，而 PaaS 是一個複雜的合集，你的調試的方便性由你的寫法決定。

二、函數可配置性

每一個函數都是一個功能，這個功能如何執行，依賴是什麼，是能夠經過配置文件來完的成，若是一個函數可配置如何執行，那麼就可讓他達到共享的目的。試想一下，你寫了一個視頻處理的功能，傳入的是一個視頻地址或者URL，傳出的是一個 GIF，那麼這個函數你只須要先寫好功能，而後用配置文件定義如何運行，若是這是個 API 服務，那麼定義出來 HTTP 請求什麼路徑，什麼方法來實現它；若是他須要基於隊列去執行，那我只須要定義用什麼隊列來執行。

 

 

這是一個經過隊列讀取 S3 的 ZIP 文件解壓縮成 PNG 並上傳 S3 的例子，源代碼能夠點原文看

對於 AWS Lambda 來講，能夠抽象爲如下配置（這是一個基於 AWS Lambda 的一個框架的配置）。正是這種機制，能夠真正的實現函數級別的共享。

 

 

三、初始化很是容易

若是要寫一個簡單的 API 服務，就寫一個函數就夠了，省去了之前去折騰框架，弄路由、搞一大堆配置，這還不夠簡單麼。

四、FaaS 不肯定的缺點：基礎和 PaaS 是一致的

若是真算缺點，就是和 PaaS 是相似的：FaaS 對資源的掌控是不夠的。可是，PaaS 的缺點致使掌控性是一個較大的問題；而 FaaS 自己函數運行是比較獨立的，全部的成本都涵蓋在一個函數內，複雜性就大大下降。

還有一個缺點，若是開發一個複雜的應用，函數之間的調用和管理是一個棘手的問題，如今已經有框架在着手解決這些問題，能夠看下面相關資源的推薦。

相關資源

如今已經有很多知名服務商提供此類服務，你們的實現各不相同，可是思路是一致的。好比最著名的 AWS Lambda、Azure Functions、Google Cloud Functions、IBM OpenWhisk。

若是以爲平臺自己複雜性略高，能夠經過如下幾個框架去玩：APEX、Serverless 等