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

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

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

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

名稱中有什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

軟件設計

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

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

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

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

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

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

層vs層次

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

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

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

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

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

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

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

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

5.擁抱第三方服務。

不妨更詳細地分析這每一個原則。

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

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

那么，Lambda究竟是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

擁抱第三方服務

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

結(jié)束語

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

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

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