faas的應用場景

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

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

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

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