FaaS服務的特點和優(yōu)勢

相對于傳統(tǒng)的服務器應用程序，基于FaaS的應用程序通常在模塊功能上的設計相對單一，不同的功能往往分割到不同的云函數(shù)中處理，模塊內聚程度相對較高。不同功能模塊之間通過觸發(fā)器來相互觸發(fā)調用，功能模塊之間的耦合度非常低。一個個高內聚低耦合的云函數(shù)非常有利于團隊合作開發(fā)，也非常有利于后期的功能維護和缺陷定位。

每個云函數(shù)運行后通常都不能保留自己的運行狀態(tài)和內存數(shù)據(jù)(靜態(tài)變量有一些情況下會在同一個實例的不同調用周期間共享)，因此每個實例啟動的時候面對的是一個一致的干凈的初始狀態(tài)，不需要考慮歷史狀態(tài)的處理和維護。

由于云函數(shù)運行的容器由云服務提供商維護，因此FaaS的開發(fā)者一般不需要面對服務器運維、擴縮容等繁雜的事務(即使在訪問壓力超過了默認上限的情況下，往往也只需要提交工單申請?zhí)嵘舷蘧涂梢詫崿F(xiàn)擴容)，而且服務的安全性和穩(wěn)定性相比自己維護服務器要高得多。

FaaS的一個劣勢是冷啟動帶來的延遲問題。如果一個觸發(fā)事件到來的時候，服務容器中沒有可以立刻響應的實例，容器就需要啟動新的代碼實例來響應，根據(jù)服務商能力等不同，這個過程通常有毫秒級到秒級的延遲。各個云服務商都在通過優(yōu)化淘汰策略和規(guī)則等手段獨立降低冷啟動率，而對于延遲非常敏感的業(yè)務，用戶通常也可以用預熱請求的方式來確保代碼實例常駐在容器中，比如用定時器觸發(fā)代碼實例進行一個非常快的空響應。

FaaS的其他劣勢包括語言版本落后(云服務商通常只提供最流行的幾種開發(fā)語言的最穩(wěn)定的幾個運行環(huán)境)、依賴服務商提供的借口和周邊產(chǎn)品能力帶來的服務遷移困難等。

對于企業(yè)用戶來說，F(xiàn)aaS相比傳統(tǒng)的服務器架構有更淺的技術棧深度和更緩的學習曲線，這有利于團隊提升效率，降低人力成本。而FaaS架構的一個劣勢是難以進行傳統(tǒng)的狀態(tài)管理。因為FaaS架構的高度可擴展性意味著每個應用都隨時會被創(chuàng)建出來新的實例或者銷毀掉存在的實例，而實例不能長久地占有內存空間，因此要提供有狀態(tài)的服務就必須要和獨立的存儲服務進行交互，這往往會增加服務延遲，導致占有了CPU和內存等資源卻難以高效地利用。

因此Serverless應用一般不通過會話(Session)認證用戶身份，而是采用Json Web Token(JWT)之類的無狀態(tài)身份驗證機制來代替Session身份驗證。