概觀
在此實驗室中，您將建立簡單的常見問題集微服務。微服務會傳回一個 JSON 物件，內含隨機的問題和回答配對，使用會叫用 AWS Lambda 函數的 Amazon API Gateway 端點。以下是微服務的架構模式：
涵蓋的主題
本實驗室結束後，您將能夠：
- 建立 AWS Lambda 函數
- 建立 Amazon API Gateway 端點
- 使用 Amazon CloudWatch 對 API Gateway 和 Lambda 進行偵錯
先決條件
具備程式設計經驗及熟悉應用程式開發會有一定的幫助，但這並非執行此實驗室的必要條件。不過，在執行此實驗室之前，您應先完成 AWS Lambda 簡介自主進度實驗室。
其他 AWS 服務
在您存取此實驗室期間，IAM 政策會停用實驗室不需要的其他 AWS 服務。此外，這個實驗室所用服務的功能會受限於實驗室所需，且在某些情況下，更會因實驗室蓄意的設計而進一步受限。存取其他服務或執行此實驗室指南以外的動作時，將會發生錯誤。
技術概念
微服務架構
「微服務架構樣式是以小型服務套件的形式開發單一應用程式的方法，其中，每個服務各有其本身的程序，且會與輕量型機制通訊 (通常是 HTTP 資源 API)。這些服務是以商業功能為中心而建置的，且可由全自動化部署機器單獨部署。這些服務的集中化管理已降到最低限度，且可使用不同的程式設計語言來撰寫，並採用不同的資料儲存技術。」 – James Lewis 與 Martin Fowler
微服務架構的概念是，將大型的複雜系統分解為獨立且易於管理和擴充的分離式服務。這可讓開發人員達成其主要設計目標，例如擴充能力、可用性和維護性。
Amazon API Gateway 和 AWS Lambda 將 Web 服務完美結合，而能夠輕易建置、提供及維護一個微服務套件以供複雜的軟體系統作為基礎。
在此實驗室中，您將了解如何對一個簡單的微服務 (代表龐大系統的一部分) 進行開發、部署和偵錯。其中包含兩個部分：RESTful API 以及在使用者觸及端點時執行的函數。
應用程式設計界面 (API)
應用程式設計界面是一組指令，其定義開發人員應如何操作應用程式。API 的基礎概念是建立標準化方法來操作應用程式所提供的各種服務。API 設計為與軟體開發套件 (SDK) 搭配使用，後者是一個工具集合，可讓開發人員根據 API 輕鬆建立下游應用程式。
API 優先策略
許多軟體組織均採用 API 優先策略，亦即，其眾多的各項服務都會先 (且一律會) 發行為 API。在設計服務時，很難悉數得知眾多的應用程式中有哪些可能會使用該服務。例如，此實驗室中的常見問答集服務很適合植入外部網站的常見問答集頁面。但按理來看，雲端教育公司也會想要在其訓練教材中內嵌常見問答集，以製作閃示卡或訓練文件。如果全然是靜態網站，教育公司的內嵌程序將十分艱難。藉由提供可以標準化格式使用的 API，微服務將可用來開發服務的生態系統，以及最初未考量到的使用案例。
RESTFUL API
具象狀態傳輸 (REST) 是指符合六項條件限制的架構：
- 透過用戶端-伺服器模型來分離關注點。
- 用戶端會完整儲存狀態，而用戶端與伺服器之間的通訊則為無狀態。
- 用戶端會快取資料以改善網路效能。
- 伺服器與用戶端之間有統一的界面 (API 形式)。
- 隨著系統複雜度的增加，將會導入層。RESTful 元件可以有多層。
- 遵循隨需程式碼模式，在此模式下，程式碼可以即時下載 (在我們的案例中會以 Lambda 實作)，且可直接變更而無須更新用戶端。
此實驗室遵循 RESTful 模型。用戶端會將請求傳送至後端 Lambda 函數 (伺服器)。服務的邏輯會封裝在 Lambda 函數內，且會提供統一界面供用戶端使用。
建置 RESTFUL API 的最佳實務
建置 API 的主要目標之一，是要為您的服務集建立創新的生態系統。因此，您的 API 務必要直覺化且易於使用。以下是可遵循的常用命名和方法配置：
操作URL函數GET/questions傳回所有問題GET/questions/17傳回第 17 個問題POST/questions建立新問題PUT/questions/17更新第 17 個問題PATCH/questions/17局部更新第 17 個問題DELETE/questions/17刪除第 17 個問題請留意如何取得特定問題，API 端點並不是 /question/name，而是 /questions/identifier。如此，API 設計工具即可提供透過 /questions 端點傳回問題群組 (可以是所有問題) 的功能，以及透過 /questions/identifier 傳回單一記錄回應的功能。如需詳細資訊，請參閱此實驗室指南最後的其他資源區段。
以下是幾個值得參考的 RESTful API 範例：
- AWS Elemental MediaConvert
- Spotify
- Twitch
- Netflix Genie
- Slack
AMAZON API GATEWAY 和 AWS LAMBDA
一個使用 Amazon API Gateway 的微服務，由 API Gateway 中已定義的資源和相關聯的方法 (GET、POST、PUT 等) 以及後端目標所組成。在此實驗室中，後端目標將是 Lambda 函數。不過，後端目標也可以是其他 HTTP 端點 (第三方 API 或接聽端 Web 伺服器)、AWS 服務 Proxy，或要作為預留位置的模擬整合。
AMAZON API GATEWAY
API Gateway 是由 AWS 提供的受管服務，可讓 API 的建立、部署和維護更加容易。API Gateway 包含下列功能：
- 轉換傳入 API 請求的內文和標頭，以符合後端系統
- 轉換傳出 API 回應的內文和標頭，以符合 API 需求
- 透過 AWS Identity and Access Management 控制 API 存取
- 為第三方開發建立及套用 API 金鑰
- 啟用 Amazon CloudWatch 整合以進行 API 監控
- 快取 API 透過 Amazon CloudFront 進行回應，以加快回應速度
- 將一個 API 部署至多個階段，以輕易區分開發、測試和生產階段，以及進行版本控制
- 將自訂網域連線至 API
- 定義模型以利標準化 API 請求和回應轉換
AMAZON API GATEWAY 和 AWS LAMBDA 術語
- 資源：以 URL 端點和路徑表示。例如 api.mysite.com/questions。您可以將 HTTP 方法與資源產生關聯，並為每個方法定義不同的後端目標。在微服務架構中，一項資源會代表您系統內的單一微服務。
- 方法：在 API Gateway 中，方法會以資源路徑和 HTTP 動詞 (例如 GET、POST 和 DELETE) 的組合來識別。
- 方法請求：API Gateway 中的方法請求設定會儲存方法授權設定，並定義從用戶端接收的 URL 查詢字串參數和 HTTP 請求標頭。
- 整合請求：整合請求設定會定義用於方法的後端目標。您也可在此定義對應範本，用以轉換傳入的請求，以符合後端目標預期的格式。
- 整合回應：在整合回應設定中，您可以定義後端目標的回應與 API Gateway 中方法回應之間的對應。您也可以轉換從後端目標傳回的資料，使其符合最終使用者和應用程式預期的格式。
- 方法回應：方法回應設定會定義方法回應的類型、其標頭和內容類型。
- 模型：在 API Gateway 中，模型可定義某些資料的格式，亦稱為結構描述或形狀。您可以利用模型來簡化建立對應範本的程序。依據設計，API Gateway 主要是要與 JavaScript 物件標記法 (JSON) 格式的資料搭配使用；因此，API Gateway 會使用 JSON 結構描述來定義資料的預期結構描述。
- 階段：在 API Gateway 中，階段會定義據以存取 API 部署的路徑。這通常用來區分不同的版本，以及開發與生產端點等等。
- 藍圖：Lambda 藍圖是一個範例 Lambda 函數，可作為建置新 Lambda 函數的基礎。
