摘要：原文作者無服務(wù)器架構(gòu)是指一個(gè)應(yīng)用大量依賴第三方服務(wù)后端即服務(wù)，，簡稱，或者把代碼交由托管的短生命周期的容器中執(zhí)行函數(shù)即服務(wù)，，簡稱。這些服務(wù)最早被稱為，下文將對此簡稱為。是目前的熱門實(shí)現(xiàn)之一，下文將對此簡稱為。它同樣經(jīng)由網(wǎng)關(guān)暴露給外部使用。

譯注：

為了便于對照參考，“Serverless”、“BaaS” 等術(shù)語文中不做翻譯。
原文很長，這里分成上下兩篇。翻譯過程在 GitHub 上進(jìn)行。

原文：https://martinfowler.com/articles/serverless.html
作者：Mike Roberts

無服務(wù)器架構(gòu)（Serverless architectures）是指一個(gè)應(yīng)用大量依賴第三方服務(wù)（后端即服務(wù)，Backend as a Service，簡稱“BaaS”），或者把代碼交由托管的、短生命周期的容器中執(zhí)行（函數(shù)即服務(wù)，F(xiàn)unction as a Service，簡稱“FaaS”）?，F(xiàn)在最知名的 FaaS 平臺(tái)是 AWS Lambda。把這些技術(shù)和單頁應(yīng)用等相關(guān)概念相結(jié)合，這樣的架構(gòu)無需維護(hù)傳統(tǒng)應(yīng)用中永遠(yuǎn)保持在線的系統(tǒng)組件。Serverless 架構(gòu)的長處是顯著減少運(yùn)維成本、復(fù)雜度、以及項(xiàng)目起步時(shí)間，劣勢則在于更加依賴平臺(tái)供應(yīng)商和現(xiàn)階段仍有待成熟的支持環(huán)境。

無服務(wù)器計(jì)算（Severless computing，簡稱 Serverless）現(xiàn)在是軟件架構(gòu)圈中的熱門話題，三大云計(jì)算供應(yīng)商（Amazon、Google 和 Microsoft）都在大力投入這個(gè)領(lǐng)域，涌現(xiàn)了不計(jì)其數(shù)的相關(guān)書籍、開源框架、商業(yè)產(chǎn)品、技術(shù)大會(huì)。到底什么是 Serverless？它有什么長處/短處？我希望通過本文對這些問題提供一些啟發(fā)。

開篇我們先來看看 Serverless 是什么，之后我會(huì)盡我所能中立地談?wù)勊膬?yōu)勢和缺點(diǎn)。

就像軟件行業(yè)中的很多趨勢一樣，Serverless 的界限并不是特別清晰，尤其是它還涵蓋了兩個(gè)互相有重疊的概念：

Serverless 最早用于描述那些大部分或者完全依賴于第三方（云端）應(yīng)用或服務(wù)來管理服務(wù)器端邏輯和狀態(tài)的應(yīng)用，這些應(yīng)用通常是富客戶端應(yīng)用（單頁應(yīng)用或者移動(dòng)端 App），建立在云服務(wù)生態(tài)之上，包括數(shù)據(jù)庫（Parse、Firebase）、賬號(hào)系統(tǒng)（Auth0、AWS Cognito）等。這些服務(wù)最早被稱為 “(Mobile) Backend as a Service”，下文將對此簡稱為 “BaaS”。

Serverless 還可以指這種情況：應(yīng)用的一部分服務(wù)端邏輯依然由開發(fā)者完成，但是和傳統(tǒng)架構(gòu)不同，它運(yùn)行在一個(gè)無狀態(tài)的計(jì)算容器中，由事件驅(qū)動(dòng)、生命周期很短（甚至只有一次調(diào)用）、完全由第三方管理（感謝 ThoughtWorks 在他們最近的“技術(shù)觀察”中對此所做的定義）。這種情況稱為 Functions as a service / FaaS。AWS Lambda 是目前的熱門 FaaS 實(shí)現(xiàn)之一，下文將對此簡稱為 “FaaS”。

