這篇文章摘錄自彼得·薩巴斯基（Peter Sbarski）和薩姆·克魯內(nèi)伯格（Sam Kroonenburg）合著的《AWS上的無服務(wù)器架構(gòu)》一書，概述了無服務(wù)器架構(gòu)的五大原則。

彼得·薩巴斯基和薩姆·克魯內(nèi)伯格合著的《走無服務(wù)器道路》（Go Serverless）一書。

如果你問軟件開發(fā)人員何謂軟件架構(gòu)，可能會得到五花八門的答案：軟件架構(gòu)“是藍(lán)圖或計劃”、“概念模型”或“大局”，不一而足。毫無疑問，架構(gòu)或缺少架構(gòu)關(guān)系到軟件的成敗。良好的架構(gòu)有助于擴(kuò)展Web或移動應(yīng)用程序，而糟糕的架構(gòu)可能導(dǎo)致嚴(yán)重問題，勢必需要重寫、花費(fèi)高昂成本。了解架構(gòu)方面的選擇帶來的影響，并且能夠提前規(guī)劃，這對于構(gòu)建高效、高性能、最終成功的軟件系統(tǒng)來說極為重要。

這篇文章闡述了為什么我們認(rèn)為，無服務(wù)器架構(gòu)對軟件開發(fā)人員和解決方案架構(gòu)師來說是改變行業(yè)規(guī)則的技術(shù)。它介紹了AWS Lambda之類的關(guān)鍵服務(wù)，還介紹了無服務(wù)器架構(gòu)的幾個原則，幫助你了解什么造就真正的無服務(wù)器系統(tǒng)。

名稱中有什么？

在我們開始探討正文之前，應(yīng)該提到無服務(wù)器這個詞有點(diǎn)用詞不當(dāng)。無論你使用AWS Lambda之類的計算服務(wù)來執(zhí)行代碼還是與API進(jìn)行交互，仍然有服務(wù)器在后臺運(yùn)行。區(qū)別在于，這些服務(wù)器隱藏起來，我們是看不見的。我們不需要考慮基礎(chǔ)設(shè)施，也無法調(diào)整/改動底層操作系統(tǒng)。別人負(fù)責(zé)基礎(chǔ)設(shè)施管理的基本細(xì)節(jié)，那樣我們可以騰出時間處理其他事情。無服務(wù)器技術(shù)是指，在計算服務(wù)中運(yùn)行代碼，并與服務(wù)和API進(jìn)行交互，以完成任務(wù)。

我們?nèi)绾巫叩浇裉爝@一步？

如果你看一看支持如今大多數(shù)具有Web功能的軟件的系統(tǒng)，就會發(fā)現(xiàn)后端服務(wù)器執(zhí)行各種各樣的計算任務(wù)，而客戶端前端為用戶提供界面，以便通過瀏覽器、移動設(shè)備或桌面設(shè)備進(jìn)行操作。

在一個典型的Web應(yīng)用程序中，服務(wù)器接受來自前端的HTTP請求，處理請求。數(shù)據(jù)在保存到數(shù)據(jù)庫之前可能經(jīng)過無數(shù)個應(yīng)用層次。最后，后端生成響應(yīng)――可能采用JSON或完全呈現(xiàn)的標(biāo)記這種形式，響應(yīng)被發(fā)回給客戶端（圖1）。當(dāng)然，一旦將其他元素考慮進(jìn)來，比如負(fù)載均衡、事務(wù)、集群、緩存、消息傳遞和數(shù)據(jù)冗余，大多數(shù)系統(tǒng)比較復(fù)雜。大多數(shù)這種軟件需要服務(wù)器在數(shù)據(jù)中心或在云端運(yùn)行，這些服務(wù)器需要加以管理、維護(hù)、打補(bǔ)丁和備份起來。

圖1：這是一種基本的請求/響應(yīng)（客戶端/服務(wù)器）消息交換模式，大多數(shù)開發(fā)人員對此很熟悉。該圖中只有一臺Web服務(wù)器和一個數(shù)據(jù)庫。大多數(shù)系統(tǒng)要復(fù)雜得多。

服務(wù)器的配置、管理和打補(bǔ)丁是一項很耗費(fèi)時間的任務(wù)，常常需要專門的操作人員。很難搭建并高效地運(yùn)行一個重大的環(huán)境。基礎(chǔ)設(shè)施和硬件是任何IT系統(tǒng)的必要組成部分，但它們也常常讓人容易分心，忽視最重要的事情：解決業(yè)務(wù)問題。

