不過哪些應(yīng)用程序適合這種部署方式？答案與您面對AWS或者Azure時基本相同; 這些系統(tǒng)的設(shè)計目標都是通過具體操作觸發(fā)代碼塊。以下五種常見的無服務(wù)器框架可行方案相信值得您加以參考。

 

作為無服務(wù)器架構(gòu)最簡單也最直接的應(yīng)用之一，我們可以通過服務(wù)或者單頁面應(yīng)用創(chuàng)建REST API以返回待消費數(shù)據(jù)。

REST API并不難構(gòu)建。一般來講，大家只需要一套基本W(wǎng)eb框架、一套用于渲染數(shù)據(jù)返回格式的庫（例如JSON）以及用于同數(shù)據(jù)后端進行交互的粘接代碼即可。利用無服務(wù)器架構(gòu)，開發(fā)者能夠?qū)Ｗ⒂诰帉懖⒉渴鹬С衷揂PI所需要的代碼，其它任務(wù)則不再需要費心。

REST API當中多數(shù)需要手動調(diào)節(jié)的功能，例如自動規(guī)模伸縮，皆可在無服務(wù)器框架中自動完成。另外，其按資源使用量付費的模式意味著您能夠擁有一套輕量化且訪問成本極低的API，且?guī)缀鯚o需任何部署工作。

 

這種被廣泛使用的HTTP上回調(diào)機制能夠輕松實現(xiàn)推送、管道與插件等功能，從而提升Web應(yīng)用的實用性。無服務(wù)器框架特別適用于webhook場景，且相關(guān)優(yōu)勢與創(chuàng)建API類似：低運營成本、低維護要求、可自動規(guī)模伸縮。大家完全可以在Azure Functions上利用Node.js實現(xiàn)webhook以處理Twilio服務(wù)中的短信消息或電話呼叫。

更重要的是，大部分webhook類活動并不需要大量代碼。因此，其非常適合由lambda式無服務(wù)器設(shè)計提供的面向功能方案實現(xiàn)，從而顯著簡化整個交付流程。

提供靜態(tài)內(nèi)容

無服務(wù)器架構(gòu)還提供一種簡單方法以支撐靜態(tài)內(nèi)容，包括圖片、音頻或者HTML頁面等不會被應(yīng)用修改的內(nèi)容。靜態(tài)資產(chǎn)可存儲在多個后端當中，包括Amazon S3存儲桶，并通過地理化緩存（例如Cloudflare）實現(xiàn)加速。（如果您使用S3，則可選擇Amazon Route 53以將URL映射至特定資源; 在基本場景下甚至完全無需涉及AWS Lambda。）

同樣的，無服務(wù)器模式的優(yōu)勢在于自動接著各項組件以契合需求。我們也能夠在必要時以相對簡單的方式添加動態(tài)功能。不過在這種情況下，功能在啟動時間可能對性能造成影響，因此需要對應(yīng)引入地理緩存機制。

 

這類用例可以視為上述方法的集合體。單一頁面的基礎(chǔ)資產(chǎn)可視為靜態(tài)內(nèi)容; 前端數(shù)據(jù)提供由API調(diào)用實現(xiàn)。前端的數(shù)據(jù)渲染則通過JavaScript框架完成。

優(yōu)勢：應(yīng)用的每項元素皆可獨立實現(xiàn)并進行獨立擴展。弊端：應(yīng)用必須作為多項獨立功能的集合，而非單一統(tǒng)一項目。這意味著我們無法利用現(xiàn)代源代碼控制與項目管理技術(shù)對其進行全面打理。另外，大家還需要引入React、Angular或者Vue.js等前端框架——不過這對于有經(jīng)驗的Web開發(fā)者來說應(yīng)該不是什么問題。

運行在后臺的事件驅(qū)動型應(yīng)用

無服務(wù)器應(yīng)用可響應(yīng)事件，但并不是說這些事件就必須屬于HTTP請求。其可以為云服務(wù)中的事件或消息管道，也可以由運行計劃負責觸發(fā)——大家可以借此方便地執(zhí)行被動或者低優(yōu)先級功能。例如被上傳至S3存儲桶的圖像可解決對應(yīng)功能，旨在為該圖像提供對應(yīng)的元數(shù)據(jù)標簽、大小調(diào)整并根據(jù)圖像識別或分析API的反饋進行裁剪。

無服務(wù)器框架的突出特性在于，其中的各個組件采取松散耦合模式——或者可以將其形容為微服務(wù)形式。如果大家不希望采取這樣的組合方式或者面對的是整體式應(yīng)用的移植工作，那么無服務(wù)器架構(gòu)可能并不合適。但在另一方面，其顯然更適合支持新型、元素數(shù)量較少且各組件需要獨立擴展的應(yīng)用。

 

原文鏈接：

原文標題：Build 'em now! 5 uses for serverless frameworks

原文作者：Serdar Yegulalp