就像很多軟件發展趨勢一樣,業界并沒有對“無服務器”有一個明確的說法,即使它真的表示以下兩個不同而又重疊的領域也不會對此有所幫助:
無服務器先用來描述那些顯著或完全依賴于第三方應用或服務(“在云端”)的應用程序。這些應用程序依賴于第三方來管理服務器端邏輯和狀態,它們都是典型“富客戶端”的應用程序(你可以想象為單一頁面的Web應用程序或移動應用),并采用云平臺提供的生態系統,包括可訪問的數據庫(如Parse、Firebase)、認證服務(Auth0、AWS Cognito)等。這些類型的服務以前被描述為“(移動)后端即服務”。我在文中會用“BaaS”縮寫來代替這樣的服務。 無服務器還表示那些有服務器端邏輯的應用仍然需要由開發者來編寫。不同于傳統的架構,它運行在無狀態計算的容器中,這些容器由事件觸發的、是短暫的(也許僅僅只是一次調用)、并且完全由第三方管理。(感謝ThoughtWorks在他們最近的技術雷達的定義。)理解這個觀點的另一種方式是“函數即服務(FaaS)”,其中AWS Lambda是目前最流行的FaaS實現之一。Mike主要分析了第二個領域,并用FaaS作為文中“無服務器”的代言詞。他認為第二個領域相對較新,并且它和我們平常如何考慮技術架構的方式有顯著的區別,也推動了無服務概念周邊很多的炒作。他也提到了其實這些概念是相互關聯的,并在不斷合并。文中他給出了UI驅動的應用和消息驅動的應用兩個例子解釋了無服務架構的設計以及不同。
通過解讀AWS Lamda產品描述,Mike在文中分享了他對于FaaS的幾個理解:
從根本上說,FaaS是關于無需管理自己的服務器系統或者服務器應用,就能夠運行后端代碼的。 FaaS不需要基于一個特定的框架或類庫進行編碼。 無服務器應用程序的運行部署與傳統系統非常不同 - 我們將代碼上傳到FaaS服務提供商,它會幫我們做所有其他事情。 水平擴展是完全自動的、彈性的,并且由服務提供商進行管理。 FaaS中的函數是由服務提供商定義的事件類型觸發的。 大多數服務提供商還允許函數被HTTP請求響應觸發,通常在某種API網關里。他同時也探討了FaaS在狀態、執行時長、啟動延時、API網關、工具和開源等方面的表現。他提到了FaaS在本地狀態的顯著約束,并可以這樣簡單來理解:
對于任何的函數調用,你所創建的進程或者主機狀態不會有一個對隨后的調用可用,這包含了你寫到內存和硬盤上的狀態。換句話說,從部署單元角度來看,FaaS的函數是無狀態的。這對應用架構產生了巨大的影響。
這通常意味著FaaS要么是純粹無狀態的,即提供輸入的純函數轉換;要么是利用數據庫、跨應用緩存(如Redis)或者網絡文件存儲(如S3)的方式來存儲跨請求的狀態或處理請求需要的進一步輸入。
而對于執行時間而言,
FaaS函數的每次調用是有時間限制的。當前AWS Lamda函數不允許超過5分鐘,超過就會被中斷。這意味著長任務并不適合FaaS,除非重新設計架構。
另外,FaaS函數的響應時長取決于很多的因素,也許會從10毫秒到2分鐘。Mike認為如果你編寫一個低延遲交易應用,那么不管你使用什么語言實現,可能都無法使用FaaS系統。
那么Paas是無服務器嗎?在文中Mike引用了Adrian Cockcroft的回答
如果您的PaaS能夠高效地在20分鐘內啟動運行半秒的實例,那么你可以稱它為無服務器。
Mike認為:
絕大多數PaaS應用并不是著眼于將整個應用的每個請求都來回切換,而FaaS平臺做的正是這一點。FaaS和PaaS之間的主要操作差異在于擴展。對于大多數的PaaS來說,你仍然需要考慮規模,例如在Heroku你想運行多少Dynos。而如果是FaaS的應用,這完全是透明的。即使你將你的PaaS應用程序設置為自動擴展,你也不會對單個請求進行同樣的配置(除非你有一個非常特殊的流量描述文件),所以當涉及到成本的時候,FaaS應用會更高效。
同時他也指出這并不意味著沒有運維。這里要考慮兩個重要的事情:
首先,“運維”不僅僅意味著服務器管理。它也意味著監控、部署、安全、網絡,也意味著一定的產品問題診斷和系統規模擴展。這些問題在無服務器應用中仍然存在,你依舊需要應對的策略。 其次,即使仍然發生系統管理的工作,你也僅僅是將它們外包給無服務器平臺而已。最后Mike對存儲過程即服務的另一話題也進行了探討,他認為:
這可能來自于一個事實,即FaaS函數的許多例子(包括一些我在本文中使用的)都是少量訪問數據庫的代碼。如果這就是我們可以使用FaaS的所有場景,那么我認為這個名字是有幫助的。然而它實際上只是FaaS能力的一個子集。如果僅僅因為這個原因就形成這樣觀點的話,那這限制是不合理的。
同時他也提到了值得去考慮FaaS是否也有存儲過程的一些問題,包括Camille在tweet中提到的技術債,也值得在FaaS的上下文去探討一下存儲過程中已經得到的經驗教訓,并是否適用FaaS。