【邊欄注釋：“Serverless” 術(shù)語的起源】

本文將主要聚焦于 FaaS，不僅僅因?yàn)樗?Serverless 中最新也最熱門的領(lǐng)域，更重要的是它和我們傳統(tǒng)技術(shù)架構(gòu)思路的顯著不同。

BaaS 和 FaaS 在運(yùn)維層面有類似之處（都無需管理硬件資源），并且也經(jīng)常配合使用。主流的云服務(wù)商都會(huì)提供一套“Serverless 全家桶”，囊括了 BaaS 和 FaaS 產(chǎn)品——例如 Amazon 的 Serverless 產(chǎn)品介紹，Google 的 Firebase 服務(wù)也緊密集成了 Google Cloud Functions。

對小公司而言這兩個(gè)領(lǐng)域也有交叉，Auth0 最初是一個(gè) BaaS 產(chǎn)品，提供用戶管理的各種服務(wù)，他們后來創(chuàng)建了配套的 FaaS 服務(wù) Webtask，并且將此概念進(jìn)一步延伸推出了 Extend，支持其他 BaaS 和 SaaS 公司能夠輕松地在現(xiàn)有產(chǎn)品中加入 FaaS 能力。

我們來設(shè)想一個(gè)傳統(tǒng)的三層 C/S 架構(gòu)，例如一個(gè)常見的電子商務(wù)應(yīng)用（比如在線寵物商店），假設(shè)它服務(wù)端用 Java，客戶端用 HTML/JavaScript：

在這個(gè)架構(gòu)下客戶端通常沒什么功能，系統(tǒng)中的大部分邏輯——身份驗(yàn)證、頁面導(dǎo)航、搜索、交易——都在服務(wù)端實(shí)現(xiàn)。

把它改造成 Serverless 架構(gòu)的話會(huì)是這樣：

這是張大幅簡化的架構(gòu)圖，但還是有相當(dāng)多變化之處：

我們移除了最初應(yīng)用中的身份驗(yàn)證邏輯，換用一個(gè)第三方的 BaaS 服務(wù)。

另一個(gè) BaaS 示例：我們允許客戶端直接訪問一部分?jǐn)?shù)據(jù)庫內(nèi)容，這部分?jǐn)?shù)據(jù)完全由第三方托管（如 AWS Dynamo），這里我們會(huì)用一些安全配置來管理客戶端訪問相應(yīng)數(shù)據(jù)的權(quán)限。

前面兩點(diǎn)已經(jīng)隱含了非常重要的第三點(diǎn)：先前服務(wù)器端的部分邏輯已經(jīng)轉(zhuǎn)移到了客戶端，如保持用戶 Session、理解應(yīng)用的 UX 結(jié)構(gòu)（做頁面導(dǎo)航）、獲取數(shù)據(jù)并渲染出用戶界面等等。客戶端實(shí)際上已經(jīng)在逐步演變?yōu)閱雾搼?yīng)用。

還有一些任務(wù)需要保留在服務(wù)器上，比如繁重的計(jì)算任務(wù)或者需要訪問大量數(shù)據(jù)的操作。這里以“搜索”為例，搜索功能可以從持續(xù)運(yùn)行的服務(wù)端中拆分出來，以 FaaS 的方式實(shí)現(xiàn)，從 API 網(wǎng)關(guān)（后文做詳細(xì)解釋）接收請求返回響應(yīng)。這個(gè)服務(wù)器端函數(shù)可以和客戶端一樣，從同一個(gè)數(shù)據(jù)庫讀取產(chǎn)品數(shù)據(jù)。
我們原始的服務(wù)器端是用 Java 寫的，而 AWS Lambda（假定我們用的這家 FaaS 平臺(tái)）也支持 Java，那么原先的搜索代碼略作修改就能實(shí)現(xiàn)這個(gè)搜索函數(shù)。

