根據 AWS 解決方案架構師 Cassandra Bonner 在悉尼舉行的 APIdays 澳大利亞會議上的演講，Amazon Web Services 看到了適合采用無服務器架構的五種主要產品和設計模式。Bonner 總結當前無服務器技術的成熟度，顧問 Ken Fromm 最近在 A Cloud Guru 的 Medium 博客上寫道，無服務器架構允許開發人員專注于管理他們的應用程序和系統需要做的事情，而不是他們后端計算資源的物理算力、限制條件和復雜的基礎設施設置。這使得產品功能或業務模塊成為在無服務器環境中規模化拓展的基本單元，而不是更底層的計算資源。這意味著，軟件的計算任務往往是異步的、無狀態的和短暫的，或者正如 Fromm 所說：「任務處理本質上變成了容器處理，容器在逐個任務的基礎上按需配置和刪除。」在 APIdays，Bonner 表示 AWS 團隊認為無服務器包含四個主要原則：簡單但可用的最小元素(即小的、可用的基礎組件)。

　　隨使用量而彈性縮放(服務器代表用戶自動縮放)。

　　用多少付費多少(客戶只需為使用服務的時間付費)。

　　內置可用性和容錯(即 NoOps)。

　　在 APIdays 活動的早些時候，澳大利亞 Amazon Web Services 解決方案架構高級經理 Peter Stanski 曾表示，AWS 在澳大利亞和新西蘭市場(與世界大部分地區一樣)的傳統采用路徑在于中型企業。在過去的一兩年里，雖然初創公司通常從一開始就對無服務器服務「照單全收」，但擁有遺留系統的成熟企業通常會從開發和概念驗證測試來構建新應用程序，加入分析監控功能，然后開始遷移一些他們的遺留系統上云，最終專注于將任務關鍵型應用程序遷移到 AWS。

　　AWS 的 Peter Stanski 在澳大利亞 APIdays 上發表演講。Stanski 說，今年，各種規模的企業從一開始就傾向于「全力投入」云計算。他們將著手遷移現有遺留技術棧，同時直接在云服務上構建新的應用程序。

　　Bonner 描述了采用無服務器架構的類似趨勢：雖然新應用程序可能正在利用無服務器架構開發和托管，但在大多數情況下，企業正在采用混合模式托管軟件，在無服務器環境中構建新功能，然后融入并逐步脫離現有的企業軟件托管環境。「這就是我們看到很多客戶開始的方式，」Bonner 指出一個常見的例子：一家企業可能有一個管理圖像數據的現有工作流程，現在正在添加一個在無服務器中運行的圖像識別功能環境，然后將分類結果通過構建數據管道傳回到現有的(遺留)企業軟件工作流中，該工作流可能就托管于用戶的云環境中。Bonner 在無服務器架構下，為不同行業和用例定義了五種結合無服務器架構的產品設計模式：事件驅動的數據處理。

　　網絡應用程序。

　　移動和物聯網應用程序。

　　應用生態系統。

　　事件工作流。

　　用例 #1：事件驅動的數據處理

(事件驅動用例架構圖)

　　無服務器環境最常見的應用之一是在事件發生后觸發某個數據操作。Bonner 給出了將圖像對象添加到 Amazon S3 存儲桶的示例。這可能會觸發 lambda 函數，例如，運行壓縮任務，以便將圖像以標準尺寸格式重新歸檔到 S3 中。這種風格的用例也非常適合傳統云和無服務器云混合使用的趨勢。在這種趨勢中，無服務器被用來在更廣泛的托管環境中執行特定功能。

　　用例 #2：無服務器 Web 應用程序

(Web 應用程序用例的架構圖)

　　在無服務器 Web 應用程序中，可能會組合運行進程來確定用戶的上下文和用戶個性化信息，以提供滿足用戶請求的內容和功能。例如，在此用例中，靜態內容可能存儲在 S3 中，以便在瀏覽器中打開應用程序時顯示。同時，通過應用程序的 API 網關啟動處理以運行確定應用程序用戶上下文的 Lambda 函數。然后使用通過 lambda 函數生成并作為動態數據存儲在 DynamoDB 中的更多動態內容來增強靜態內容。