過去這幾年出現(xiàn)了平臺即服務(wù)（PaaS）和容器等技術(shù)，這些解決方案有望解決這個頭痛的問題：基礎(chǔ)設(shè)施環(huán)境不一致、沖突和服務(wù)器管理開銷。PaaS是一種云計算，它為用戶提供了運(yùn)行軟件的平臺，同時把一部分底層基礎(chǔ)設(shè)施隱藏起來。為了有效地使用PaaS，開發(fā)人員需要編寫針對該平臺相應(yīng)功能特性的軟件。由于大多數(shù)PaaS實現(xiàn)方法具有短暫性，把當(dāng)初被設(shè)計成在獨(dú)立服務(wù)器上運(yùn)行的老式應(yīng)用程序遷移到PaaS服務(wù)，需要額外的開發(fā)工作。不過，如果面臨選擇，許多開發(fā)人員會決定使用PaaS，而不是更傳統(tǒng)、更手動化的解決方案，那是由于PaaS減少了維護(hù)和平臺支持方面的要求，這可以理解。

容器化是一種隔離應(yīng)用程序的方法，讓應(yīng)用程序有自己的環(huán)境。這種輕量級方法可替代全面的虛擬化。容器是孤立的、輕量級的，但它們需要部署到服務(wù)器上，無論在公共云上、在私有云中還是在現(xiàn)場。如果依賴關(guān)系明確，容器是一種出色的解決方案，不過它們在內(nèi)務(wù)處理（housekeeping）方面有各自的挑戰(zhàn)和復(fù)雜性。它們并不是與僅僅能夠直接在云端運(yùn)行代碼來得一樣容易。

最后，我們迎來了Lambda，這是亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）提供的一種計算服務(wù)。Lambda能夠以一種大規(guī)模并行方式執(zhí)行代碼，以響應(yīng)事件。Lambda拿來你的代碼后即可運(yùn)行，根本不需要配置服務(wù)器、安裝軟件、部署容器，或者是為低層細(xì)節(jié)而操心。AWS負(fù)責(zé)配置和管理運(yùn)行實際代碼的彈性計算云（EC2）服務(wù)器，并提供開發(fā)人員不需要考慮的一套高可用性計算基礎(chǔ)設(shè)施，包括容量配置和自動擴(kuò)展機(jī)制。無服務(wù)器架構(gòu)這個詞是指這些新型的軟件架構(gòu)：不需要直接訪問服務(wù)器就能運(yùn)行。通過采用Lambda，并充分利用各種功能強(qiáng)大的單一用途的API和Web服務(wù)，開發(fā)人員就可以迅速構(gòu)建松散耦合、可擴(kuò)展、高效的架構(gòu)。無服務(wù)器架構(gòu)的最終目的就是，遠(yuǎn)離服務(wù)器和基礎(chǔ)設(shè)施方面的問題，讓開發(fā)人員可以主要專注于代碼。

面向服務(wù)的架構(gòu)和微服務(wù)

在許多不同的系統(tǒng)和應(yīng)用程序架構(gòu)當(dāng)中，面向服務(wù)的架構(gòu)（SOA）在軟件開發(fā)人員當(dāng)中具有很高的知名度。這種架構(gòu)清楚地使這個想法概念化：系統(tǒng)可以由許多獨(dú)立的服務(wù)組成。SOA方面的文章已寫了不少，可是由于開發(fā)人員常常把設(shè)計理念與具體的實施和屬性混為一談，所以它仍存在爭議和誤解。

SOA沒有硬性規(guī)定使用任何特定的技術(shù)。相反，它鼓勵這樣一種架構(gòu)方法：開發(fā)人員創(chuàng)建自治服務(wù)，這些服務(wù)通過消息傳遞來進(jìn)行聯(lián)系，常常有一種模式（schema）或契約（contract），定義了消息是如何創(chuàng)建或交換的。服務(wù)的可重用性、自主性、可組合性、細(xì)粒度和可發(fā)現(xiàn)性，這些都是與SOA有關(guān)的重要原則。