最后我們還可以把“購買”功能改寫為另一個(gè) FaaS 函數(shù)，出于安全考慮它需要在服務(wù)器端，而非客戶端實(shí)現(xiàn)。它同樣經(jīng)由 API 網(wǎng)關(guān)暴露給外部使用。

再舉一個(gè)后端數(shù)據(jù)處理服務(wù)的例子。假設(shè)你在做一個(gè)需要快速響應(yīng) UI 的用戶中心應(yīng)用，同時(shí)你又想捕捉記錄所有的用戶行為。設(shè)想一個(gè)在線廣告系統(tǒng)，當(dāng)用戶點(diǎn)擊了廣告你需要立刻跳轉(zhuǎn)到廣告目標(biāo)，同時(shí)你還需要記錄這次點(diǎn)擊以便向廣告客戶收費(fèi)（這個(gè)例子并非虛構(gòu)，我的一位前同事最近就在做這項(xiàng)重構(gòu)）。

傳統(tǒng)的架構(gòu)會(huì)是這樣：“廣告服務(wù)器”同步響應(yīng)用戶的點(diǎn)擊，同時(shí)發(fā)送一條消息給“點(diǎn)擊處理應(yīng)用”，異步地更新數(shù)據(jù)庫（例如從客戶的賬戶里扣款）。

在 Serverless 架構(gòu)下會(huì)是這樣：

這里兩個(gè)架構(gòu)的差異比我們上一個(gè)例子要小很多。我們把一個(gè)長期保持在內(nèi)存中待命的任務(wù)替換為托管在第三方平臺(tái)上以事件驅(qū)動(dòng)的 FaaS 函數(shù)。注意這個(gè)第三方平臺(tái)提供了消息代理和 FaaS 執(zhí)行環(huán)境，這兩個(gè)緊密相關(guān)的系統(tǒng)。

我們已經(jīng)提到多次 FaaS 的概念，現(xiàn)在來挖掘下它究竟是什么含義。先來看看 Amazon 的 Lambda 產(chǎn)品簡介：

通過 AWS Lambda，無需配置或管理服務(wù)器(1)即可運(yùn)行代碼。您只需按消耗的計(jì)算時(shí)間付費(fèi) – 代碼未運(yùn)行時(shí)不產(chǎn)生費(fèi)用。借助 Lambda，您幾乎可以為任何類型的應(yīng)用程序或后端服務(wù)(2)運(yùn)行代碼，而且全部無需管理。只需上傳您的代碼，Lambda 會(huì)處理運(yùn)行(3)和擴(kuò)展高可用性(4)代碼所需的一切工作。您可以將您的代碼設(shè)置為自動(dòng)從其他 AWS 服務(wù)(5)觸發(fā)，或者直接從任何 Web 或移動(dòng)應(yīng)用程序(6)調(diào)用。

本質(zhì)上 FaaS 就是無需配置或管理你自己的服務(wù)器系統(tǒng)或者服務(wù)器應(yīng)用即可運(yùn)行后端代碼，其中第二項(xiàng)——服務(wù)器應(yīng)用——是個(gè)關(guān)鍵因素，使其區(qū)別于現(xiàn)今其他一些流行的架構(gòu)趨勢如容器或者 PaaS（Platform as a Service）。

回顧前面點(diǎn)擊處理的例子，F(xiàn)aaS 替換掉了點(diǎn)擊處理服務(wù)器（可能跑在一臺(tái)物理服務(wù)器或者容器中，但絕對是一個(gè)獨(dú)立的應(yīng)用程序），它不需要服務(wù)器，也沒有一個(gè)應(yīng)用程序在持續(xù)運(yùn)行。

