看了這個無伺服器的案例，國內雲都是浮雲

Web應用程式
無伺服器Web應用程式是無伺服器計算的最常見用例。請考慮以下情形。

如果你是斯里蘭卡最大購物中心的技術長，每天有10,000名使用者訪問網站，該應用程式具有Web、移動前端和連線到資料庫的API。目前，它使用自己的內部伺服器執行，這給公司帶來了巨大的成本。你現在希望將整個站點移至AWS Cloud，以實現更高的可用性和成本降低。

你如何進行這種遷移？

涉及無伺服器Web應用程式一般有以下考慮因素：

1. Web應用的執行成本應該是最低的
2. 能夠執行和監控Web應用以實現業務價值
3. 必須不惜一切代價保護Web應用的資料
4. Web應用應該能夠從服務中斷中恢復
5. Web應用應滿足要求中的效能標準

在上面這張指定的場景中，顯然有一個與API通訊的靜態Web應用程式。在AWS中，託管靜態Web應用程式的最佳方式是在S3上。

好了，我們使用了S3儲存桶託管靜態Web應用程式，然後透過CDN廠商CloudFront分發服務。為什麼我們在網站前使用CloudFront？簡單地說，CloudFront充當CDN，用於快取網站的影像，html，css和javascript。

接下來我們有一個rest API需要放入架構。可以使用AWS API Gateway作為我們的REST api實現。

API Gateway是AWS提供的無伺服器API，它可以自動擴充套件以滿足來自客戶端的任意數量的請求。在API閘道器收到請求後，它將轉發到相應的資源或代理服務，在本例中代理服務為AWS Lambda。

AWS Lambda是AWS的無伺服器計算產品，它可以啟動數十萬個並行lambda函式，以便從任意數量的請求中執行業務邏輯，因此，你不必擔心如何擴充套件無伺服器了！

Lambda函式內部的邏輯可以處理包括與資料庫通訊等工作。在上面的線上購物中心場景，資料庫可以使用AWS DynamoDB，它是AWS提供的完全託管的NoSQL資料庫產品。

然而，我們的架構並不完整，安全性必須設計到位，由於這是一個線上購物中心，安全是最重要的。讓我們將AWS Cognito服務插入到體系結構中。

對於無伺服器應用程式，將使用者與應用程式分離是一種很好的做法，這將讓使用者在不影響應用程式效能的情況下獨立增長，你可以確保該應用支援具有行業標準身份驗證和授權協議的數十億使用者。

AWS Cognito可用於身份驗證和授權需求，Cognito有兩個部分，Cognito User Pool和Cognito Federated Identities。

Cognito UserPool是您的使用者池，它將管理應用程式的所有使用者，它支援多種行業標準協議，如OAuth 2.0和SAML。

Cognito Federated Identities將為已登入使用者應用AWS策略，其中說明了已登入使用者允許或拒絕的資源，一旦使用者登入，他就可以呼叫下游服務，只有當使用者被允許呼叫它們時才會允許。

我們可以使用IAM策略在三個級別上保護下游服務。

1. 認證
2. API閘道器級安全性
3. 資料庫級安全性

好的！我們完成了線上購物中心的所有設定。

事件驅動的資料處理
如果應用已在S3上成功啟動並執行，開發人員可以開始最佳化該站點，因為客戶抱怨：“該網站非常慢”。

經過研究發現，在登入頁上載入高解析度產品圖片會導致速度變慢，作為補救措施，可以決定每次上傳產品圖片時生成縮圖並在登入頁面上顯示它們，從而加快網站載入速度。

事件驅動的資料處理是無伺服器計算的另一個主要用例，根據上面的場景，讓我們用非同步方式建立上傳影像的縮圖到S3的工作。

當站點管理員將產品影像上傳到S3時，它將發出S3 PUT事件。我們可以設定由此事件觸發一個Lambda函式。這是完全非同步處理，因此上傳過程可以與縮圖生成的過程解耦，此外，由於我們使用lambda進行處理，即使在大量請求時它也會很好地擴充套件。

流處理
讓我們繼續當前這個場景案例。

作為另一項改進，如果希望在網站上新增搜尋引擎，以便使用者即使在不知道產品的確切名稱/品牌的情況下也可以方便地搜尋產品。

當新產品新增到資料庫時，你決定使用Elasticsearch來索引所有產品資訊。

但是如何將Elasticsearch插入當前架構？

Elasticsearch是一個基於Lucine的搜尋引擎，根據當前該場景，我們可以用Elasticsearch叢集對產品進行索引，這樣能超快速地搜尋產品。為了以更非同步的方式索引Elasticsearch中的條目項，我們可以使用DynamoDB流。

流是按時間排序的資料序列，DynamoDB生成一個個條目項的修改動作流。我們設定一個Lambda函式，它在DynamoDB中建立條目項時被觸發。

