Azure 上任務關鍵性工作負載的應用程式平台考慮
Azure 提供許多計算服務來裝載高可用性應用程式。 服務的功能和複雜性不同。 建議您根據下列項目選擇服務：
- 可靠性、可用性、效能和安全性的非功能性需求。
- 可擴縮性、成本、操作性和複雜性等決策因素。
應用程式裝載平臺的選擇是影響所有其他設計區域的重要決策。 例如，舊版或專屬開發軟體可能不會在 PaaS 服務或容器化應用程式中執行。 這項限制會影響您選擇的計算平臺。
任務關鍵性應用程式可以使用多個計算服務來支援多個複合工作負載和微服務，每個工作負載都有不同的需求。
此設計區域提供與計算選取、設計和組態選項相關的建議。 我們也建議您 熟悉計算判定樹。
平台資源的全域散發
任務關鍵性工作負載的典型模式包括全域資源和區域資源。
未受限於特定 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 。 請確定這些目標符合商務目標。
針對具有大量流量的高規模應用程式案例，請設計解決方案以跨多個區域進行調整，以在單一區域內瀏覽潛在的容量限制。 其他區域部署戳記可以達到更高的複合 SLO。 如需詳細資訊，請參閱如何 實作多區域目標。
定義並驗證恢復點目標 （RPO） 和復原時間目標 （RTO）。
在單一地理位置內，優先使用區域配對，以受益於SDP串行化推出的計劃性維護和非計劃性維護的區域優先順序。
將 Azure 資源與使用者共置在一起，以將網路等待時間降至最低，並將端對端效能最大化。
當您選擇部署區域時，請讓目前的服務可用性與產品藍圖保持一致。 某些服務可能無法立即在每個區域中使用。
容器化
容器包含應用程式程序代碼，以及應用程式需要執行的相關組態檔、連結庫和相依性。 容器化提供應用程式程序代碼及其相依性的抽象層，並建立與基礎裝載平臺的區隔。 單一軟體套件具有高度可移植性，而且可在各種基礎結構平臺和雲端提供者之間一致地執行。 開發人員不需要重寫程式代碼，而且可以更快速且更可靠地部署應用程式。
重要
建議您針對任務關鍵性應用程式套件使用容器。 它們可改善基礎結構使用率，因為您可以在相同的虛擬化基礎結構上裝載多個容器。 此外，因為所有軟體都包含在容器中，因此不論運行時間或連結庫版本為何，您都可以跨各種作業系統移動應用程式。 使用容器管理也比傳統虛擬化裝載更容易。
任務關鍵性應用程式需要快速調整規模，以避免效能瓶頸。 因為容器映像是預先建置的，因此您只能在應用程式的啟動載入期間限制啟動，以提供快速的延展性。
設計考量
監視。 監視服務存取容器中的應用程式可能很困難。 您通常需要第三方軟體來收集和儲存容器狀態指標，例如 CPU 或 RAM 使用量。
安全性。 裝載平臺OS核心會跨多個容器共用，以建立單一攻擊點。 不過，主機虛擬機 （VM） 存取的風險有限，因為容器會與基礎操作系統隔離。
狀態。 雖然可以將數據儲存在執行中容器的文件系統中，但在重新建立容器時，數據將不會保存。 相反地，請掛接外部記憶體或使用外部資料庫來保存數據。
設計建議
將所有應用程式元件容器化。 使用容器映像作為應用程式部署套件的主要模型。
盡可能優先處理以Linux為基礎的容器運行時間。 映射更輕量，Linux節點/容器的新功能會經常發行。
使用簡短生命週期讓容器不可變且可取代。
請務必從容器、容器主機和基礎叢集收集所有相關記錄和計量。 將收集的記錄和計量傳送至統一的數據接收，以進行進一步的處理和分析。
將容器映像儲存在 Azure Container Registry 中。 使用 異地復 寫跨所有區域複寫容器映像。 啟用 適用於容器登錄 的 Defender Microsoft，以提供容器映射的弱點掃描。 請確定登錄的存取權是由 Microsoft Entra ID 所管理。
容器裝載和協調流程
數個 Azure 應用程式平臺可以有效地裝載容器。 每個平臺都有相關聯的優點和缺點。 比較商務需求內容中的選項。 不過，一律優化可靠性、延展性和效能。 如需詳細資訊，請參閱下列文章：
重要
Azure Kubernetes Service （AKS） 和 Azure Container Apps 應根據您的需求，成為容器管理的第一個選擇之一。 雖然 Azure App 服務 不是協調器，但作為低摩擦容器平臺，它仍然是 AKS 的可行替代方案。
Azure Kubernetes Service 的設計考慮和建議
AKS 是受控 Kubernetes 服務，可讓您快速布建叢集，而不需要複雜的叢集管理活動，並提供包含進階網路和身分識別功能的功能集。 如需一組完整的建議，請參閱 Azure 架構良好的架構檢閱 - 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。 一般而言，若要減少不必要的管理額外負荷，請避免部署大量的節點集區。
使用 污點和容忍 來提供專用節點，並限制耗用大量資源的應用程式。
評估應用程式親和性和反親和性需求，並在節點上設定適當的容器共置。
安全性
默認 vanilla Kubernetes 需要大量設定，以確保適合任務關鍵性案例的安全性狀態。 AKS 可解決各種現成的安全性風險。 功能包括私人叢集、稽核和登入Log Analytics、強化的節點映像，以及受控識別。
套用 AKS 安全性基準中提供的設定指引。
使用 AKS 功能來處理叢集身分識別和存取管理，以減少作業額外負荷，並套用一致的存取管理。
使用受控識別，而不是服務主體，以避免管理和輪替認證。 您可以在叢集層級新增 受控識別 。 在 Pod 層級，您可以透過 Microsoft Entra 工作負載 ID 使用受控識別。
使用 Microsoft Entra 整合 進行集中式帳戶管理和密碼、應用程式存取管理，以及增強的身分識別保護。 使用 Kubernetes RBAC 搭配 Microsoft Entra ID 以 取得最低許可權，並將授與系統管理員許可權降至最低，以協助保護設定和秘密存取。 此外，使用 Azure 角色型存取控制來限制 Kubernetes 叢集組態檔的存取。 限制容器可執行的動作存取、提供最少的許可權數目，並避免使用根許可權提升。
升級
叢集和節點必須定期升級。 AKS 支援 Kubernetes 版本 ，以配合原生 Kubernetes 的版本週期。
訂閱 GitHub 上的公用 AKS 藍圖 和 版本資訊 ，以隨時掌握即將進行的變更、改善，以及最重要的是 Kubernetes 版本版本發行和淘汰。
套用 AKS 檢查清單中提供的指引，以確保與最佳做法一致。
請注意 AKS 針對 更新節點和/或叢集所支援的各種方法。 這些方法可以是手動或自動化。 您可以使用 計劃性維護 來定義這些作業的維護時段。 每周發行新的影像。 AKS 也支援 自動升級通道 ，以便在有 AKS 叢集可用時自動將 AKS 叢集升級至較新版本的 Kubernetes 和/或更新節點映像。
網路
評估最符合使用案例的網路外掛程式。 判斷您是否需要對 Pod 之間的流量進行細微控制。 Azure 支援 kubenet， Azure CNI，並將您自己的 CNI 用於特定使用案例。
評估網路需求和叢集大小之後，優先使用 Azure CNI。 Azure CNI 可讓您使用 Azure 或 Calico 網路原則來控制叢集內的流量。
監視
您的監視工具應該能夠從執行中的Pod擷取記錄和計量。 您也應該從 Kubernetes 計量 API 收集資訊，以監視執行中資源和工作負載的健康情況。
使用 Azure 監視器和 Application Insights 從 AKS 資源收集計量、記錄和診斷，以進行疑難解答。
啟用並檢閱 Kubernetes 資源記錄。
在 Azure 監視器中設定 Prometheus 計量 。 監視器中的容器深入解析提供上線功能、啟用現成的監視功能，以及透過內建 Prometheus 支援啟用更進階的功能。
治理
使用原則，以一致的方式將集中式保護套用至 AKS 叢集。 在訂用帳戶範圍或更高層級套用原則指派，以推動開發小組之間的一致性。
使用 Azure 原則 來控制授與 Pod 的函式，以及是否執行與原則相矛盾。 此存取是透過 AKS Azure 原則 附加元件所提供的內建原則來定義。
使用 AKS 的 Azure 原則 附加元件來控制 Pod 函式，例如根許可權，以及不允許不符合原則的 Pod。
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方案，以確保背景工作節點分散到區域內的區域。 請考慮開啟支援票證，將背景工作角色數目上限增加為您需要提供正常尖峰負載的兩倍實例計數。
Container Registry：
容器登錄會裝載部署至 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 區域中， 進階容器登錄層支援區域備 援，以提供防止區域性失敗的保護。 進階層也支援 私人端點 ，協助防止未經授權的登錄存取，這可能會導致可靠性問題。
在相同的 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 數目。 它們也提供監視實例健康情況的功能，並自動修復 狀況不良的實例。
- 具有彈性協調流程 的擴展集可藉由自動將 VM 分散到容錯網域，協助防範網路、磁碟和電源失敗。
設計建議
重要
盡可能使用 PaaS 服務和容器來降低作業複雜度和成本。 只有在您需要時才使用 IaaS VM。
調整 VM SKU 大小， 以確保有效的資源使用率。
跨 可用性區域 部署三或多個 VM，以達到資料中心層級容錯。
- 如果您要部署現成的商業軟體，請先洽詢軟體廠商，並在將軟體部署至生產環境之前充分進行測試。
對於您無法跨可用性區域部署的工作負載，請使用 包含三或多個 VM 的彈性虛擬機擴展集 。 如需如何設定正確容錯網域數目的詳細資訊，請參閱 管理擴展集中的容錯網域。
優先使用 虛擬機器擴展集 進行延展性和區域備援。 對於具有不同負載的工作負載而言，這一點特別重要。 例如，如果作用中使用者或每秒要求的數目是不同的負載。
請勿直接存取個別 VM。 盡可能在前面使用負載平衡器。
若要防止區域性中斷，請跨多個 Azure 區域部署應用程式 VM。
對於不支援多區域主動/主動部署的工作負載，請考慮使用經常性/暖待命 VM 進行區域故障轉移，以實作主動/被動部署。
使用來自 Azure Marketplace 的標準映像，而不是需要維護的自定義映像。
實作自動化程式，以部署和推出 VM 的變更，避免任何手動介入。 如需詳細資訊，請參閱作業程序設計區域中的 IaaS 考慮。
實作混亂實驗，將應用程式錯誤插入 VM 元件，並觀察錯誤的風險降低。 如需詳細資訊，請參閱 持續驗證和測試。
監視 VM，並確保診斷記錄和計量已內嵌至統一 的數據接收器。
在適用時實作任務關鍵性應用程式案例的安全性作法，以及 Azure 中 IaaS 工作負載的安全性最佳做法。
後續步驟
檢閱數據平台的考慮。