FaaS 不需要代碼基于特定的庫或框架，從語言或環(huán)境的層面來看 FaaS 就是一個(gè)普通的應(yīng)用程序。例如 AWS Lambda 支持 JavaScript、Python 以及任意 JVM 語言（Java、Clojure、Scala 等），并且你的 FaaS 函數(shù)還可以調(diào)用任何一起部署的程序，也就是說實(shí)際上你可以用任何能編譯為 Unix 程序的語言（稍后我們會(huì)講到 Apex）。FaaS 也有一些不容忽視的局限，尤其是牽涉到狀態(tài)和執(zhí)行時(shí)長問題，這些我們稍后詳談。

再次回顧一下點(diǎn)擊處理的例子——代碼遷移到 FaaS 唯一需要修改的是 main 方法（啟動(dòng)）的部分，刪掉即可，也許還會(huì)有一些上層消息處理的代碼（實(shí)現(xiàn)消息監(jiān)聽界面），不過這很可能只是方法簽名上的小改動(dòng)。所有其他代碼（比如那些訪問數(shù)據(jù)庫的）都可以原樣用在 FaaS 中。

既然我們沒有服務(wù)器應(yīng)用要執(zhí)行，部署過程也和傳統(tǒng)的方式大相徑庭——把代碼上傳到 FaaS 平臺(tái)，平臺(tái)搞定所有其他事情。具體而言我們要做的就是上傳新版的代碼（zip 文件或者 jar 包）然后調(diào)用一個(gè) API 來激活更新。

橫向擴(kuò)展是完全自動(dòng)化、彈性十足、由 FaaS 平臺(tái)供應(yīng)商管理的。如果你需要并行處理 100 個(gè)請求，不用做任何處理系統(tǒng)可以自然而然地支持。FaaS 的“運(yùn)算容器”會(huì)在運(yùn)行時(shí)按需啟動(dòng)執(zhí)行函數(shù)，飛快地完成并結(jié)束。

回到我們的點(diǎn)擊處理應(yīng)用，假設(shè)某個(gè)好日子我們的客戶點(diǎn)擊廣告的數(shù)量有平日的十倍之多，我們的點(diǎn)擊處理應(yīng)用能承載得住么？我們寫的代碼是否支持并行處理？支持的話，一個(gè)運(yùn)行實(shí)例能夠處理這么多點(diǎn)擊量嗎？如果環(huán)境允許多進(jìn)程執(zhí)行我們能自動(dòng)支持或者手動(dòng)配置支持嗎？以 FaaS 實(shí)現(xiàn)你的代碼需要一開始就以并行執(zhí)行為默認(rèn)前提，但除此之外就沒有其他要求了，平臺(tái)會(huì)完成所有的伸縮性需求。

FaaS 中的函數(shù)通常都由平臺(tái)指定的一些事件觸發(fā)。在 AWS 上有 S3（文件）更新、時(shí)間（定時(shí)任務(wù)）、消息總線（Kinesis）消息等，你的函數(shù)需要指定監(jiān)聽某個(gè)事件源。在點(diǎn)擊處理器的例子中我們有個(gè)假設(shè)是已經(jīng)采用了支持 FaaS 訂閱的消息代理，如果沒有的話這部分也需要一些代碼量。

大部分的 FaaS 平臺(tái)都支持 HTTP 請求觸發(fā)函數(shù)執(zhí)行，通常都是以某種 API 網(wǎng)關(guān)的形式實(shí)現(xiàn)（如 AWS API Gateway，Webtask）。我們在寵物商店的例子中就以此來實(shí)現(xiàn)搜索和購買功能。

當(dāng)牽涉到本地（機(jī)器或者運(yùn)行實(shí)例）狀態(tài)時(shí) FaaS 有個(gè)不能忽視的限制。簡單點(diǎn)說就是你需要接受這么一個(gè)預(yù)設(shè)：函數(shù)調(diào)用中創(chuàng)建的所有中間狀態(tài)或環(huán)境狀態(tài)都不會(huì)影響之后的任何一次調(diào)用。這里的狀態(tài)包括了內(nèi)存數(shù)據(jù)和本地磁盤存儲(chǔ)數(shù)據(jù)。從部署的角度換句話說就是 FaaS 函數(shù)都是無狀態(tài)的（Stateless）。