微服務(wù)和無服務(wù)器架構(gòu)在核心思想上與面向服務(wù)的架構(gòu)一脈相承。它們保留了許多上述原則和理念，同時試圖消除老式的面向服務(wù)架構(gòu)具有的復(fù)雜性。

最近出現(xiàn)的一股趨勢是，使用微服務(wù)架構(gòu)來實施系統(tǒng)。開發(fā)人員往往把微服務(wù)考慮成小型、單獨(dú)、完全獨(dú)立的服務(wù)，它們圍繞一個特定的業(yè)務(wù)用途或功能而建。微服務(wù)可能有一個應(yīng)用程序?qū)樱凶约旱腁PI和數(shù)據(jù)庫。

理想情況下，微服務(wù)應(yīng)該易于替換，每個服務(wù)用一種適當(dāng)?shù)目蚣芎驼Z言編寫而成。微服務(wù)可以用不同的通用語言或特定領(lǐng)域語言（DSL）來編寫，光這一點(diǎn)就讓許多開發(fā)人員為之著迷。雖然可以通過使用合適的語言或針對相應(yīng)任務(wù)的一套專用庫來獲得一些好處，但這也常常是個陷阱。如果擁有多種語言和框架，支持起來有難度；要是沒有一套嚴(yán)格的準(zhǔn)則，會在將來導(dǎo)致混淆和困難。

每個微服務(wù)可能保持其狀態(tài)、存儲數(shù)據(jù)，這增加了系統(tǒng)的復(fù)雜性。一致性和協(xié)調(diào)性管理也可能成為一個問題，因為狀態(tài)必須常常跨不同的服務(wù)來加以同步。微服務(wù)可以通過消息總線間接聯(lián)系，也可以通過將消息發(fā)給對方來直接聯(lián)系。

可以說，無服務(wù)器架構(gòu)同樣體現(xiàn)了來自微服務(wù)的許多原則。畢竟，每個計算函數(shù)都可以被認(rèn)為是其自己的獨(dú)立服務(wù)，這取決于你如何設(shè)計系統(tǒng)。然而，你不需要完全接受微服務(wù)口號，就可以圍繞某個特定的業(yè)務(wù)用途來開發(fā)每個函數(shù)或服務(wù)，保持狀態(tài)，等等。

無服務(wù)器架構(gòu)的好處在于，你想運(yùn)用幾個微服務(wù)原則，就可以隨意運(yùn)用幾個，不會迫使你只有華山一條道。

軟件設(shè)計

軟件設(shè)計已從昔日代碼在大型機(jī)上運(yùn)行，變成如今在多層系統(tǒng)上運(yùn)行：在許多設(shè)計中，表示層、數(shù)據(jù)層和應(yīng)用/邏輯層具有重要地位。在每層里面，可能有多個邏輯層次處理某一功能或領(lǐng)域的特定方面。還有可能跨眾多層次的橫切組件（cross-cutting component），比如日志或異常處理系統(tǒng)。青睞分層可以理解。分層讓開發(fā)人員得以將關(guān)注點(diǎn)分離開來，開發(fā)出更易維護(hù)的應(yīng)用程序。

但是，反過來也可能如此。層次太多可能導(dǎo)致效率低下。一個小小的變化常常帶來連鎖反應(yīng)，導(dǎo)致開發(fā)人員修改整個系統(tǒng)中的每個層次，把大量的時間和精力花費(fèi)在實施和測試上。層次數(shù)量越多，久而久之系統(tǒng)會變得越復(fù)雜、越笨拙。圖2顯示了具有多個層次的分層架構(gòu)的一個例子。

圖2：一個典型的三層應(yīng)用程序通常由表示層、應(yīng)用層和數(shù)據(jù)層組成。在每個層中，可能有多個層次，它們有特定的職責(zé)。開發(fā)人員可以選擇各層次彼此如何聯(lián)系。這可以是嚴(yán)格的自上而下的方式，也可以是一種松散的方式：各層次可以繞過緊鄰的層次，與其他層次對話。層次的聯(lián)系方式將影響性能、依賴項管理和應(yīng)用程序的復(fù)雜性。然后還有橫跨多個層次的功能――這叫作橫切關(guān)注點(diǎn)（cross-cutting concern）。

