很多朋友搞不清“無服務器”與“功能即服務”架構之間的區別。其一，無服務器其實有點用詞不當，其中當然存在服務器元素，只是大家不必親自維護。您需要做的只是上傳代碼片段并由托管服務處理其余工作。

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

 API

作為無服務器架構最簡單也最直接的應用之一，我們可以通過服務或者單頁面應用創建REST API以返回待消費數據。

REST API并不難構建。一般來講，大家只需要一套基本Web框架、一套用于渲染數據返回格式的庫(例如JSON)以及用于同數據后端進行交互的粘接代碼即可。利用無服務器架構，開發者能夠專注于編寫并部署支持該API所需要的代碼，其它任務則不再需要費心。

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

創建webhook

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

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

提供靜態內容

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

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

單頁面應用

這類用例可以視為上述方法的集合體。單一頁面的基礎資產可視為靜態內容; 前端數據提供由API調用實現。前端的數據渲染則通過JavaScript框架完成。

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

運行在后臺的事件驅動型應用

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

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

原文鏈接：

http://www.infoworld.com/article/3165484/cloud-computing/build-em-now-5-uses-for-serverless-frameworks.html

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

原文作者：Serdar Yegulalp