這對于應(yīng)用架構(gòu)有重大的影響，無獨(dú)有偶，“Twelve-Factor App” 的概念也有一模一樣的要求。

在此限制下的做法有多種，通常這個(gè) FaaS 函數(shù)要么是天然無狀態(tài)的——純函數(shù)式地處理輸入并且輸出，要么使用數(shù)據(jù)庫、跨應(yīng)用緩存（如 Redis）或者網(wǎng)絡(luò)文件系統(tǒng)（如 S3）來保存需要進(jìn)一步處理的數(shù)據(jù)。

FaaS 函數(shù)可以執(zhí)行的時(shí)間通常都是受限的，目前 AWS Lambda 函數(shù)執(zhí)行最長不能超過五分鐘，否則會(huì)被強(qiáng)行終止。

這意味著某些需要長時(shí)間執(zhí)行的任務(wù)需要調(diào)整實(shí)現(xiàn)方法才能用于 FaaS 平臺(tái)，例如你可能需要把一個(gè)原先長時(shí)間執(zhí)行的任務(wù)拆分成多個(gè)協(xié)作的 FaaS 函數(shù)來執(zhí)行。

目前你的 FaaS 函數(shù)響應(yīng)請求的時(shí)間會(huì)受到大量因素的影響，可能從 10 毫秒到 2 分鐘不等。這聽起來很糟糕，不過我們來看看具體的情況，以 AWS Lambda 為例。

如果你的函數(shù)是 JavaScript 或者 Python 的，并且代碼量不是很大（千行以內(nèi)），執(zhí)行的消耗通常在 10 到 100 毫秒以內(nèi)，大函數(shù)可能偶爾會(huì)稍高一些。

如果你的函數(shù)實(shí)現(xiàn)在 JVM 上，會(huì)偶爾碰到 10 秒以上的 JVM 啟動(dòng)時(shí)間，不過這只會(huì)在兩種情況下發(fā)生：

你的函數(shù)調(diào)用觸發(fā)比較稀少，兩次調(diào)用間隔超過 10 分鐘。

流量突發(fā)峰值，比如通常每秒處理 10 個(gè)請求的任務(wù)在 10 秒內(nèi)飆升到每秒 100 個(gè)。

前一種情況可以用個(gè) hack 來解決：每五分鐘 ping 一次給函數(shù)保持熱身。

這些問題嚴(yán)重么？這要看你的應(yīng)用類型和流量特征。我先前的團(tuán)隊(duì)有一個(gè) Java 的異步消息處理 Lambda 應(yīng)用每天處理數(shù)億條消息，他們就完全不擔(dān)心啟動(dòng)延遲的問題。如果你要寫的是一個(gè)低延時(shí)的交易程序，目前而言肯定不會(huì)考慮 FaaS 架構(gòu)，無論你是用什么語言。

不論你是否認(rèn)為你的應(yīng)用會(huì)受此影響，都應(yīng)該以生產(chǎn)環(huán)境級(jí)別的負(fù)載測試下實(shí)際性能情況。如果目前的情況還不能接受的話，可以幾個(gè)月后再看看，因?yàn)檫@也是現(xiàn)在的 FaaS 平臺(tái)供應(yīng)商們主要集中精力在解決的問題。

我們前面還碰到過一個(gè) FaaS 的概念：“API 網(wǎng)關(guān)”。API 網(wǎng)關(guān)是一個(gè)配置了路由的 HTTP 服務(wù)器，每個(gè)路由對應(yīng)一個(gè) FaaS 函數(shù)，當(dāng) API 網(wǎng)關(guān)收到請求時(shí)它找到匹配請求的路由，調(diào)用相應(yīng)的 FaaS 函數(shù)。通常 API 網(wǎng)關(guān)還會(huì)把請求參數(shù)轉(zhuǎn)換成 FaaS 函數(shù)的調(diào)用參數(shù)。最后 API 網(wǎng)關(guān)把 FaaS 函數(shù)執(zhí)行的結(jié)果返回給請求來源。

