戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！

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

一些示例

界面驅(qū)動(dòng)的應(yīng)用（UI-driven applications）

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

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

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

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

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

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

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

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

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

消息驅(qū)動(dòng)的應(yīng)用（Message-driven applications）

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

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

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

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

解構(gòu) “Function as a Service”

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

通過(guò) AWS Lambda，無(wú)需配置或管理服務(wù)器(1)即可運(yùn)行代碼。您只需按消耗的計(jì)算時(shí)間付費(fèi) – 代碼未運(yùn)行時(shí)不產(chǎn)生費(fèi)用。借助 Lambda，您幾乎可以為任何類(lèi)型的應(yīng)用程序或后端服務(wù)(2)運(yùn)行代碼，而且全部無(wú)需管理。只需上傳您的代碼，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ú)需配置或管理你自己的服務(wù)器系統(tǒng)或者服務(wù)器應(yīng)用即可運(yùn)行后端代碼，其中第二項(xiàng)——服務(wù)器應(yīng)用——是個(gè)關(guān)鍵因素，使其區(qū)別于現(xiàn)今其他一些流行的架構(gòu)趨勢(shì)如容器或者 PaaS（Platform as a Service）。回顧前面點(diǎn)擊處理的例子，FaaS 替換掉了點(diǎn)擊處理服務(wù)器（可能跑在一臺(tái)物理服務(wù)器或者容器中，但絕對(duì)是一個(gè)獨(dú)立的應(yīng)用程序），它不需要服務(wù)器，也沒(méi)有一個(gè)應(yīng)用程序在持續(xù)運(yùn)行。

FaaS 不需要代碼基于特定的庫(kù)或框架，從語(yǔ)言或環(huán)境的層面來(lái)看 FaaS 就是一個(gè)普通的應(yīng)用程序。例如 AWS Lambda 支持 JavaScript、Python 以及任意 JVM 語(yǔ)言（Java、Clojure、Scala 等），并且你的 FaaS 函數(shù)還可以調(diào)用任何一起部署的程序，也就是說(shuō)實(shí)際上你可以用任何能編譯為 Unix 程序的語(yǔ)言（稍后我們會(huì)講到 Apex）。FaaS 也有一些不容忽視的局限，尤其是牽涉到狀態(tài)和執(zhí)行時(shí)長(zhǎng)問(wèn)題，這些我們稍后詳談。 再次回顧一下點(diǎn)擊處理的例子——代碼遷移到 FaaS 唯一需要修改的是 main 方法（啟動(dòng)）的部分，刪掉即可，也許還會(huì)有一些上層消息處理的代碼（實(shí)現(xiàn)消息監(jiān)聽(tīng)界面），不過(guò)這很可能只是方法簽名上的小改動(dòng)。所有其他代碼（比如那些訪問(wèn)數(shù)據(jù)庫(kù)的）都可以原樣用在 FaaS 中。

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

橫向擴(kuò)展是完全自動(dòng)化、彈性十足、由 FaaS 平臺(tái)供應(yīng)商管理的。如果你需要并行處理 100 個(gè)請(qǐng)求，不用做任何處理系統(tǒng)可以自然而然地支持。FaaS 的“運(yùn)算容器”會(huì)在運(yùn)行時(shí)按需啟動(dòng)執(zhí)行函數(shù)，飛快地完成并結(jié)束。 回到我們的點(diǎn)擊處理應(yīng)用，假設(shè)某個(gè)好日子我們的客戶(hù)點(diǎn)擊廣告的數(shù)量有平日的十倍之多，我們的點(diǎn)擊處理應(yīng)用能承載得住么？我們寫(xiě)的代碼是否支持并行處理？支持的話，一個(gè)運(yùn)行實(shí)例能夠處理這么多點(diǎn)擊量嗎？如果環(huán)境允許多進(jìn)程執(zhí)行我們能自動(dòng)支持或者手動(dòng)配置支持嗎？以 FaaS 實(shí)現(xiàn)你的代碼需要一開(kāi)始就以并行執(zhí)行為默認(rèn)前提，但除此之外就沒(méi)有其他要求了，平臺(tái)會(huì)完成所有的伸縮性需求。

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

大部分的 FaaS 平臺(tái)都支持 HTTP 請(qǐng)求觸發(fā)函數(shù)執(zhí)行，通常都是以某種 API 網(wǎng)關(guān)的形式實(shí)現(xiàn)（如 AWS API Gateway，Webtask）。我們?cè)趯櫸锷痰甑睦又芯鸵源藖?lái)實(shí)現(xiàn)搜索和購(gòu)買(mǎi)功能。

狀態(tài)

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

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

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

執(zhí)行時(shí)長(zhǎng)

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

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

啟動(dòng)延遲

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

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

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

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

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

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

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

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

API 網(wǎng)關(guān)

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

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

除了純粹的路由請(qǐng)求，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 的場(chǎng)景是創(chuàng)建無(wú)服務(wù)器的 http 前端微服務(wù)，同時(shí)又具備了 FaaS 函數(shù)的伸縮性、管理便利等優(yōu)勢(shì)。

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

工具鏈

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

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

開(kāi)源

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

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

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

什么不是 Serverless

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

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

對(duì)比 PaaS

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

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

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

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

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

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

對(duì)比 NoOps

Serverless 并非“零運(yùn)維”——盡管它可能是“無(wú)系統(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)境。這既不能說(shuō)壞也不能說(shuō)好——我們外包了大量的內(nèi)容，是好是壞要看具體情況。不論怎樣，某些時(shí)候這層抽象也會(huì)發(fā)生問(wèn)題，就會(huì)需要一個(gè)來(lái)自某個(gè)地方的人類(lèi)系統(tǒng)管理員來(lái)支持你的工作了。

對(duì)比存儲(chǔ)過(guò)程即服務(wù)

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

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

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

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

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

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

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

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

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

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

福利

掃描添加小編微信，備注“姓名+公司職位”，加入【云計(jì)算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！

推薦閱讀：

• 如何高效地準(zhǔn)備技術(shù)面試？

• 漫畫(huà)：有趣的“帽子問(wèn)題”

• 我為什么放棄了 Chrome？

• 5天破10億的哪吒，為啥這么火，Python來(lái)分析

• 通俗易懂：圖解10大CNN網(wǎng)絡(luò)架構(gòu)

• 互聯(lián)網(wǎng)公司上演反腐風(fēng)暴；GitHub CEO 對(duì)斷供表示無(wú)能為力；程序員面試錦集| 開(kāi)發(fā)者周刊

• 在其他國(guó)家被揭穿騙子又盯上非洲? 這幾個(gè)騙子公司可把非洲人民坑苦了……

真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的被吹得天花乱坠的无服务器架构，究竟是什么？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。