準備
您將新增自己的增強功能至符合組織高可用性需求的現有架構。 在這裡，我們將討論透過練習取得成功所需的背景內容。
問題內容
Contoso Shoes 必須準備好推出下一個高調產品，這預期會大大增加流量。 在過去兩年內，有數個事件導致網站離線長達半天。 該系統並未完全在開發/測試環境中進行測試，有些錯誤問題會進入生產環境。 疑難排解和補救需要很長的時間，因為操作員無法快速識別根本原因。
當某些元件無法使用時，便會有些挑戰。 當 Azure Key Vault 設定錯誤時，計算上的向外擴張作業便會受到影響。 此外，針對區域性停電也沒有任何應對策略。 在最近的事件中，整個西歐區域都停電了。 因為工作負載只在該區域中執行，所以公司必須承受財務損失，直到區域再度恢復電力為止。
目前架構
若要完成這項挑戰，您必須充分了解 Contoso Shoe 目前的架構。 讓我們專注於其 API 層。
元件
此架構的所有元件皆部署到單一區域。
Azure App 服務方案 標準 S2 SKU 提供託管應用程式的計算平台。 已啟用自動調整。 開發環境會使用基本 B1 SKU。
Azure App 服務 提供在容器中執行 API 程式碼的應用程式平臺。 App Service 驗證功能已啟用授權。
部署位置 可讓您您執行部署，並將之與生產部署交換。 它們僅用於生產環境。
Azure Container Registry 會儲存容器化的 API 程式碼，並透過工作負載小組所建立及管理的持續整合/持續傳遞 (CI/CD) 管線推送。 生產環境與開發/測試環境皆會使用容器登錄。
Azure Cosmos DB 與 SQL API 會儲存與工作負載相關的所有狀態。 Cosmos DB 資料庫帳戶具有單一資料庫，其中包含共用輸送量模型中的一些容器。 Azure Cosmos 帳戶會使用無伺服器產能模式。 生產環境有一個實例，開發/測試也有一個。
Azure Key Vault 會儲存 API 對外部、協力廠商 API 進行 HTTP POST 呼叫所需的秘密，做為要求流程的一部分。 應用程式會透過 Azure App 服務應用程式設定中的金鑰保存庫參考來存取秘密。 生產環境有一個金鑰保存庫，開發/測試也有一個。
Azure Log Analytics 用作統一接收器，用於儲存解決方案中使用的所有元件之所有 Azure 診斷設定的記錄和指標。 生產環境有一個工作區，開發/測試也有一個。
Azure Application Insights 用於從 API 擷取遙測和記錄。 Application Insights 使用獨立模式，而非寫入專用的記錄分析工作區。 生產與開發/測試不會共用通用實例。
Azure Pipelines 用於 CI/CD，可建置、測試及部署生產前和生產環境中的工作負載。 工作負載小組會管理管線，也會管理其解決方案中的所有基礎結構。 Bicep 是基礎結構即程式碼 (IaC) 的技術選擇。
設計選擇
在元件清單中，部署戳記是由參與處理要求的服務所組成。 這些服務包括 App Services 和 API 程式碼和 Cosmos DB。 戳記也包含非功能元件：Key Vault 和 Container Registry。 應用程式對效能和復原架構具有協力廠商相依性。 系統管理的識別會在戳記的元件之間使用。
在戳記中，App Services 會設定為根據負載自動調整。
個別的環境會用於生產與開發/測試。 生產環境會使用 App Service 方案的標準 SKU。 公司做出這個選擇，以便能夠在將應用程式部署至生產環境之前，將應用程式預先設定為位置的功能。 開發/測試環境會使用基本 SKU 進行成本最佳化。 這兩個環境都有自己的服務實例。 環境只會共用 Container Registry。
容器化的 API 程式碼會在單一容器映射中傳遞，該映射會在 App Service 中執行。 API 具有各種前端用於讀取及寫入的多個 HTTP 端點。 前端並不在此課程模組的範圍中，但在這種情況的任務關鍵性狀態的整體範圍中。 程式碼已使用 Application Insights 進行檢測，以擷取一些基本遙測。 開發此程式碼的小組也會管理 API 容器映射和 CI/CD 管線的 CI/CD 管線。
取捨
不過，如同所有項目，目前架構也會有取捨。 商務需求優先于可靠性和作業的成本優化。 為維持在成本限制內，架構尚未演進。 利用平台所提供的可靠性功能時，元件就會不足。 例如，選擇計算的 SKU 可防止工作負載使用可用性區域。 對於遙測，會使用舊版的 Application Insights，但未與 Log Analytics 整合。
此外，工作負載的存取權過於普遍。 例如，如果沒有任何虛擬網路整合，所有 Azure 服務都可以透過公用網際網路直接連線。
開發解決方案時，應用程式開發小組使用單一 Azure 訂用帳戶，並在同一個訂用帳戶中共置開發/測試和生產環境，讓 DevOps 小組輕鬆使用工具。 但是，生產資源和開發/測試資源不會完全隔離。 這兩個環境之間會共用一些資源，但其確實會從 Contoso Shoes 解決方案的其餘部分取得隔離的訂用帳戶。
此外，開發/測試環境是開發與 QA 小組所有成員共用的單一環境。 選擇合理，因為小組的大小，而且兩者之間的協調不需要更高程度的隔離。 隨著小組和解決方案演進，單一開發/測試環境逐漸造成整合複雜度，因為工作流程生命週期會發生衝突。 變換及其對可靠性的影響成本很高。
專案規格
該公司想要將功能新增至其解決方案架構，以便能夠處理預期的負載增加。 以下是商務需求:
- 藉由將架構延伸至多個區域，建置可承受區域故障的功能
- 在地理位置更接近客戶的區域中，更快速地為客戶提供服務，進而改善客戶體驗
- 與 Azure 藍圖對齊，並利用 Azure 服務所提供的最新可靠性功能
- 透過建置整體健康情況模型，提早攔截問題並偵測系統中的串聯影響
這些需求只是其改進計畫的優先順序清單。 應用程式小組注意到，必須考慮所有設計區域，才能讓此解決方案的可靠性符合任務關鍵性標準。 請放心，在您協助他們處理即將推出的練習中涵蓋的各個層面之後，他們不會停止改善其解決方案和作業。
歡迎加入小組! Contoso Shoes 希望聽到您的建議。
設定
在此 [挑戰專案] 中，您將擔任架構設計人員的角色，以協助 Contoso Shoes 獲得其可靠性結果，並從上一節的優先項目開始。
- 建議您使用架構圖表工具來視覺化架構。
- 如果您熟悉服務及其功能，則不需要 Azure 訂閱來進行這項挑戰。