AWS 有自己的一套 API 網(wǎng)關(guān)，其他平臺(tái)也大同小異。

除了純粹的路由請求，API 網(wǎng)關(guān)還會(huì)負(fù)責(zé)身份認(rèn)證、輸入?yún)?shù)校驗(yàn)、響應(yīng)代碼映射等，你可能已經(jīng)敏銳地意識(shí)到這是否合理，如果你有這個(gè)考慮的話，我們待會(huì)兒就談。

另一個(gè)應(yīng)用 API 網(wǎng)關(guān)加 FaaS 的場景是創(chuàng)建無服務(wù)器的 http 前端微服務(wù)，同時(shí)又具備了 FaaS 函數(shù)的伸縮性、管理便利等優(yōu)勢。

目前 API 網(wǎng)關(guān)的相關(guān)工具鏈還不成熟，盡管這是可行的但也要夠大膽才能用。

前面關(guān)于工具鏈還不成熟的說法是指大體上 FaaS 無服務(wù)器架構(gòu)平臺(tái)的情況，也有例外，Auth0 Webtask 就很重視改善開發(fā)者體驗(yàn)，Tomasz Janczuk 在最近一屆的 Serverless Conf 上做了精彩的展示。

無服務(wù)器應(yīng)用的監(jiān)控和調(diào)試還是有點(diǎn)棘手，我們會(huì)在本文未來的更新中進(jìn)一步探討這方面。

無服務(wù)器 FaaS 的一個(gè)主要好處就是只需要近乎透明的運(yùn)行時(shí)啟動(dòng)調(diào)度，所以這個(gè)領(lǐng)域不像 Docker 或者容器領(lǐng)域那么依賴開源實(shí)現(xiàn)。未來肯定會(huì)有一些流行的 FaaS / API 網(wǎng)關(guān)平臺(tái)實(shí)現(xiàn)可以跑在私有服務(wù)器或者開發(fā)者工作站上，IBM 的 OpenWhisk 就是一個(gè)這樣的實(shí)現(xiàn)，不知道它是否能成為流行選擇，接下來的時(shí)間里肯定會(huì)有更多競爭者出現(xiàn)。

除了運(yùn)行時(shí)的平臺(tái)實(shí)現(xiàn)，還是有不少開源工具用以輔助開發(fā)和部署的，例如 Serverless Framework 在 API 網(wǎng)關(guān) + Lambda 的易用性上就比它的原創(chuàng)者 AWS 要好很多，這是一個(gè) JS 為主的項(xiàng)目，如果你在寫一個(gè) JS 網(wǎng)關(guān)應(yīng)用一定要去了解下。

再如 Apex——“輕松創(chuàng)建、部署及管理 AWS Lambda 函數(shù)”。Apex 有意思的一點(diǎn)是它允許你用 AWS 平臺(tái)并不直接支持的語言來實(shí)現(xiàn) Lambda 函數(shù)，比如 Go。

在前文中我定義了 “Serverless” 是兩個(gè)概念的組合：“Backend as a Service” 和 “Function as a Service”，并且對后者的特性做了詳細(xì)解釋。

在我們開始探討它的好處和弊端之前，我想再花點(diǎn)兒時(shí)間在它的定義上，或者說：區(qū)分開那些容易和 Serverless 混淆的概念。我看到一些人（包括我自己最近）對此都有困惑，我想值得對此做個(gè)澄清。

既然 Serverless FaaS 這么像 12-Factor 應(yīng)用，那不就是另一種形式的 Platform as a Service 么？就像 Heroku？對此借用 Adrian Cockcroft 一句非常簡明的話：

如果你的 PaaS 能在 20ms 內(nèi)啟動(dòng)一個(gè)只運(yùn)行半秒鐘的實(shí)例，它就叫 Serverless。
— Adrian Cockcroft

