【51CTO.com快譯】 無服務器架構是指高度依賴于第三方服務（即后端即服務，簡稱BaaS）或者運行在臨時容器（即功能即服務，簡稱FaaS）內之定制化代碼的應用程序，目前最為知名的相關服務為AWSLambda。

盡管名為"無服務器"，但此類架構并非將代碼徹底剝離于服務器之外。"無服務器計算"是指企業或個人無需購買、租賃或配置用于支持后端代碼運行的物理或者虛擬服務器。
 

無服務器解決方案通常包含Web服務器、FaaS層、安全令牌服務（簡稱STS）、用戶驗證以及數據庫等組成要素。

無服務器代碼可與面向常規服務器形式的代碼--例如微服務--并發運行。舉例來說，我們可將一款Web應用中的部分代碼以微服務形式編寫，而另一部分則可表現為無服務器形式。此外，在編寫當中完全不涉及任何服務器配置要素的應用程序亦可實現無服務器化。

FaaS提供的平臺允許開發者根據具體事件觸發代碼執行操作，而無需構建并維護復雜的基礎設施。在這一體系當中，由第三方應用或服務對服務器端邏輯及狀態進行管理。

無服務器計算的弊端

1.第三方API系統的問題

供應商控制、多租戶問題、供應商鎖定以及安全缺陷等負面影響皆可能由第三方API所引發。在不具備系統控制能力的前提下使用API有可能導致系統宕機、強迫性API升級、功能缺失、發生意外限制以及成本變更等后果。另外，多租戶問題亦常見于各類云計算框架之內。Salesforce（PaaS）即因其多租戶云結構而引入了部分監管限制，開發人員亦需要在使用當中盡可能避免相關問題。具體而言，多租戶解決方案往往會在安全性、穩定性以及性能層面發生問題。

2.運維工具缺失

開發人員需要依靠供應商為其提供調試與監控類工具。事實上，分布式系統的調試工作相當困難，且通常需要對大量相關指標進行訪問方可了解問題的產生根源。

3.架構復雜性

開發人員需要投入大量時間以評估、實施并測試具體功能應當拆分成怎樣的粒度。應用程序一次調用操作中所涉及的功能數量需要加以平衡。對大量功能進行管理無疑將提升運營成本，而忽略粒度設置則終將令微服務架構變為"迷你整體"架構。

目前，AWSLambda對用戶所能并發執行的總體lambda數量作出了限制。其中的問題在于，該限制將影響您的整體AWS帳戶。部分企業會利用同一AWS帳戶進行生產及測試。這意味著如果某位工作人員著手進行一項新的負載測試并嘗試執行1000項并發Lambda功能，則生產應用將立即遭遇拒絕服務（簡稱DoS）狀況。

4.實施難度過高

對無服務器應用進行集成化測試難度極高。無服務器FaaS（即每項功能）中的各集成單元要遠小于其它架構，因此我們需要將大量單元加以集成，方能正常完成測試。另外，大家可能需要在整體邏輯應用之內為每項功能部署一項對應的FaaS組件。這意味著您將無法以原子性方式對一組功能進行統一部署，而由于不存在應用程序版本管理概念，因此原子回滾亦無法實現。如此一來，我們需要關閉一切觸發相應功能的事件源、部署整體功能組，而后再重新啟動事件源。

原文鏈接：
https://dzone.com/articles/the-drawbacks-of-serverless-architecture
原文標題：The Drawbacks of Serverless Architecture
原文作者：Rohit Akiwatkar

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】