無服務(wù)器架構(gòu)實際上有助于解決分層、非得更新太多對象這一問題。開發(fā)人員有機(jī)會消除或盡量減少層次，只要將系統(tǒng)分成多個功能，讓前端得以安全地與服務(wù)、甚至數(shù)據(jù)庫直接進(jìn)行通信，如圖3所示。這一切都可以以一種有組織的方式來實現(xiàn)，可以清楚地定義服務(wù)邊界，防止意大利面條式實施和依賴項惡夢，讓Lambda函數(shù)成為自治式，并且規(guī)劃函數(shù)和服務(wù)如何交互。

圖3：在無服務(wù)器架構(gòu)中，沒有單一的傳統(tǒng)后端。通過API網(wǎng)關(guān)，應(yīng)用程序的前端直接與服務(wù)、數(shù)據(jù)庫或計算函數(shù)進(jìn)行聯(lián)系。然而，有些服務(wù)必須隱藏在計算服務(wù)函數(shù)后面，額外的安全措施和驗證可能在這里進(jìn)行。

無服務(wù)器方法解決不了所有問題，也無法消除系統(tǒng)的底層復(fù)雜性。然而，如果實施得當(dāng)，它還是可以為減少、厘清和管理復(fù)雜性帶來機(jī)會。精心規(guī)劃的無服務(wù)器架構(gòu)可以讓開發(fā)人員更容易在將來做出變化，這對任何長期的應(yīng)用程序來說都是一個重要因素。下一節(jié)將更詳細(xì)地討論服務(wù)的組織和編排。

層vs層次

一些開發(fā)人員對于層次（layer）與層（tier）之間的區(qū)別分不太清楚。層是一種模塊邊界，它是為了隔離系統(tǒng)的主要組件而存在的。用戶看得見的表示層與包括業(yè)務(wù)邏輯的應(yīng)用層分開來。反過來，數(shù)據(jù)層是另一個獨(dú)立的系統(tǒng)，負(fù)責(zé)數(shù)據(jù)的管理、持久化和訪問。分組在一個層中的組件可能實際上駐留在不同的基礎(chǔ)設(shè)施上。

層次是邏輯片段，負(fù)責(zé)執(zhí)行應(yīng)用程序中特定的職責(zé)。每一層在里面可能有多個層次，負(fù)責(zé)功能的不同部分，比如域服務(wù)。

無服務(wù)器架構(gòu)的原則

無服務(wù)器架構(gòu)有五大原則，描述了一個理想的無服務(wù)器系統(tǒng)應(yīng)該如何構(gòu)建。你在構(gòu)建無服務(wù)器架構(gòu)時，可以運(yùn)用這些原則，幫助指導(dǎo)你做出決定。

1.根據(jù)需要，使用計算服務(wù)來執(zhí)行代碼（沒有服務(wù)器）。

2.編寫單一用途的無狀態(tài)函數(shù)。

3.設(shè)計基于推送的、事件驅(qū)動的管道。

4.創(chuàng)建更粗實、更強(qiáng)大的前端。

5.擁抱第三方服務(wù)。

不妨更詳細(xì)地分析這每一個原則。

根據(jù)需要，使用計算服務(wù)執(zhí)行代碼

無服務(wù)器架構(gòu)是SOA概念的自然延伸。在無服務(wù)器架構(gòu)中，所有自定義代碼作為孤立的、獨(dú)立的、常常細(xì)粒度的函數(shù)來編寫和執(zhí)行，這些函數(shù)在AWS Lambda之類的無狀態(tài)計算服務(wù)中運(yùn)行。開發(fā)人員可以編寫函數(shù)，執(zhí)行幾乎任何常見的任務(wù)，比如讀取和寫入到數(shù)據(jù)源、調(diào)用函數(shù)以及執(zhí)行計算。在比較復(fù)雜的情況下，開發(fā)人員可以構(gòu)建更復(fù)雜的管道，編排多個函數(shù)的調(diào)用。可能會有這種場景：仍需要服務(wù)器來處理某個任務(wù)。然而，這種情況并不多見；作為開發(fā)人員，你應(yīng)該盡量避免運(yùn)行服務(wù)器、與之交互。

那么，Lambda究竟是什么？