換句話說，大部分 PaaS 應(yīng)用不會(huì)為了每個(gè)請求都啟動(dòng)并結(jié)束整個(gè)應(yīng)用，而 FaaS 就是這么做的。

好吧，然而假設(shè)我是個(gè)嫻熟的 12-Factor 應(yīng)用開發(fā)者，寫代碼的方式還是沒有區(qū)別對么？沒錯(cuò)，但是你如何運(yùn)維是有很大不同的。鑒于我們都是 DevOps 工程師我們會(huì)在開發(fā)階段就充分考慮運(yùn)維，對吧？

FaaS 和 PaaS 在運(yùn)維方面的關(guān)鍵區(qū)別是伸縮性（Scaling）。對于大多數(shù) PaaS 平臺(tái)而言你需要考慮如何伸縮，例如在 Heroku 上你要用到多少 Dyno 實(shí)例？對于 FaaS 應(yīng)用這一步驟是完全透明的。即便你將 PaaS 配置為自動(dòng)伸縮，也無法精細(xì)到單個(gè)請求級(jí)別，除非你有一個(gè)非常明確穩(wěn)定的流量曲線可以針對性地配置。所以 FaaS 應(yīng)用在成本方面要高效得多。

既然如此，何必還用 PaaS？有很多原因，最主要的因素應(yīng)該是工具鏈成熟度。另外像Cloud Foundry 能夠給混合云和私有云的開發(fā)提供一致體驗(yàn)，在寫就本文的時(shí)候 FaaS 還沒有這么成熟的平臺(tái)。

使用 Serverless FaaS 的好處之一是避免在操作系統(tǒng)層面管理應(yīng)用程序進(jìn)程。有一些 PaaS 平臺(tái)如 Heroku 也提供了這樣的特性；另一種對進(jìn)程的抽象是容器，這類技術(shù)的代表是 Docker。容器托管系統(tǒng)（Mesos、Kubernetes 等）把應(yīng)用從系統(tǒng)級(jí)開發(fā)中抽象出來，這種做法日漸流行，甚至在此之上云服務(wù)商的容器平臺(tái)（如 Amazon ECS、EKS、Google Cloud Engine）也像 Serverless FaaS 一樣允許團(tuán)隊(duì)從管理主機(jī)中完全解放出來。在這股容器大潮中，F(xiàn)aaS 是否還有優(yōu)勢？

概念上來說前面對 PaaS 的論斷仍舊適用于容器。Serverless FaaS 的伸縮性是完全自動(dòng)化、透明、良好組織的，并且自動(dòng)進(jìn)行資源監(jiān)控和分配；而容器平臺(tái)仍舊需要你對容量和集群進(jìn)行管理。

另外我還得說容器技術(shù)也處在不夠成熟和穩(wěn)定的階段，盡管它越來越接近了。當(dāng)然這不是說 Serverless 就成熟了，但你終究需要在兩個(gè)都屬前沿的技術(shù)方向中做出選擇。

還有個(gè)值得一提的是不少容器平臺(tái)支持了自動(dòng)伸縮的容器集群，Kubernetes 有內(nèi)建的 Horizontal Pod Autoscaling 功能，AWS Fargate 則承諾會(huì)有“Serverless 容器”。

總的來說 Serverless FaaS 和托管容器在管理和伸縮性方面的差別已經(jīng)不大，在它們之間的取舍更多看風(fēng)格取向和應(yīng)用的類型。例如事件驅(qū)動(dòng)的應(yīng)用組件更適合用 FaaS 實(shí)現(xiàn)，而同步請求驅(qū)動(dòng)的應(yīng)用組件更適合用容器實(shí)現(xiàn)。我預(yù)計(jì)很快就會(huì)有不少團(tuán)隊(duì)和應(yīng)用同時(shí)采用這兩種架構(gòu)模式，期待看它們會(huì)擦出怎樣的火花。

