FaaS是Function as a Service的縮寫，可以簡單理解為功能即服務(wù)。與微服務(wù)相比，F(xiàn)aaS提供了一種更加服務(wù)化的軟件架構(gòu)范式，F(xiàn)aaS讓研發(fā)人員只關(guān)注業(yè)務(wù)代碼邏輯，而不關(guān)注技術(shù)架構(gòu)。

1、微服務(wù) 個人一直認為 FaaS 是微服務(wù)的終極演進結(jié)果。微服務(wù)一直沒有一個明確的標(biāo)準(zhǔn)是拆到多細算是微服務(wù)，F(xiàn)aaS 給了一個標(biāo)準(zhǔn)：冷啟動時間在毫秒量級，以及資源使用受系統(tǒng)上限約束。有人覺得全拆成 Function，是不是太細了？但實際上 Function 只是個抽象的概念，你也可以把整個應(yīng)用的請求全部指向一個 Function，然后在內(nèi)部做路由，只要能保證冷啟動時間。另外微服務(wù)本質(zhì)上還需要解決服務(wù)間的調(diào)用，追蹤，熔斷/重試等機制，這些在傳統(tǒng)的方案里，都是通過應(yīng)用內(nèi)嵌框架來解決的，而微服務(wù)領(lǐng)域最近很火的 Service Mesh 的解決思路是在網(wǎng)絡(luò)層處理，這樣就可以獨立交付，而 FaaS 可以說異曲同工，它直接從應(yīng)用中剝離了一層出來，然后具體是內(nèi)嵌框架還是通過 Service Mesh 實現(xiàn)，對用戶來說沒有區(qū)別。

2、視頻，圖片以及流式事件處理 本質(zhì)上是需要一種通用的，可自定義的，工作流應(yīng)用。當(dāng)前的工作流一般都是針對具體場景的，尚無支持自定義邏輯并且適用于各種類型事件的分布式工作流。而基于 FaaS 有可能誕生這樣一種工作流。另外類似于 Storm 這樣的流式大數(shù)據(jù)處理平臺，也可以理解成一種基于特定語言的 FaaS 平臺，F(xiàn)aaS 和流式數(shù)據(jù)處理平臺的整合大有前景。

3、事件驅(qū)動以及響應(yīng)式架構(gòu) 這個場景和前一個場景有相似之處，只不過前一個關(guān)注的是應(yīng)用場景，這條單指技術(shù)架構(gòu)場景。服務(wù)器端的事件驅(qū)動和響應(yīng)式架構(gòu)和客戶端技術(shù)相比，一直缺少一種統(tǒng)一的體系解決方案，主要原因是服務(wù)器端缺少分布式系統(tǒng)級別的支持，純開發(fā)框架的方式實現(xiàn)比較困難，如果調(diào)度系統(tǒng)和開發(fā)框架配合，實現(xiàn)這種架構(gòu)就比較容易了。

4、IoT 物聯(lián)網(wǎng)場景實際上和前面的流式事件處理以及事件驅(qū)動架構(gòu)都有關(guān)系。這里單獨作為一條闡述，主要是物聯(lián)網(wǎng)對應(yīng)用開發(fā)帶來的不僅僅是架構(gòu)上的變化?；ヂ?lián)網(wǎng)主要是信息技術(shù)，主要是面向人的應(yīng)用，要求及時把信息展示給用戶，所以應(yīng)用多是 http 的請求響應(yīng)模式，對延遲比較敏感（毫秒級）。而物聯(lián)網(wǎng)場景下，多是事件觸發(fā)，哪怕有人參與的場景，比如智能開關(guān)，也是觸發(fā)事件后控制另外的設(shè)備，對延遲忍耐度較高（秒級），協(xié)議多也不是 http，而是物聯(lián)網(wǎng)相關(guān)的消息協(xié)議。