Lambda是一種計算服務(wù)，它在AWS基礎(chǔ)設(shè)施上執(zhí)行用用JavaScript（node.js）、Python或Java編寫的代碼。源代碼部署到孤立的容器上，該容器有單獨(dú)分配的內(nèi)存、磁盤空間和處理器。代碼、配置和依賴項這一組合通常被稱為Lambda函數(shù)。Lambda運(yùn)行時環(huán)境可以并行多次調(diào)用某個函數(shù)。Lambda支持推拉事件操作模式，并與數(shù)量眾多的AWS服務(wù)整合起來。函數(shù)可以通過API網(wǎng)關(guān)由HTTP請求來調(diào)用，也可以按時間表來運(yùn)行。請注意：Lambda并不是市面上唯一的計算服務(wù)。微軟Azure函數(shù)（Microsoft Azure Functions）、IBM Bluemix OpenWhisk和谷歌云函數(shù)（Google Cloud Functions）是你可能應(yīng)該關(guān)注的其他計算服務(wù)。

編寫單一用途的無狀態(tài)函數(shù)

作為軟件工程師，你在設(shè)計函數(shù)時應(yīng)該盡量著眼于單一職責(zé)原則（SRP）。單單處理某一項任務(wù)的函數(shù)更容易測試、運(yùn)行穩(wěn)定，而且?guī)淼腻e誤和意外的副作用比較少。通過以一種松散編排的方式將函數(shù)和服務(wù)組合起來，你就能構(gòu)建照樣易于理解、易于管理的復(fù)雜后端系統(tǒng)。擁有明確定義的接口的細(xì)粒度函數(shù)也更有可能在無服務(wù)器架構(gòu)里面被重復(fù)使用。

為Lambda等計算服務(wù)編寫的代碼應(yīng)該以無狀態(tài)方式來構(gòu)建。它不得假設(shè)：本地資源或進(jìn)程會在當(dāng)前的會話之后生存下去。無狀態(tài)性功能很強(qiáng)大，因為它讓平臺得以迅速擴(kuò)展，以處理數(shù)量不斷變化的入站事件或請求。

設(shè)計基于推送的、事件驅(qū)動的管道

可以構(gòu)建滿足任何用途的無服務(wù)器架構(gòu)。系統(tǒng)可以一開始就構(gòu)建成無服務(wù)器，也可以逐步重新設(shè)計現(xiàn)有的整體單一式應(yīng)用程序，以便充分發(fā)揮這種架構(gòu)的優(yōu)勢。最靈活、最強(qiáng)大的無服務(wù)器設(shè)計是事件驅(qū)動型的。圖4顯示了我們?nèi)绾螌嗰R遜的簡單存儲服務(wù)（S3）、Lambda和Elastic Transcoder連接起來，構(gòu)建一條事件驅(qū)動的、基于推送的管道。

構(gòu)建事件驅(qū)動的、基于推送的系統(tǒng)常常有望降低成本和復(fù)雜性（你不需要運(yùn)行額外代碼來輪詢變更），可能讓整個用戶體驗更流暢。不言而喻，雖然事件驅(qū)動的、基于推送的模式是個美好的目標(biāo)，但它們并非在所有情況下都是適當(dāng)?shù)幕蚩梢詫崿F(xiàn)的。有時候，你不得不實施一個Lambda函數(shù)來輪詢事件源或按時間表運(yùn)行。

圖4：基于推送的管道這種設(shè)計風(fēng)格與無服務(wù)器架構(gòu)非常搭配。在這個例子中，用戶上傳一段轉(zhuǎn)碼成不同格式的視頻。上傳創(chuàng)建了一個事件，從而觸發(fā)了Lambda函數(shù)。該函數(shù)創(chuàng)建一個轉(zhuǎn)碼作業(yè)。轉(zhuǎn)碼作業(yè)提交給轉(zhuǎn)碼視頻服務(wù)，新的視頻創(chuàng)建后，被保存到另一個S3存儲桶。保存新視頻這個過程觸發(fā)了另一個Lambda函數(shù)，該函數(shù)反過來更新數(shù)據(jù)庫。數(shù)據(jù)庫中一個新的條目觸發(fā)了最后一個函數(shù)，該函數(shù)創(chuàng)建通知，并調(diào)用通知服務(wù)，實現(xiàn)調(diào)派。在這個例子中，所有函數(shù)和服務(wù)僅僅負(fù)責(zé)一個動作，整個編排易于調(diào)整。

創(chuàng)建更粗實、更強(qiáng)大的前端