Serverless 并非“零運(yùn)維”——盡管它可能是“無系統(tǒng)管理員”，也要看你在這個(gè) Serverless 的兔子洞里走多深。

“運(yùn)維”的意義遠(yuǎn)不止系統(tǒng)管理，它還包括并不限于監(jiān)控、部署、安全、網(wǎng)絡(luò)、支持、生產(chǎn)環(huán)境調(diào)試以及系統(tǒng)伸縮。這些事務(wù)同樣存在于 Serverless 應(yīng)用中，你仍舊需要相應(yīng)的方法處理它們。某些情況下 Serverless 的運(yùn)維會(huì)更難一些，畢竟它還是個(gè)嶄新的技術(shù)。

系統(tǒng)管理的工作仍然要做，你只是把它外包給了 Serverless 環(huán)境。這既不能說壞也不能說好——我們外包了大量的內(nèi)容，是好是壞要看具體情況。不論怎樣，某些時(shí)候這層抽象也會(huì)發(fā)生問題，就會(huì)需要一個(gè)來自某個(gè)地方的人類系統(tǒng)管理員來支持你的工作了。

Charity Majors 在第一屆 Serverless 大會(huì)上就這個(gè)主題做了個(gè)非常不錯(cuò)的演講，也可以看看她相關(guān)的兩篇文章：WTF is operations? 和 Operational Best Practices）。

還有一種說法把 Serverless FaaS 看做“存儲(chǔ)過程即服務(wù)（Stored Procedures as a Service）”，我想原因是很多 FaaS 函數(shù)示范都用數(shù)據(jù)庫訪問作為例子。如果這就是它的主要用途，我想這個(gè)名字也不壞，但終究這只是 FaaS 的一種用例而已，這樣去考慮 FaaS 局限了它的能力。

我好奇 Serverless 會(huì)不會(huì)最終變成類似存儲(chǔ)過程那樣的東西，開始是個(gè)好主意，然后迅速演變成大規(guī)模技術(shù)債務(wù)。
— Camille Fournier

但我們?nèi)匀恢档每紤] FaaS 是否會(huì)導(dǎo)致跟存儲(chǔ)過程類似的問題，包括 Camille 提到的技術(shù)債。有很多存儲(chǔ)過程給我們的教訓(xùn)可以放在 FaaS 場景下重新審視，存儲(chǔ)過程的問題在于：

通常依賴于服務(wù)商指定的語言，或者至少是指定的語言框架/擴(kuò)展

因?yàn)楸仨氃跀?shù)據(jù)庫環(huán)境中執(zhí)行所以很難測試

難以進(jìn)行版本控制，或者作為應(yīng)用包進(jìn)行管理

盡管不是所有存儲(chǔ)過程的實(shí)現(xiàn)都有這些問題，但它們都是常會(huì)碰到的。我們看看是否適用于 FaaS：

第一條就目前看來顯然不是 FaaS 的煩惱，直接排除。

第二條，因?yàn)?FaaS 函數(shù)都是純粹的代碼，所以應(yīng)該和其他任何代碼一樣容易測試。整合測試是另一個(gè)問題，我們稍后展開細(xì)說。

第三條，既然 FaaS 函數(shù)都是純粹的代碼，版本控制自然不成問題；最近大家開始關(guān)心的應(yīng)用打包，相關(guān)工具鏈也在日趨成熟，比如 Amazon 的 Serverless Application Model（SAM）和前面提到的其他 Serverless 框架都提供了類似的功能。2018 年初 Amazon 還開放了 Serverless Application Repository（SAR）服務(wù)，方便組織分發(fā)應(yīng)用程序和組件，也是基于 AWS Serverless 服務(wù)構(gòu)建的。關(guān)于 SAR 可以看看我的另一篇文章：Examining the AWS Serverless Application Repository。

本文翻譯的實(shí)時(shí)更新：https://amio.github.io/server...