這個Lambda函式只能由建立條目流觸發,它被觸發後，提取其中的條目項，放入Elasticsearch索引中，這樣前端客戶就可以查詢elasticsearch，更快速輕鬆地搜尋到自己需要的產品條目。

這時，CTO又得到了管理層的更多指示要求。

隨著網站越來越受歡迎，希望實時檢視網站指標以獲得洞察力：
>誰訪問該網站
>訪客數量
>在網站上花費的時間
>頁面瀏覽量
>有多少訪客幾乎買了一個產品並退出

如何在架構中實現實時資料處理？

構建良好的無伺服器應用程式的關鍵支柱之一是“卓越運營”，業務經理應該能夠查詢監控日誌獲得業務價值，以下是實時使用者事件日誌聚合器，它提供了有價值的分析：

該網站託管在S3。我們可以設定AWS Pinpoint服務來記錄興趣點（在Checkout頁面/登入頁面等等處設定）的使用者事件，並將這些事件收集儲存到AWS的Kinesis Firehose。

為了分析感興趣的資料和執行聚合的事件，我們可以使用Kinesis Data Analytics在預定義視窗（基於時間或基於大小）期間的訪問流，Kinesis Data Analytics使用SQL查詢資料流，它從定義的流視窗建立一個虛擬表並執行SQL查詢。我們可以掛鉤一個Lambda函式來消費使用Elasticsearch中的資訊和索引，一旦資料存在Elasticsearch中，我們就可以使用Kibana或其他視覺化工具來直觀觀察這些資料。

基於人工智慧的聊天機器人
我們對該網站又有一個有趣的要求：

為了改善網站的使用者體驗（UX），作為CTO，決定整合會話機器人，使用者可以透過語音搜尋和訂購專案，機器人將以語音回覆使用者的所有查詢。

AWS Lex是一項託管服務，允許開發人員以簡單的步驟建立會話機器人，開發人員不需要是深度學習或NLP（自然語言處理）專家。他們只需要提供幾個示例短語和相應的Lambda函式來執行，然後，AWS Lex將建立具有深度學習功能的NLP模型，它將在一段時間內接受培訓。

連線到Lex的Lambda函式可以執行很多操作（例如：建立訂單），並使用AWS Polly進行語音響應，這是一種文字到語音服務。

無伺服器工作流
讓我們繼續看看前面網上商城的情景。

如果你有三個主要供應商為公司提供庫存，需要設定一個工作流程能每次自動以檢查庫存中產品數量是否有少於5的？如果有就從相應的供應商處下訂單；如果無法聯絡供應商，就將產品標記為少於5個專案，否則更新庫存數量為新的數量。

如何將這個工作流分解為一個個步驟？
如何保持請求的狀態（跟蹤步驟）？

根據這個場景，該公司只有三個主要供應商，所有產品都屬於這些供應商之一，如果產品數量小於5，則應從相應的供應商處進行重新排序過程。

Lambda是無伺服器應用程式的計算構建塊，Lambdas目的是在指定的呼叫中執行單個操作，當我們為多個彼此依賴的操作新增邏輯時，如果整個操作過程全部完成肯定會超過300秒，那可能也會超時，這就有了一個問題。

實際上，單一責任原則（SRP）是一種很好的設計模式，可以在任何上下文中使用，以實現解耦和可管理的程式碼單元，因此，AWS引入了Step Function，它提供了一組連線任務（可以是lambda函式）來執行工作流。

當我們跨多個lambda函式分發工作流時，我們如何保持請求的狀態？換句話說，我們如何儲存工作流的狀態呢？從而能表達這個長流程當前位於哪個步驟？

Step Function提供瞭解決方案，它是一個狀態機，能被事件（例如：來自APIGateway的Http呼叫）呼叫，並保持執行直到當前這個工作流程完成，這樣也就是儲存了請求的狀態。

[img index=1]
上圖是狀態機的圖片，在第一步，它將執行一個lambda函式以獲得庫存數量少於五個的所有產品；在第二步，它將在有效負載上執行另一個lambda函式，該函式從基於第一步的結果來查詢相應產品的供應商；然後它將在供應商上執行一個選擇策略，它就像一個普通的開關邏輯，觸發相應供應商的重新下單功能（呼叫供應商的API），如果供應商沒有回覆，它將觸發預設的lambda函式，將當前產品的標籤更新為庫存少於5個以便後續人工處理。

結論
這篇文章是關於無伺服器模式和用例，無伺服器架構使我們能夠以最低成本從小規模開始，逐步發展具有豐富特性和功能的架構，同時保持架構高度可擴充套件且經濟高效。

Evolving Architecture | Serverless Patterns and Us

[該貼被admin於2018-08-23 13:50修改過]