有必要記住這一點(diǎn)，在Lambda中運(yùn)行的自定義代碼應(yīng)該快速執(zhí)行。較早終結(jié)的函數(shù)較便宜，因為Lambda定價基于請求數(shù)量、執(zhí)行時間段以及分配的內(nèi)存量。在Lambda中要處理的事務(wù)比較少來得比較省錢。此外，擁有調(diào)用服務(wù)的更豐富的前端有利于更好的用戶體驗。在線資源之間更少的環(huán)節(jié)和縮短的延遲會讓人覺得應(yīng)用程序的性能和可用性更好。

數(shù)字簽名的令牌讓前端可以與不同的服務(wù)（包括數(shù)據(jù)庫）直接進(jìn)行通信。相比之下，在傳統(tǒng)系統(tǒng)中，所有通信經(jīng)由后端服務(wù)器來進(jìn)行實現(xiàn)。讓前端與服務(wù)進(jìn)行通信有助于創(chuàng)建環(huán)節(jié)少得多、盡快獲得所需資源的系統(tǒng)。

然而，不是一切都可以或者都應(yīng)該在前端執(zhí)行。有些秘密無法交給客戶端設(shè)備。處理信用卡或向訂戶發(fā)送電子郵件只能由不受最終用戶控制的服務(wù)來完成。在這種情況下，就需要計算服務(wù)來協(xié)調(diào)動作、驗證數(shù)據(jù)，并實施安全。

另外要考慮的重要一點(diǎn)是一致性。如果前端負(fù)責(zé)寫入到多個服務(wù)，可是中途出現(xiàn)故障，就會導(dǎo)致系統(tǒng)處于不一致的狀態(tài)。在這種情況下，應(yīng)該使用Lambda函數(shù)，因為它可以旨在從容地處理錯誤，重新嘗試失敗的操作。原子性和一致性在Lambda函數(shù)中實現(xiàn)起來和控制起來比在前端中容易得多。

擁抱第三方服務(wù)

如果第三方服務(wù)能提供價值、減少自定義代碼，自然歡迎它們加入。如今，開發(fā)人員可以充分利用許多服務(wù)，從用于驗證的Auth0服務(wù)，到用于支付處理的Stripe或Braintree服務(wù)，不一而足。只要考慮到價格、性能和可用性等因素，開發(fā)人員就應(yīng)該試著采用第三方服務(wù)。開發(fā)人員花時間解決其領(lǐng)域獨(dú)有的問題要比重復(fù)構(gòu)建別人已經(jīng)實施的功能有意義得多。如果已有了切實可行的第三方服務(wù)和API，別純粹為了構(gòu)建而構(gòu)建。應(yīng)站在巨人的肩上達(dá)到新的高度。

結(jié)束語

對IT基礎(chǔ)設(shè)施和軟件開發(fā)而言，云計算一向是改變行業(yè)規(guī)則的技術(shù)，現(xiàn)在也是如此。軟件開發(fā)人員需要認(rèn)真考慮他們最大限度地利用云平臺的方式，以獲得競爭優(yōu)勢。

無服務(wù)器架構(gòu)是開發(fā)人員和企業(yè)組織需要考慮、研究和采用的最新進(jìn)展。這是架構(gòu)領(lǐng)域出現(xiàn)的一種激動人心的新變化，隨著開發(fā)人員積極采用AWS Lambda等計算服務(wù)，這種架構(gòu)會迅速發(fā)展起來。如今，一些無服務(wù)器應(yīng)用程序支持成千上萬個用戶，并執(zhí)行復(fù)雜的操作，包括處理繁重任務(wù)，比如視頻編輯和數(shù)據(jù)處理。在許多情況下，無服務(wù)器架構(gòu)可獲得比傳統(tǒng)模式更好的效果，而且實施起來成本更低、速度更快。

還需要降低與運(yùn)行基礎(chǔ)設(shè)施，對傳統(tǒng)軟件系統(tǒng)進(jìn)行開發(fā)有關(guān)的復(fù)雜性和成本。減少花在基礎(chǔ)設(shè)施維護(hù)上的時間和成本，加上可擴(kuò)展性帶來的好處，這些是企業(yè)組織和開發(fā)人員考慮無服務(wù)器架構(gòu)的充分理由。在今后幾年，無服務(wù)器后端的發(fā)展步伐可能只會加快。