本文說明 Microsoft Commercial Software Engineering (CSE) 小組如何與全球零售商合作，使用無伺服器架構在 Azure 和 Amazon Web Services (AWS) 雲端平臺之間部署高可用性 無伺服器解決方案。
架構
下載這個架構的 Visio 檔案 。
資料流程
- 使用者應用程式可以來自任何能夠登入到雲端的來源。 在此實作期間，使用者會登入閘道應用程式，以在 Azure 與 AWS 雲端之間對請求進行 50-50 的負載平衡。
- 任何回應還會透過 API 管理員閘道路由，然後將其傳送到要求者應用程式。
單元
Serverless Framework
此解決方案使用無伺服器架構，可從 Serverless， Inc. 取得。無伺服器架構的免費版本包含 CLI、更多外掛程式，以及有限的監視服務。 專業版本提供跨雲端操作的功能，如增強的監視和警示。 此架構支援 Node.js 和 Python 語言，以及 AWS 和 Azure 雲端主機。
若要將 Azure 與 Serverless Framework 搭配使用，您需要：
- Node.js，以封裝微服務
- Azure Functions，以提供與其他雲端平台類似的功能
- Serverless Framework，以支援多重雲端部署和監視
- 無伺服器多重雲端程式庫，為開發人員提供標準化執行時間 API
- Azure Functions 無伺服器外掛程式，以支援多重雲端部署。 此外掛程式一開始不會與可比較的 AWS Lambda 外掛程式相容，並已針對此專案延伸。
下圖顯示處理管線。 中介軟體層代表在到達處理常式之前所需的任何中繼功能。
與雲端無關的 API
每個平台上的無伺服器實作都支援作為微服務的個別功能，每個功能 VM 節點各有一個，並視需要執行處理。 每個 AWS Lambda 函數都有對應的 Azure Functions 函數。 無伺服器多重雲端程式庫將類似的微服務從任一雲端組建到與雲端無關的標準化 REST API，用戶端應用程式可以使用此 API 與任一平台進行相互作用。 因為抽象化的 API 層會提供程式碼來為每個平台處理相應的微服務，所以交易不需要轉譯。 與雲端無關的介面可讓使用者應用程式與雲端互動，而不需要知道或關心他們所存取的雲端平台。
下圖說明此概念：
搭配 GitOps 的 CI/CD
Serverless Framework 的主要工作是將應用程式部署到雲端所涉及的所有基礎結構問題抽象化。 透過使用以資訊清單為基礎的方法，無伺服器架構可以處理所有部署問題，以視需要自動化部署以支援 GitOps。
雖然此初始專案使用手動部署，但在雲端內或跨雲端執行資訊清單驅動的無伺服器組建、測試和部署是非常實際的作法。 此流程可以使用 GitOps 開發人員工作流程：從 Git 組建，使用品質閘道進行測試和評估，以及將無伺服器解決方案推送至兩個雲端提供者。 從專案開頭就使用 Serverless Framework 執行所有部署是最有效的方法。
API 管理員
API 管理員可以是現有或自訂的應用程式。 此實作中的 Apigee™ API 管理員僅充當路由器，為兩個雲端平台提供 50-50 交易負載平衡，其功能未得到充分利用。
API 管理員必須能夠：
- 視需要在雲端平台內部或外部部署
- 在兩個雲端平台之間路由訊息
- 記錄流量要求以協調非同步訊息流量
- 使用一般 REST API 從使用者應用程式以及向使用者應用程式轉送要求和回應
- 監控兩個雲端無伺服器架構部署的健康情況，以驗證其接收要求的能力
- 在每個雲端平台上執行自動健康情況和可用性檢查，以支援路由和高可用性
替代方案
Python 等其他語言可以實作解決方案，在此案例中，只要其得到雲端平台、AWS Lambda 和 Azure Functions 的無伺服器實作的支援。 此專案使用 Node.js 封裝微服務，因為客戶很熟悉 Node.js，而且 AWS 和 Azure 平台都支援此專案。
解決方案可以使用支援 Serverless Framework 的任何雲端平台，而不只是 Azure 和 AWS。 目前，Serverless Framework 報告與八個不同雲端提供者的相容性。 唯一要注意的是，確保支援多重雲端結構或其等效結構的元素在目標雲端平台上可供使用。
此初始實作中的 API 管理員僅充當路由器，為兩個雲端平台提供 50-50 交易負載平衡。 API 管理員可以針對特定情節併入其他商務邏輯。
實例詳細資料
在無伺服器運算中，雲端提供者動態配置微服務資源來執行程式碼，並且只對使用的資源收費。 無伺服器運算從基礎結構實作、程式碼部署和營運層面 (如規劃和維護) 抽象應用程式程式碼。
與其他服務一樣，每個雲端提供者都有自己的無伺服器實作，客戶很難在沒有相當大的營運影響和成本的情況下使用不同的提供者。 潛在客戶可能會認為這種情況會削弱他們的議價地位和敏捷性。 廠商鎖定是企業雲端採用的最大障礙之一。
開放原始碼 Serverless Framework 是通用的雲端介面，其用於跨雲端提供者開發和部署無伺服器運算解決方案。 針對無伺服器功能的開放原始碼和通用 API 可協助提供者、客戶和合作夥伴為最佳服務組建跨雲端解決方案。 Serverless Framework 透過解決廠商鎖定和跨雲端提供者備援的問題，減少採用雲端的障礙。 客戶可以根據成本、敏捷性和其他考慮因素最佳化他們的解決方案。
CSE 和 Azure 產品小組共同重寫無伺服器 CLI，以支援全新 Azure Functions 功能，如進階功能、API 管理和 KeyVault。 無伺服器 CLI 現在為 Azure 和 AWS 的 GitOps 部署提供標準介面。 此小組也開發無伺服器多重雲端程式庫，其提供標準化執行時間 API以用於將無伺服器應用程式部署到 AWS 和 Azure。
這種設計透過多重雲端平台之間的主動-主動容錯移轉提供高可用性，而不是主動-被動容錯移轉。 如果一個雲端提供者的服務變得狀況不良或無法使用，此解決方案可以將要求重設路徑到另一個雲端平台。
此專案符合下列技術目標：
- 建立跨產業解決方案。
- 使用多重雲端無伺服器程式庫來支援與雲端無關的 API，其與部署在任何地方的微服務進行相互作用。
- 支援 GitOps CI/CD 流程工作流程，以便在所有受支援的雲端平台上進行開發、測試和部署。
- 透過經過驗證的雲端閘道使用以 API 為基礎的存取，並使用將閘道作為路由器在雲端平台之間進行負載平衡。
使用 Serverless Framework 的其他潛在優點包括：
- 防止或減少廠商鎖定
- 使用多重雲端無伺服器程式庫在開發過程中可減少 40-60+% 的程式碼
- 開發合併不同雲端提供者服務的最佳解決方案
- 消除大多數平台和基礎結構的複雜性和維護需求
- 更輕鬆地進行資料共享、效能和成本比較，以及利用特殊供應項目的能力
- 主動-主動高可用性
潛在使用案例
- 使用無伺服器多重雲端程式庫中的與雲端無關 API 為多個平台寫入用戶端應用程式。
- 在無伺服器架構中，將一系列功能性微服務部署到多個雲端平台。
- 跨雲端平台使用與雲端無關的應用程式，而不需要知道或關心託管應用程式的平台。
考量
此文章不會描述安全性解決方案，雖然初始部署已包含。 有許多可能的安全性解決方案、一些相依的平台，而且此架構應該配合任何合理的解決方案。 使用者驗證是假定的最低安全性。
因為很難表達 AWS 和 Azure 無伺服器功能供應項目之間的區別，所以早期的工作應該專注於對應每個雲端平台上可用的功能，並確定必要的轉換需求。 您可以根據這些資訊開發與平台無關的 API。
由於任何開放原始碼的軟體需要長期維護和支援挑戰，使用開放原始碼解決方案可能會帶來風險。
在免費的 Serverless Framework 中，監視主要受限於系統管理儀表板。 付費企業供應專案提供監視。 目前，Azure Functions 無伺服器外掛程式不包含可檢視性或監視的佈建，並且需要修改才能實作這些功能。
此解決方案可以使用計量來比較雲端平台之間的效能和成本，讓客戶能夠順暢地最佳化雲端平台的使用方式。
部署此案例
傳統的藍綠部署會開發應用程式，並將其部署至兩個不同但完全相同的環境 (藍色和綠色)，以提高可用性並降低風險。 藍色環境通常是正常處理即時流量的生產環境，綠色環境是根據需要進行容錯移轉部署。 通常，CI/CD 管線會在相同雲端平台中自動部署藍色和綠色環境。 將此設定視為主動-被動設定。
在多重雲端解決方案中，會在兩個雲端平台中實作藍綠部署。 在無伺服器案例下，會針對每個雲端平台部署兩組重複的微服務，一個是生產環境，另一個則作為容錯移轉環境。 每個雲端平台中的這種主動-被動設定降低此平台停機的風險，提高其可用性，並實現多重雲端主動-主動高可用性。
藍綠部署的第二個優點是能夠使用每個雲端平台上的容錯移轉部署作為微服務更新的測試環境，然後再將其發佈到生產部署。