 |
VOOZH | about |
|
VOOZH | about |
這篇文章摘錄自彼得·薩巴斯基(Peter Sbarski)和薩姆·克魯內伯格(Sam Kroonenburg)合著的《AWS上的無伺服器架構》一書，概述了無伺服器架構的五大原則。
彼得·薩巴斯基和薩姆·克魯內伯格合著的《走無伺服器道路》(Go Serverless)一書。
如果你問軟體開發人員何謂軟體架構，可能會得到五花八門的答案：軟體架構「是藍圖或計劃」、「概念模型」或「大局」，不一而足。毫無疑問，架構或缺少架構關係到軟體的成敗。良好的架構有助於擴展Web或移動應用程式，而糟糕的架構可能導致嚴重問題，勢必需要重寫、花費高昂成本。了解架構方面的選擇帶來的影響，並且能夠提前規劃，這對於構建高效、高性能、最終成功的軟體系統來說極為重要。
這篇文章闡述了為什麼我們認為，無伺服器架構對軟體開發人員和解決方案架構師來說是改變行業規則的技術。它介紹了AWS Lambda之類的關鍵服務，還介紹了無伺服器架構的幾個原則，幫助你了解什麼造就真正的無伺服器系統。
名稱中有什麼？
在我們開始探討正文之前，應該提到無伺服器這個詞有點用詞不當。無論你使用AWS Lambda之類的計算服務來執行代碼還是與API進行交互，仍然有伺服器在後台運行。區別在於，這些伺服器隱藏起來，我們是看不見的。我們不需要考慮基礎設施，也無法調整/改動底層作業系統。別人負責基礎設施管理的基本細節，那樣我們可以騰出時間處理其他事情。無伺服器技術是指，在計算服務中運行代碼，並與服務和API進行交互，以完成任務。
我們如何走到今天這一步？
如果你看一看支持如今大多數具有Web功能的軟體的系統，就會發現後端伺服器執行各種各樣的計算任務，而客戶端前端為用戶提供界面，以便通過瀏覽器、行動裝置或桌面設備進行操作。
在一個典型的Web應用程式中，伺服器接受來自前端的HTTP請求，處理請求。數據在保存到資料庫之前可能經過無數個應用層次。最後，後端生成響應――可能採用JSON或完全呈現的標記這種形式，響應被發回給客戶端(圖1)。當然，一旦將其他元素考慮進來，比如負載均衡、事務、集群、緩存、消息傳遞和數據冗餘，大多數系統比較複雜。大多數這種軟體需要伺服器在數據中心或在雲端運行，這些伺服器需要加以管理、維護、打補丁和備份起來。
圖1：這是一種基本的請求/響應(客戶端/伺服器)消息交換模式，大多數開發人員對此很熟悉。該圖中只有一台Web伺服器和一個資料庫。大多數系統要複雜得多。
伺服器的配置、管理和打補丁是一項很耗費時間的任務，常常需要專門的操作人員。很難搭建並高效地運行一個重大的環境。基礎設施和硬體是任何IT系統的必要組成部分，但它們也常常讓人容易分心，忽視最重要的事情：解決業務問題。
過去這幾年出現了平台即服務(PaaS)和容器等技術，這些解決方案有望解決這個頭痛的問題：基礎設施環境不一致、衝突和伺服器管理開銷。PaaS是一種雲計算，它為用戶提供了運行軟體的平台，同時把一部分底層基礎設施隱藏起來。為了有效地使用PaaS，開發人員需要編寫針對該平台相應功能特性的軟體。由於大多數PaaS實現方法具有短暫性，把當初被設計成在獨立伺服器上運行的老式應用程式遷移到PaaS服務，需要額外的開發工作。不過，如果面臨選擇，許多開發人員會決定使用PaaS，而不是更傳統、更手動化的解決方案，那是由於PaaS減少了維護和平台支持方面的要求，這可以理解。
容器化是一種隔離應用程式的方法，讓應用程式有自己的環境。這種輕量級方法可替代全面的虛擬化。容器是孤立的、輕量級的，但它們需要部署到伺服器上，無論在公共雲上、在私有雲中還是在現場。如果依賴關係明確，容器是一種出色的解決方案，不過它們在內務處理(housekeeping)方面有各自的挑戰和複雜性。它們並不是與僅僅能夠直接在雲端運行代碼來得一樣容易。
最後，我們迎來了Lambda，這是亞馬遜網絡服務(AWS)提供的一種計算服務。Lambda能夠以一種大規模並行方式執行代碼，以響應事件。Lambda拿來你的代碼後即可運行，根本不需要配置伺服器、安裝軟體、部署容器，或者是為低層細節而操心。AWS負責配置和管理運行實際代碼的彈性計算雲(EC2)伺服器，並提供開發人員不需要考慮的一套高可用性計算基礎設施，包括容量配置和自動擴展機制。無伺服器架構這個詞是指這些新型的軟體架構：不需要直接訪問伺服器就能運行。通過採用Lambda，並充分利用各種功能強大的單一用途的API和Web服務，開發人員就可以迅速構建鬆散耦合、可擴展、高效的架構。無伺服器架構的最終目的就是，遠離伺服器和基礎設施方面的問題，讓開發人員可以主要專注於代碼。
面向服務的架構和微服務
在許多不同的系統和應用程式架構當中，面向服務的架構(SOA)在軟體開發人員當中具有很高的知名度。這種架構清楚地使這個想法概念化：系統可以由許多獨立的服務組成。SOA方面的文章已寫了不少，可是由於開發人員常常把設計理念與具體的實施和屬性混為一談，所以它仍存在爭議和誤解。
SOA沒有硬性規定使用任何特定的技術。相反，它鼓勵這樣一種架構方法：開發人員創建自治服務，這些服務通過消息傳遞來進行聯繫，常常有一種模式(schema)或契約(contract)，定義了消息是如何創建或交換的。服務的可重用性、自主性、可組合性、細粒度和可發現性，這些都是與SOA有關的重要原則。
微服務和無伺服器架構在核心思想上與面向服務的架構一脈相承。它們保留了許多上述原則和理念，同時試圖消除老式的面向服務架構具有的複雜性。
最近出現的一股趨勢是，使用微服務架構來實施系統。開發人員往往把微服務考慮成小型、單獨、完全獨立的服務，它們圍繞一個特定的業務用途或功能而建。微服務可能有一個應用程式層，有自己的API和資料庫。
理想情況下，微服務應該易於替換，每個服務用一種適當的框架和語言編寫而成。微服務可以用不同的通用語言或特定領域語言(DSL)來編寫，光這一點就讓許多開發人員為之著迷。雖然可以通過使用合適的語言或針對相應任務的一套專用庫來獲得一些好處，但這也常常是個陷阱。如果擁有多種語言和框架，支持起來有難度;要是沒有一套嚴格的準則，會在將來導致混淆和困難。
每個微服務可能保持其狀態、存儲數據，這增加了系統的複雜性。一致性和協調性管理也可能成為一個問題，因為狀態必須常常跨不同的服務來加以同步。微服務可以通過消息總線間接聯繫，也可以通過將消息發給對方來直接聯繫。
可以說，無伺服器架構同樣體現了來自微服務的許多原則。畢竟，每個計算函數都可以被認為是其自己的獨立服務，這取決於你如何設計系統。然而，你不需要完全接受微服務口號，就可以圍繞某個特定的業務用途來開發每個函數或服務，保持狀態，等等。
無伺服器架構的好處在於，你想運用幾個微服務原則，就可以隨意運用幾個，不會迫使你只有華山一條道。
軟體設計
軟體設計已從昔日代碼在大型機上運行，變成如今在多層系統上運行：在許多設計中，表示層、數據層和應用/邏輯層具有重要地位。在每層裡面，可能有多個邏輯層次處理某一功能或領域的特定方面。還有可能跨眾多層次的橫切組件(cross-cutting component)，比如日誌或異常處理系統。青睞分層可以理解。分層讓開發人員得以將關注點分離開來，開發出更易維護的應用程式。
但是，反過來也可能如此。層次太多可能導致效率低下。一個小小的變化常常帶來連鎖反應，導致開發人員修改整個系統中的每個層次，把大量的時間和精力花費在實施和測試上。層次數量越多，久而久之系統會變得越複雜、越笨拙。圖2顯示了具有多個層次的分層架構的一個例子。
圖2：一個典型的三層應用程式通常由表示層、應用層和數據層組成。在每個層中，可能有多個層次，它們有特定的職責。開發人員可以選擇各層次彼此如何聯繫。這可以是嚴格的自上而下的方式，也可以是一種鬆散的方式：各層次可以繞過緊鄰的層次，與其他層次對話。層次的聯繫方式將影響性能、依賴項管理和應用程式的複雜性。然後還有橫跨多個層次的功能――這叫作橫切關注點(cross-cutting concern)。
無伺服器架構實際上有助於解決分層、非得更新太多對象這一問題。開發人員有機會消除或儘量減少層次，只要將系統分成多個功能，讓前端得以安全地與服務、甚至資料庫直接進行通信，如圖3所示。這一切都可以以一種有組織的方式來實現，可以清楚地定義服務邊界，防止義大利麵條式實施和依賴項惡夢，讓Lambda函數成為自治式，並且規劃函數和服務如何交互。
圖3：在無伺服器架構中，沒有單一的傳統後端。通過API網關，應用程式的前端直接與服務、資料庫或計算函數進行聯繫。然而，有些服務必須隱藏在計算服務函數後面，額外的安全措施和驗證可能在這裡進行。
無伺服器方法解決不了所有問題，也無法消除系統的底層複雜性。然而，如果實施得當，它還是可以為減少、釐清和管理複雜性帶來機會。精心規劃的無伺服器架構可以讓開發人員更容易在將來做出變化，這對任何長期的應用程式來說都是一個重要因素。下一節將更詳細地討論服務的組織和編排。
層vs層次
一些開發人員對於層次(layer)與層(tier)之間的區別分不太清楚。層是一種模塊邊界，它是為了隔離系統的主要組件而存在的。用戶看得見的表示層與包括業務邏輯的應用層分開來。反過來，數據層是另一個獨立的系統，負責數據的管理、持久化和訪問。分組在一個層中的組件可能實際上駐留在不同的基礎設施上。
層次是邏輯片段，負責執行應用程式中特定的職責。每一層在裡面可能有多個層次，負責功能的不同部分，比如域服務。
無伺服器架構的原則
無伺服器架構有五大原則，描述了一個理想的無伺服器系統應該如何構建。你在構建無伺服器架構時，可以運用這些原則，幫助指導你做出決定。
1.根據需要，使用計算服務來執行代碼(沒有伺服器)。
2.編寫單一用途的無狀態函數。
3.設計基於推送的、事件驅動的管道。
4.創建更粗實、更強大的前端。
5.擁抱第三方服務。
不妨更詳細地分析這每一個原則。
根據需要，使用計算服務執行代碼
無伺服器架構是SOA概念的自然延伸。在無伺服器架構中，所有自定義代碼作為孤立的、獨立的、常常細粒度的函數來編寫和執行，這些函數在AWS Lambda之類的無狀態計算服務中運行。開發人員可以編寫函數，執行幾乎任何常見的任務，比如讀取和寫入到數據源、調用函數以及執行計算。在比較複雜的情況下，開發人員可以構建更複雜的管道，編排多個函數的調用。可能會有這種場景：仍需要伺服器來處理某個任務。然而，這種情況並不多見;作為開發人員，你應該儘量避免運行伺服器、與之交互。
那麼，Lambda究竟是什麼？
Lambda是一種計算服務，它在AWS基礎設施上執行用用JavaScript(node.js)、Python或Java編寫的代碼。原始碼部署到孤立的容器上，該容器有單獨分配的內存、磁碟空間和處理器。代碼、配置和依賴項這一組合通常被稱為Lambda函數。Lambda運行時環境可以並行多次調用某個函數。Lambda支持推拉事件操作模式，並與數量眾多的AWS服務整合起來。函數可以通過API網關由HTTP請求來調用，也可以按時間表來運行。請注意：Lambda並不是市面上唯一的計算服務。微軟Azure函數(Microsoft Azure Functions)、IBM Bluemix OpenWhisk和谷歌雲函數(Google Cloud Functions)是你可能應該關注的其他計算服務。
編寫單一用途的無狀態函數
作為軟體工程師，你在設計函數時應該儘量著眼於單一職責原則(SRP)。單單處理某一項任務的函數更容易測試、運行穩定，而且帶來的錯誤和意外的副作用比較少。通過以一種鬆散編排的方式將函數和服務組合起來，你就能構建照樣易於理解、易於管理的複雜後端系統。擁有明確定義的接口的細粒度函數也更有可能在無伺服器架構裡面被重複使用。
為Lambda等計算服務編寫的代碼應該以無狀態方式來構建。它不得假設：本地資源或進程會在當前的會話之後生存下去。無狀態性功能很強大，因為它讓平台得以迅速擴展，以處理數量不斷變化的入站事件或請求。
設計基於推送的、事件驅動的管道
可以構建滿足任何用途的無伺服器架構。系統可以一開始就構建成無伺服器，也可以逐步重新設計現有的整體單一式應用程式，以便充分發揮這種架構的優勢。最靈活、最強大的無伺服器設計是事件驅動型的。圖4顯示了我們如何將亞馬遜的簡單存儲服務(S3)、Lambda和Elastic Transcoder連接起來，構建一條事件驅動的、基於推送的管道。
構建事件驅動的、基於推送的系統常常有望降低成本和複雜性(你不需要運行額外代碼來輪詢變更)，可能讓整個用戶體驗更流暢。不言而喻，雖然事件驅動的、基於推送的模式是個美好的目標，但它們並非在所有情況下都是適當的或可以實現的。有時候，你不得不實施一個Lambda函數來輪詢事件源或按時間表運行。
圖4：基於推送的管道這種設計風格與無伺服器架構非常搭配。在這個例子中，用戶上傳一段轉碼成不同格式的視頻。上傳創建了一個事件，從而觸發了Lambda函數。該函數創建一個轉碼作業。轉碼作業提交給轉碼視頻服務，新的視頻創建後，被保存到另一個S3存儲桶。保存新視頻這個過程觸發了另一個Lambda函數，該函數反過來更新資料庫。資料庫中一個新的條目觸發了最後一個函數，該函數創建通知，並調用通知服務，實現調派。在這個例子中，所有函數和服務僅僅負責一個動作，整個編排易於調整。
創建更粗實、更強大的前端
有必要記住這一點，在Lambda中運行的自定義代碼應該快速執行。較早終結的函數較便宜，因為Lambda定價基於請求數量、執行時間段以及分配的內存量。在Lambda中要處理的事務比較少來得比較省錢。此外，擁有調用服務的更豐富的前端有利於更好的用戶體驗。在線資源之間更少的環節和縮短的延遲會讓人覺得應用程式的性能和可用性更好。
數字簽名的令牌讓前端可以與不同的服務(包括資料庫)直接進行通信。相比之下，在傳統系統中，所有通信經由後端伺服器來進行實現。讓前端與服務進行通信有助於創建環節少得多、儘快獲得所需資源的系統。
然而，不是一切都可以或者都應該在前端執行。有些秘密無法交給客戶端設備。處理信用卡或向訂戶發送電子郵件只能由不受最終用戶控制的服務來完成。在這種情況下，就需要計算服務來協調動作、驗證數據，並實施安全。
另外要考慮的重要一點是一致性。如果前端負責寫入到多個服務，可是中途出現故障，就會導致系統處於不一致的狀態。在這種情況下，應該使用Lambda函數，因為它可以旨在從容地處理錯誤，重新嘗試失敗的操作。原子性和一致性在Lambda函數中實現起來和控制起來比在前端中容易得多。
擁抱第三方服務
如果第三方服務能提供價值、減少自定義代碼，自然歡迎它們加入。如今，開發人員可以充分利用許多服務，從用於驗證的Auth0服務，到用於支付處理的Stripe或Braintree服務，不一而足。只要考慮到價格、性能和可用性等因素，開發人員就應該試著採用第三方服務。開發人員花時間解決其領域獨有的問題要比重複構建別人已經實施的功能有意義得多。如果已有了切實可行的第三方服務和API，別純粹為了構建而構建。應站在巨人的肩上達到新的高度。
結束語
對IT基礎設施和軟體開發而言，雲計算一向是改變行業規則的技術，現在也是如此。軟體開發人員需要認真考慮他們最大限度地利用雲平台的方式，以獲得競爭優勢。
無伺服器架構是開發人員和企業組織需要考慮、研究和採用的最新進展。這是架構領域出現的一種激動人心的新變化，隨著開發人員積極採用AWS Lambda等計算服務，這種架構會迅速發展起來。如今，一些無伺服器應用程式支持成千上萬個用戶，並執行複雜的操作，包括處理繁重任務，比如視頻編輯和數據處理。在許多情況下，無伺服器架構可獲得比傳統模式更好的效果，而且實施起來成本更低、速度更快。
還需要降低與運行基礎設施，對傳統軟體系統進行開發有關的複雜性和成本。減少花在基礎設施維護上的時間和成本，加上可擴展性帶來的好處，這些是企業組織和開發人員考慮無伺服器架構的充分理由。在今後幾年，無伺服器後端的發展步伐可能只會加快。
