Azure 提供許多計算服務來裝載高可用性應用程式。 服務的功能和複雜性不同。 建議您根據下列項目選擇服務：
- 可靠性、可用性、效能和安全性的非功能性需求。
- 可擴縮性、成本、操作性和複雜性等決策因素。
應用程式裝載平臺的選擇是影響所有其他設計區域的重要決策。 例如，舊版或專屬開發軟體可能不會在 PaaS 服務或容器化應用程式中執行。 這項限制會影響您選擇的計算平臺。
任務關鍵性應用程式可以使用多個計算服務來支援多個複合工作負載和微服務，每個工作負載都有不同的需求。
此設計區域提供與計算選取、設計和組態選項相關的建議。 我們也建議您熟悉計算決策樹。
重要
本文是 Azure 良好架構框架任務關鍵性工作負載系列的一部分。 如果您不熟悉此系列，我們建議您從什麼是使命關鍵工作負載？開始。
平台資源的全球分佈
任務關鍵性工作負載的典型模式包括全域資源和區域資源。
未受限於特定 Azure 區域的 Azure 服務會部署或設定為全域資源。 某些使用案例包括跨多個區域分散流量、儲存整個應用程式的永久狀態，以及快取全域靜態數據。 如果您需要同時容納 規模單元架構 和 全球分佈，請考慮如何以最佳方式將資源分佈或複製到 Azure 區域中。
其他資源會以區域方式部署。 這些資源會作為部署模板的一部分來部署，通常會對應至擴展單位。 不過，區域可以有多個戳記，而且戳記可以有多個單位。 區域資源的可靠性非常重要，因為它們負責執行主要工作負載。
下圖顯示高階設計。 使用者透過中央全域進入點存取應用程式，然後將要求重新導向至適當的區域部署戳記：
顯示任務關鍵架構的圖表。
任務關鍵性設計方法需要多區域部署。 此模型可確保區域容錯，讓應用程式即使在整個區域關閉時仍可供使用。 當您設計多區域應用程式時，請考慮不同的部署策略，例如主動/主動和主動/被動，以及應用程式需求，因為每個方法都有顯著的取捨。 對於任務關鍵性工作負載，我們強烈建議使用中/主動模型。
並非所有工作負載都支援或需要同時執行多個區域。 您應該權衡特定的應用程式需求與取捨，以判斷最佳的設計決策。 對於可靠性較低的特定應用程式案例，主動/被動或分區化可能是適合的替代方案。
可用性區域 可以在區域內不同的數據中心提供高可用性的部署。 幾乎所有的 Azure 服務都可以在區域設定中取得，其中服務會委派給特定區域，或區域備援設定，其中平臺會自動確保服務跨越區域且可承受區域中斷。 這些設定最多可提供數據中心層級的容錯能力。
設計考量
區域與區域能力。 並非所有服務與功能都可在每個 Azure 區域中使用。 此考慮可能會影響您選擇的區域。 此外，並非每個區域都提供可用性區域。
區域配對。 Azure 區域會分組成 區域組， 由單一地理位置中的兩個區域組成。 某些 Azure 服務會使用配對的區域來確保商務持續性，並提供保護層級以防止數據遺失。 例如，Azure 異地備援記憶體 （GRS） 會自動將數據復寫到次要配對區域，確保主要區域無法復原時，數據是持久的。 如果中斷會影響多個 Azure 區域，則每個配對中至少有一個區域會優先進行復原。
數據一致性。 針對一致性挑戰，請考慮使用全球分布式資料存儲、區域蓋章架構，以及部分活躍/主動部署。 在部分部署中，某些元件在所有區域都處於作用中狀態，而其他元件則位於主要區域內。
安全部署。 Azure 安全部署實務（SDP）架構可確保 Azure 平台的所有程式代碼和組態變更（計畫性維護）都經過逐步推出。 在發行期間分析健康情況是否降低。 在 Canary 和試驗階段順利完成之後，平臺更新會跨區域配對串行化，因此每個配對中只有一個區域會在指定時間更新。
平臺容量。 如同任何雲端提供者，Azure 具有有限的資源。 無法使用可能是區域容量限制的結果。 如果發生區域性中斷，當工作負載嘗試在配對區域內復原時，資源需求就會增加。 中斷可能會造成容量問題，其中供應暫時不符合需求。
設計建議
在至少兩個 Azure 區域中部署您的解決方案，以協助防止區域性中斷。 將它部署在具有工作負載所需功能和特性的區域。 這些功能應符合效能和可用性目標，同時滿足數據落地和保留需求。
例如，某些數據合規性需求可能會限制可用區域的數目，並可能迫使設計上的妥協。 在這種情況下，強烈建議您在操作包裝函式中新增額外的投資，以預測、偵測和回應失敗。 假設您受限於具有兩個區域的地理位置，而且只有其中一個區域支援可用性區域（3 + 1 個數據中心模型）。 建立使用故障區域隔離的次要部署模式，允許兩個區域部署在主動配置中，並確保主要區域中有多個部署標記。
如果適當的 Azure 區域未全部提供您需要的功能，請準備好在區域部署戳記的一致性上妥協，以排定地理分佈的優先順序並最大化可靠性。 如果只有單一 Azure 區域適合，請在所選區域中部署多個部署戳記（區域縮放單位），以降低某些風險，並使用可用性區域來提供數據中心層級容錯。 不過，地理分佈中的如此重大妥協，會大幅限制可達到的複合 SLO 和整體可靠性。
重要
針對以大於或等於99.99%之 SLO 為目標的案例，我們建議至少三個部署區域。 計算所有使用者流程的 複合 SLO。 請確定這些目標符合商務目標。
針對具有大量流量的高規模應用程式場景，請設計解決方案，使其能夠跨多個區域擴展，以應對單一區域內可能出現的容量限制。 其他區域部署標記可以達到更高的整體服務水平目標。 如需詳細資訊，請參閱如何 實作多區域目標。
定義並驗證恢復點目標 （RPO） 和復原時間目標 （RTO）。
在單一地理位置內，優先使用區域配對，以受益於SDP串行化推出的計劃性維護和非計劃性維護的區域優先順序。
將 Azure 資源與使用者共置在一起，以將網路等待時間降至最低，並將端對端效能最大化。
- 您也可以使用 內容傳遞網路（CDN）或邊緣快取等解決方案，為分散式使用者基底提供最佳的網路等待時間。 如需詳細資訊，請參閱全域流量路由、應用程式交付服務，以及快取與靜態內容交付。
當您選擇部署區域時，請讓目前的服務可用性與產品藍圖保持一致。 某些服務可能無法立即在每個區域中使用。
容器化
容器包含應用程式程序代碼，以及應用程式需要執行的相關組態檔、連結庫和相依性。 容器化提供應用程式程序代碼及其相依性的抽象層，並建立與基礎裝載平臺的區隔。 單一軟體套件具有高度可移植性，而且可在各種基礎結構平臺和雲端提供者之間一致地執行。 開發人員不需要重寫程式代碼，而且可以更快速且更可靠地部署應用程式。
重要
建議您針對任務關鍵性應用程式套件使用容器。 它們可改善基礎結構使用率，因為您可以在相同的虛擬化基礎結構上裝載多個容器。 此外，因為所有軟體都包含在容器中，因此不論運行時間或連結庫版本為何，您都可以跨各種作業系統移動應用程式。 使用容器管理也比傳統虛擬化裝載更容易。
任務關鍵性應用程式需要快速調整規模，以避免效能瓶頸。 由於容器映像已經預先建置，因此您可以將啟動過程限制在應用程式的引導階段，從而加快擴展速度。
設計考量
監視。 監視服務存取容器中的應用程式可能很困難。 您通常需要第三方軟體來收集和儲存容器狀態指標，例如 CPU 或 RAM 使用量。
安全性。 裝載平臺OS核心會跨多個容器共用，以建立單一攻擊點。 不過，主機虛擬機 （VM） 存取的風險有限，因為容器會與基礎操作系統隔離。
狀態。 雖然可以將數據儲存在執行中容器的文件系統中，但在重新建立容器時，數據將不會保存。 相反地，請掛接外部記憶體或使用外部資料庫來保存數據。
設計建議
將所有應用程式元件容器化。 使用容器映像作為應用程式部署套件的主要模型。
盡可能優先選擇以Linux為基礎的容器執行時環境。 映像檔更輕便，而且針對 Linux 節點或容器的新功能經常被推出。
使用簡短生命週期讓容器不可變且可取代。
請務必從容器、容器主機和基礎叢集收集所有相關記錄和計量。 將收集的記錄和計量傳送至統一的數據接收，以進行進一步的處理和分析。
將容器映像儲存在 Azure 容器登錄中。 使用 地理複寫 在所有區域複寫容器映像檔。 啟用 適用於容器登錄 的 Defender Microsoft，以提供容器映射的弱點掃描。 請確定登錄的存取權是由 Microsoft Entra ID 所管理。
容器管理與編排
數個 Azure 應用程式平臺可以有效地裝載容器。 每個平臺都有相關聯的優點和缺點。 比較商務需求內容中的選項。 不過，一律優化可靠性、延展性和效能。 如需詳細資訊，請參閱下列文章：
- 計算判定樹
- 容器選項比較
重要
Azure Kubernetes Service （AKS） 和 Azure Container Apps 應根據您的需求，成為容器管理的第一個選擇之一。 雖然 Azure App Service 不是一個協調工具，但作為一個低阻力的容器平台，它仍然是 AKS 的可行替代方案。
Azure Kubernetes Service 的設計考慮和建議
AKS 是受控 Kubernetes 服務，可讓您快速布建叢集，而不需要複雜的叢集管理活動，並提供包含進階網路和身分識別功能的功能集。 如需一組完整的建議，請參閱 Azure Well-Architected Framework 檢閱 - AKS。
重要
您不需要重新部署 AKS 叢集，就無法變更一些基本設定決策。 範例包括選擇公有和私有 AKS 叢集、啟用 Azure 網路原則、Microsoft Entra 整合，以及對 AKS 使用受管識別，而非服務主體。
可靠性
AKS 會管理原生 Kubernetes 控制平面。 如果控制平面無法使用，會造成工作負載停機。 利用 AKS 所提供的可靠性功能：
將 AKS 叢集部署至不同 Azure 區域，作為擴展單元，以提高可靠性和可用性至最高。 使用 可用性區域 ，將 AKS 控制平面和代理程式節點分散到實體個別的數據中心，將 Azure 區域內的復原能力最大化。 不過，如果共置延遲是問題，您可以在單一區域內執行 AKS 部署，或使用 鄰近放置群組 將節點間延遲降至最低。
使用生產叢集的 AKS 運行時間 SLA ，將 Kubernetes API 端點可用性保證最大化。
延展性
考慮 AKS 規模限制，如節點數目、每個叢集的節點集區，以及每個訂用帳戶的叢集。
如果擴展限制是一個限制，請利用 擴展單元策略，並透過集群部署更多單元。
啟用 叢集自動調整功能，使其可針對資源限制自動調整代理節點的數量。
使用水準 Pod 自動調整程式，根據 CPU 使用率或其他計量來調整部署中的 Pod 數目。
針對大規模和突發情況，請考慮使用虛擬節點進行廣泛且迅速的擴展。
定義應用程式部署指令清單中的 pod 資源要求和限制。 如果您未這麼做，可能會遇到效能問題。
隔離
維護工作負載和系統工具所使用的基礎結構之間的界限。 共用基礎結構可能會導致高資源使用率和雜訊鄰近案例。
針對系統和工作負載服務使用不同的節點集區。 工作負載元件的專用節點集區應以特殊基礎結構資源的需求為基礎，例如高記憶體 GPU VM。 一般而言，若要減少不必要的管理額外負荷，請避免部署大量的節點集區。
使用 污點和容忍 來提供專用節點，並限制耗用大量資源的應用程式。
評估應用程式親和性和反親和性需求，並在節點上設定適當的容器共置。
安全性
默認狀態下的原生 Kubernetes 需要進行大量配置，以確保在關鍵任務場景中維持適當的安全狀態。 AKS 可解決各種現成的安全性風險。 功能包括私人叢集、稽核和登入Log Analytics、強化的節點映像，以及受控識別。
依據 AKS 安全性基準中提供的設定指引進行設置。
使用 AKS 功能來處理叢集身分識別和存取管理，以減少作業額外負荷，並套用一致的存取管理。
使用受控識別，而不是服務主體，以避免管理和輪替認證。 您可以在叢集層級新增受控身分識別。 在 Pod 層級，您可以透過 Microsoft Entra 工作負載 ID 使用受控身份。
使用 Microsoft Entra 整合來集中管理帳戶和密碼、應用程式存取，以及加強的身分識別保護。 使用 Kubernetes RBAC 搭配 Microsoft Entra ID 以達到<最小權限>，並將授予管理員權限降至最低，以協助保護配置和機密存取。 此外，請使用 Azure 角色型存取控制來限制 Kubernetes 叢集配置檔案的存取。 限制容器可以執行的動作存取、提供最少的權限數目，並避免使用 root 權限提高。
升級
叢集和節點必須定期升級。 AKS 支援 Kubernetes 版本 ，以配合原生 Kubernetes 的版本週期。
訂閱 GitHub 上的公用 AKS 路線圖 和 版本資訊，以隨時掌握即將進行的變更、改善，以及最重要的是 Kubernetes 版本發行和淘汰。
請注意 AKS 所支援的各種更新節點及/或叢集的方法。 這些方法可以是手動或自動化。 您可以使用 計劃性維護 來定義這些作業的維護時段。 每周發行新的影像。 AKS 也支援自動升級通道，方便在有新版本的 Kubernetes 或更新的節點映像可用時自動升級 AKS 叢集。
網路
評估最符合使用案例的網路外掛程式。 判斷您是否需要對 Pod 之間的流量進行細微控制。 Azure 支援 kubenet、
評估網路需求和叢集大小之後，優先使用 Azure CNI。 Azure CNI 可讓您使用 Azure 或 Calico 網路政策來控制叢集內的流量。
監視
您的監視工具應該能夠從正在運行的容器擷取記錄和度量。 您也應該從 Kubernetes 計量 API 收集資訊，以監視執行中資源和工作負載的健康情況。
使用 Azure 監視器和 Application Insights 從 AKS 資源收集計量、記錄和診斷，以進行疑難解答。
啟用並檢閱 Kubernetes 資源記錄。
在 Azure 監視器中設定 Prometheus 指標。 監視器中的容器深入解析提供上線功能、啟用現成的監視功能，以及透過內建 Prometheus 支援啟用更進階的功能。
治理
使用原則，以一致的方式將集中式保護套用至 AKS 叢集。 在訂閱範圍或更高層級套用政策指派，以促進開發小組之間的一致性。
使用 Azure 原則來控制授與 Pod 的功能，以及其運行是否與原則相矛盾。 此存取是透過 Azure Policy Add-on for AKS 所提供的內建政策來定義。
請使用 AKS 的 Azure Policy 進階附加元件 來控制 Pod 功能，例如管理 root 權限，並禁止不符合政策的 Pod。
注意
當您部署至 Azure 登陸區域時，登陸區域的實作應提供 Azure 原則，以協助您確保一致的可靠性和安全性。
Azure App 服務 的設計考慮和建議
針對 Web 和 API 為基礎的工作負載案例，App Service 可以作為 AKS 的可行替代方案。 它提供低摩擦容器平臺，而不需要 Kubernetes 的複雜性。 如需完整的建議，請參閱 App Service 的可靠性考量 和 App Service 的卓越運營。
可靠性
評估 TCP 和 SNAT 埠的使用。 TCP 聯機會用於所有輸出連線。 SNAT 連接埠用於對公用IP位址的輸出連線。 SNAT 埠耗盡是常見的失敗案例。 您應該在使用 Azure 診斷 監視埠時，透過負載測試來預測性地偵測此問題。 如果發生 SNAT 錯誤，您必須增加或擴大工作節點，或實施程式碼最佳實踐，以協助保留及重複使用 SNAT 埠。 您可以使用的編碼作法範例包括連線共用和資源的延遲載入。
TCP 埠耗盡是另一個失敗案例。 當某個工作者的輸出連線的數量總和超過可用容量時，就會發生此情況。 可用的 TCP 連接埠數目取決於背景工作角色的大小。 如需建議，請參閱 TCP 和 SNAT 埠。
延展性
規劃未來的延展性需求和應用程式成長，以便從一開始就套用適當的建議。 如此一來，您就可以避免隨著解決方案成長而發生技術移轉債務。
啟用自動調整，以確保有足夠的資源可支援服務請求。 評估 App Service 上針對高密度主機環境的每個應用程式的調整能力。
請注意，App Service 具有每個 App Service 方案實例的預設、軟性限制。
套用自動調整規則。 如果符合配置檔內的任何規則，App Service 方案會擴展，但只有在符合配置檔內的所有規則時，才會縮減。 使用擴展和縮減規則組合，確保自動調整可以執行擴展和縮減的操作。 瞭解單一配置檔中多個縮放規則的行為模式。
請注意，您可以在 App Service 方案層級啟用個別應用程式調整，以允許應用程式獨立於裝載應用程式的 App Service 方案進行調整。 應用程式會透過盡力而為的方式，均勻地配置給可用的節點。 儘管無法保證均勻分佈，但平台可確保同一應用程式的兩個實例不會被託管在同一個個體上。
監視
監視應用程式行為並取得相關記錄和計量的存取權，以確保您的應用程式如預期般運作。
您可以使用診斷記錄，透過 Azure 事件中樞 將應用層級和平臺層級記錄內嵌至 Log Analytics、Azure 儲存體 或第三方工具。
使用 Application Insights 進行應用程式效能監視可提供應用程式效能的深入解析。
任務關鍵性應用程式必須能夠在發生失敗時自我癒合。 啟用 自動癒合 以自動回收狀況不良的工作者。
您必須使用適當的健康情況檢查來評估所有重要的下游相依性，這有助於確保整體健康情況。 強烈建議您啟用 健康情況檢查 ，以識別沒有回應的工作者。
部署
若要解決每個 App Service 方案中的實例預設限制，請在單一區域中以多個擴展單位部署 App Service 方案。 在可用性區域的配置中部署 App Service 計劃，確保工作節點分佈於區域內的不同區域。 請考慮開啟支援工單，將工作者數量上限增加至您需要應付正常尖峰負載的實例數量的兩倍。
容器註冊表
容器註冊表會裝載部署至 AKS 等容器運行環境的映像檔。 您必須仔細設定任務關鍵性工作負載的容器登錄。 中斷不應該造成提取映像的延遲，尤其是在調整作業期間。 下列考慮和建議著重於 Azure Container Registry，並探索與集中式和同盟部署模型相關聯的取捨。
設計考量
格式。 請考慮使用依賴 Docker 所提供格式和標準的容器登錄來進行推送和提取作業。 這些解決方案相容且大部分可互換。
部署模型。 您可以將容器登錄部署為組織內多個應用程式所使用的集中式服務。 或者，您可以將它部署為特定應用程式工作負載的專用元件。
公共登記冊。 容器映像會儲存在 Docker Hub 或其他存在於 Azure 外部和指定虛擬網路的公用登錄中。 這不一定是問題，但可能會導致與服務可用性、節流和數據外洩相關的各種問題。 在某些應用程式案例中，您需要將公用容器映像複製到私有容器登錄中，以限制輸出流量、增加可用性，或避免潛在的節流。
設計建議
使用專用於應用程式工作負載的容器登錄實例。 除非組織可用性和可靠性需求與應用程式完全一致，否則避免在集中式服務上建立相依性。
在建議的核心架構模式中，容器註冊是長期存在的全域資源。 請考慮針對每個環境使用單一全域容器登錄。 例如，使用全域生產登錄。
請確定公用登錄的 SLA 符合您的可靠性和安全性目標。 請特別注意相依於 Docker Hub 的使用案例節流限制。
優先選擇 Azure Container Registry 來裝載容器映像。
Azure Container Registry 的設計考慮和建議
此原生服務提供一系列功能，包括異地複寫、Microsoft Entra 驗證、自動化容器建置，以及透過 Container Registry 工作修補。
可靠性
設定所有部署區域的異地複寫，以移除區域相依性並優化延遲。 Container Registry 透過異地複寫至多個已設定的區域以支援高可用性，提供針對區域中斷的復原能力。 如果某個區域無法使用，其他區域將繼續處理圖片請求。 當區域重新上線時，Container Registry 會復原並復寫其變更。 這項功能也會在每個設定的區域內提供登錄共置，以減少網路延遲和跨區域資料傳輸成本。
在提供可用性區域支援的 Azure 區域中， Premium 容器登錄層支援區域冗餘 ，以防止區域故障。 進階層也支援 私人端點 ，協助防止未經授權的登錄存取，這可能會導致可靠性問題。
將映像檔託管於與其取用計算資源相鄰的同一個 Azure 區域內。
影像鎖定
影像可能會因為手動錯誤而刪除。 Container Registry 支援鎖定映像版本或儲存庫，以防止變更或刪除。 當先前部署的映像 版本 就地變更時，相同版本部署可能會在變更前後提供不同的結果。
如果您想要保護 Container Registry 實例免於刪除，請使用 資源鎖。
標記的影像
標記的 Container Registry 映像預設為可變動，這表示相同的標記可以在推送至登錄的多個映射上使用。 在生產案例中，這可能會導致可能影響應用程式運作時間的無法預期行為。
身分識別和存取管理
使用 Microsoft Entra 整合式驗證來推送和提取映像，而不是依賴存取金鑰。 為了增強安全性，請完全停用使用系統管理員存取密鑰。
無伺服器計算
無伺服器運算會視需要提供資源，並不需要管理基礎結構。 雲端提供者會自動布建、調整及管理執行已部署應用程式程式代碼所需的資源。 Azure 提供數個無伺服器計算平臺：
Azure Functions。 當您使用 Azure Functions 時，應用程式邏輯會實作為獨立的程式碼區塊，或稱為函式，以回應 HTTP 要求或佇列訊息等事件。 每個函式會視需要進行調整以符合需求。
Azure Logic Apps。 Logic Apps 最適合用來建立和執行自動化工作流程，以整合各種應用程式、數據源、服務和系統。 和 Azure Functions 一樣，Logic Apps（邏輯應用）會使用內建觸發來進行事件驅動處理。 不過，您可以使用支援條件和迴圈等程式碼區塊的圖形使用者介面來建立邏輯應用程式，而不是部署應用程式程序代碼。
Azure API 管理。 您可以使用 API 管理，使用取用層來發佈、轉換、維護及監視增強式安全性 API。
Power Apps 和 Power Automate。 這些工具提供低程式碼或無程式碼開發體驗，具有簡單的工作流程邏輯和整合，可透過使用者介面中的聯機進行設定。
對於任務關鍵性應用程式，無伺服器技術提供簡化的開發與作業，這對簡單的商務使用案例而言相當重要。 不過，這種簡單性代價是延展性、可靠性和效能方面的彈性，對於大多數任務關鍵性應用程式案例而言，這並不可行。
下列各節提供使用 Azure Functions 和 Logic Apps 作為非關鍵工作流程案例替代平臺的設計考慮和建議。
Azure Functions 的設計考慮和建議
關鍵任務工作負載包含關鍵和非關鍵的運作流程。 Azure Functions 是流程的可行選擇，這些流程與重要系統流程沒有相同的嚴格商務需求。 它非常適合事件驅動流程，尤其是那些短暫運行的過程，因為函式能夠執行不同作業並以最快速度完成。
選擇適合應用程式可靠性層級的 Azure Functions 裝載選項。 建議您使用 Premium 方案，因為它可讓您設定計算實例大小。 專用方案是最不無伺服器的選項。 它提供自動調整，但這些調整作業的速度比其他方案慢。 我們建議您使用進階方案，將可靠性和效能最大化。
有一些安全性考慮。 當您使用 HTTP 觸發程式來公開外部端點時，請使用 Web 應用程式防火牆 （WAF） 為 HTTP 端點提供來自常見外部攻擊媒介的保護層級。
我們建議使用私人端點來限制私人虛擬網路的存取。 它們也可以降低數據外泄風險，例如惡意系統管理員案例。
您必須在 Azure Functions 程式代碼上使用程式代碼掃描工具，並將這些工具與 CI/CD 管線整合。
Azure Logic Apps 的設計考慮和建議
和 Azure Functions 一樣，Logic Apps（邏輯應用）會使用內建觸發來進行事件驅動處理。 不過，您可以使用支援條件、迴圈和其他建構等區塊的圖形使用者介面來建立邏輯應用程式，而不是部署應用程式程序代碼。
有多種部署模式可供使用。 我們建議使用標準模式，以確保單一租使用者部署並減輕吵雜的鄰近案例。 此模式會使用以 Azure Functions 為基礎的容器化單一租使用者 Logic Apps 執行環境。 在此模式中，邏輯應用程式可以有多個具狀態和無狀態工作流程。 您應該注意組態限制。
透過 IaaS 受限的遷移
許多具有現有內部部署部署的應用程式會使用虛擬化技術和備援硬體來提供關鍵性可靠性層級。 現代化通常會因商業限制而無法完全符合建議用於關鍵任務工作負載的雲端原生基準（North Star）架構模式。 這就是為什麼許多應用程式採用階段式方法，使用虛擬化和 Azure 虛擬機器 作為主要應用程式裝載模型的初始雲端部署。 在某些情況下，可能需要使用基礎結構即服務 （IaaS） VM：
- 可用的 PaaS 服務不提供所需的效能或控制層級。
- 工作負載需要作業系統存取、特定驅動程式或網路和系統設定。
- 工作負載不支援在容器中執行。
- 廠商不支援第三方工作負載。
本節著重於使用 虛擬機器 和相關聯服務的最佳方法，以最大化應用程式平臺的可靠性。 它強調適用於任務關鍵設計方法論的關鍵層面，該方法論涵蓋了雲端原生和 IaaS 移轉案例。
設計考量
使用 IaaS VM 的營運成本明顯高於使用 PaaS 服務的成本，因為 VM 和作業系統的管理需求。 管理 VM 需要頻繁推出軟體套件和更新。
Azure 提供增加 VM 可用性的功能：
- 可用性區域 可透過將 VM 分散到區域內實體分隔的數據中心，協助您達到更高的可靠性層級。
- Azure 虛擬機擴展集 提供功能，可自動調整群組中的 VM 數目。 它們也提供監測實例健康狀況的功能，並自動修復狀況不良的實例。
- 具有彈性協調的規模設定可以藉由自動將虛擬機器分散到容錯網域，有助於防範網路、磁碟和電力中斷。
設計建議
重要
盡可能使用 PaaS 服務和容器來降低作業複雜度和成本。 只有在您需要時才使用 IaaS VM。
確定 VM SKU 大小的合適尺寸，以確保有效的資源使用率。
跨 可用性區域 部署三個或更多的虛擬機器，以達到資料中心層級的容錯能力。
- 如果您要部署現成的商業軟體，請先洽詢軟體廠商，並在將軟體部署至生產環境之前充分進行測試。
對於無法部署在可用性區域的工作負載，請使用包含三台或更多 VM 的彈性虛擬機器規模設定組。 如需有關如何設定容錯網域數目的詳細資訊，請參閱 管理虛擬機器規模設置中的容錯網域。
優先使用 虛擬機器規模集 用於延展性和區域冗餘。 對於具有不同負載的工作負載而言，這一點特別重要。 例如，如果活躍用戶或每秒請求的數量是可變負載。
請勿直接存取個別 VM。 盡可能在前面使用負載平衡器。
若要防止區域性中斷，請跨多個 Azure 區域部署應用程式 VM。
對於不支援多區域主動/主動部署的工作負載，請考慮使用熱/暖備援 VM 來實作主動/被動部署，以進行區域故障轉移。
使用來自 Azure Marketplace 的標準映像，而不是需要維護的自定義映像。
實作自動化程式，以部署和推出 VM 的變更，避免任何手動介入。 如需詳細資訊，請參閱作業程序設計區域中的IaaS 考慮。
實作混亂實驗，將應用程式錯誤插入 VM 元件，並觀察錯誤的風險降低。 如需詳細資訊，請參閱 持續驗證和測試。
監視 VM，並確保診斷記錄和度量已匯入至統一的數據接收器。
在適用的情況下，實施關鍵性任務應用程式場景的安全性作法，以及 Azure 中 IaaS 工作負載的安全性最佳實踐。
後續步驟
檢視關於數據平台的考量事項。