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

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

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

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

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