　　用例 #3：移動和物聯網應用

(移動應用用例的架構圖)

與 Web 應用程序用例類似，構建在無服務器環境中的移動和物聯網應用程序正在尋求根據用戶的上下文決定向用戶提供哪些內容。無服務器身份驗證用于確保用戶(無論是人還是機器)獲得適當授權以訪問信息或函數。然后 Lambda 執行函數并與 DynamoDB 中的數據交互以滿足用戶的需求。

　　用例 #4：無服務器應用生態系統

(應用生態系統用例的架構圖)

　　在應用程序生態系統中，應用程序或工作流是在無服務器環境中創建的，并結合了 AWS 功能和產品以及第三方服務商 API。Bonner 舉了一個例子，有人告訴 Amazon Echo，他們正在做演示，然后語音數據觸發 lambda 函數，通過 Slack API 將該消息傳遞給遠程團隊。然后在無服務器環境中輪詢確定團隊何時做出響應并向 Echo 發送反饋信息。

　　用例 #5：事件工作流

(事件工作流用例的架構圖)

　　最近發布的 AWS Step Functions 現在為無服務器工作流程的可能性增加了更復雜的功能。可以在 Step Functions 中創建決策樹，然后與 Lambda 和 AWS 產品對齊以執行工作流分支操作(盡管 Amazon Web Services 在澳大利亞突出顯示 Step Functions 令人困惑，因為它在澳大利亞尚不可用)。例如，使用發布/訂閱消息傳遞模型，可以通過狀態機可視化并擁有所有函數和分布式組件。用戶可以通過 Step Functions 和 lambdas 映射客戶入職流程、進入 CRM、購物車訂購和訂單履行，并自動添加 AWS 工具以確保工作流程能夠完成。因此，雖然 Fromm 談到無服務器主要是異步、無狀態和短暫的，但一旦進入更復雜的工作流和應用程序，一些持久狀態和進行同步調用的能力就會發揮作用。Step Functions 提供狀態機，以便 Lambda 函數可以為業務流程提供一定程度的即時狀態，其中無服務器應用程序可能需要結合同步和異步調用鏈。但是，像 iRobots 的 Ben Kehoe 這樣的無服務器高級用戶認為，Step Functions 當前的定價結構過于苛刻，無法在無服務器環境的生產中使用它。此外，默認節流限制表明其預期用途不包括彈性縮放，只包括瞬態事件調度。「我希望狀態即服務成為一種服務范式，可以用于無服務器架構中 FaaS 所需的低級瞬態狀態，無論是通過 Step Functions 還是其他服務，」Kehoe 在 Step Functions 首次發布之后在自己博客中寫道。

　　身份驗證的選擇

　　在無服務器環境中，還可以為實施中的無服務器設計模式和用例選擇最適合的用戶身份驗證和身份管理工作流。身份驗證方法可能會根據來自一個組織的多個用戶是否需要具有不同權限角色的訪問權限、用戶是否主要是客戶或合作伙伴是否具有某些訪問權限而改變。Jim Tran 和 Justin Pirtle 于去年 11 月在 AWS Re:Invent 上發表的視頻更詳細地描述了無服務器環境中可用的一些身份驗證選擇：AWS re:Invent 2016：無服務器身份驗證和授權：身份管理 (MBL306)。

　　不斷成熟中的無服務器工具和生態

　　雖然還沒接近成熟期，無服務器有機會成為企業通過云平臺交付產品和服務的主要力量。隨著 serverless 的成熟并越來越多地被新項目和混合應用所采用，隨著企業開始選擇將現有應用程序遷移到 serverless 架構，企業數字和上云的發展軌跡很可能會在無服務器市場重復，盡管 serverless 目前的市場占有率還較小。雖然面向企業和企業的關鍵任務軟件可能尚未出現，但一些安全功能和整體生態系統工具仍需成熟，但無服務器的用例表明，除了初創公司之外，無服務器的可能性越來越大就像今天成熟的云計算一樣，成為值得企業數字化「全面采用」的新一代云計算架構。
　　（邯鄲小程序開發）