開發背景工作的建議

適用于此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：07	藉由實作自我保留和自我修復措施，強化工作負載的復原能力和復原能力。 使用基礎結構式可靠性模式和軟體型設計模式來處理元件失敗和暫時性錯誤，將功能建置到解決方案中。 將功能建置到系統中，以偵測解決方案元件失敗，並在工作負載繼續完整或減少的功能時自動起始更正動作。

相關指南：暫時性錯誤 | 自我保留

本指南說明開發背景工作的建議。 背景工作會自動執行，而不需要使用者互動。 許多應用程式都需要獨立于 UI 執行的背景工作。

背景作業的一些範例包括批次作業、密集處理工作，以及長時間執行的進程，例如工作流程。 應用程式會啟動作業，並處理來自使用者的互動式要求。 例如，如果應用程式需要產生使用者上傳的影像縮圖，則可以執行背景工作來產生縮圖，並將它儲存至儲存體。 使用者不需要等待程式完成。 另一個範例是客戶下訂單，這會起始處理訂單的背景工作流程。 當背景作業執行時，客戶會繼續流覽 Web 應用程式。 背景作業完成後，它會更新預存訂單資料，並將電子郵件傳送給客戶以確認訂單。

背景工作有助於將應用程式 UI 上的負載降到最低，以改善可用性並減少互動式回應時間。

主要設計策略

若要選擇要指定為背景工作的工作，請考慮工作是否在沒有使用者互動的情況下執行，以及 UI 是否需要等候工作完成。 要求使用者或 UI 在執行時等候的工作通常不是適當的背景工作。

背景工作類型

背景作業的一些範例如下：

• 需要大量 CPU 處理的作業，例如數學計算或結構化模型分析。

• 需要大量 I/O 的作業，例如執行一系列儲存體交易或索引檔案。

• 如夜間資料更新或排程處理的批次作業。

• 長時間執行的工作流程，例如訂單履行或布建服務和系統。

• 將工作傳輸到更安全的位置進行處理的敏感資料處理。 例如，您可能不想在 Web 應用程式中處理敏感性資料。 相反的，您可以改用如 閘道管理員的模式將資料傳送到隔離的背景處理序中，且該處理序擁有受保護儲存體的存取權。

觸發程序

使用：

• 事件驅動觸發程式：事件，通常是使用者動作或工作流程中的步驟，會觸發工作。

• 排程驅動觸發程式：以計時器為基礎的排程會叫用工作。 作業可以依週期性或單一執行進行排程。

事件驅動觸發程序

動作會觸發啟動背景工作的事件驅動調用。 事件驅動觸發程式的範例包括：

• UI 或不同的作業會將訊息放在佇列中，如 Web-Queue-Worker 架構樣式中所述。 訊息包含先前執行動作的相關資料，例如下訂單的客戶。 背景工作會監視此佇列，並偵測新訊息的抵達。 它會讀取訊息，並使用訊息的資料作為背景工作的輸入。 此模式稱為 非同步訊息式通訊。

• UI 或不同的作業會儲存或更新儲存體中的值。 背景作業會監視儲存體，並偵測變更。 它會讀取資料，並使用它做為背景工作的輸入。

• UI 或不同的作業會對端點提出要求，例如 HTTPS URI 或公開為 Web 服務的 API。 在要求過程中，UI 或作業會傳輸背景工作所需的資料。 端點或 Web 服務會叫用背景工作，將資料做為其輸入。

其他適用于事件驅動調用的工作範例包括影像處理、工作流程、將資訊傳送至遠端服務、傳送電子郵件訊息，以及在多租使用者應用程式中布建新使用者。

排程驅動觸發程序

計時器會觸發啟動背景工作的排程驅動調用。 排程驅動觸發程式的範例包括：

• 在應用程式本機執行或作為應用程式作業系統一部分的計時器會定期叫用背景工作。

• 在不同的應用程式中執行的計時器，例如 Azure Logic Apps，會定期將要求傳送至 API 或 Web 服務。 API 或 Web 服務會叫用背景工作。

• 個別的進程或應用程式會啟動計時器，以在時間延遲或特定時間叫用背景工作。

其他適合排程驅動調用的工作範例包括批次處理常式 (，例如根據客戶最近的行為更新相關產品清單) 、例行資料處理工作 (例如更新索引或產生累積結果) 、每日報表的資料分析、資料保留清除和資料一致性檢查。

如果您使用必須以單一實例身分執行的排程驅動工作，請檢閱下列考慮：

• 如果執行排程器的計算實例，例如使用 Windows 排程工作的虛擬機器 (VM) 調整，則您正在執行排程器的多個實例。 排程器的多個實例可以啟動工作的多個實例。 如需詳細資訊，請參閱 軟體系統中等冪的意義為何？

• 如果工作執行的時間超過排程器事件之間的期間，排程器可能會在上一個工作執行時啟動工作的另一個實例。

傳回結果

背景工作會以非同步方式在不同的進程中執行，甚至是在不同的位置，從叫用背景作業的 UI 或進程執行。 在理想情況下，背景工作會 引發並忘記 作業。 其執行時間進度不會影響 UI 或呼叫進程，這表示呼叫進程不會等待工作完成。 UI 和呼叫進程無法在工作結束時偵測到。

如果您需要背景工作與呼叫工作通訊以指出進度或完成，則必須實作機制。 一些範例包括：

• 將狀態指標值寫入 UI 或呼叫端工作可存取的儲存體，以監視或檢查此值。 背景工作傳回給呼叫端的其他資料可以放在相同的儲存體中。

• 建立 UI 或呼叫端所監視的回復佇列。 背景工作可以將訊息傳送至指出狀態的佇列。 背景工作傳回給呼叫端的資料可以放在訊息中。 針對Azure 服務匯流排，請使用 ReplyTo 和 CorrelationId 屬性來實作這項功能。

• 從 UI 或呼叫端可以存取來取得狀態資訊的背景工作中，公開 API 或端點。 回應可以包含背景工作傳回給呼叫端的資料。

• 設定背景工作，以透過 API 回呼 UI 或呼叫端，以指出預先定義點或完成時的狀態。 您可以使用在本機引發的事件或發佈和訂閱機制。 要求或事件承載可以包含背景工作傳回給呼叫端的資料。

資料分割背景作業

如果您在現有的計算實例中包含背景工作，請考慮這些變更如何影響計算實例的品質屬性和背景作業。 請考慮這些因素，以決定是否要將工作與現有的計算實例共置，或將它們分成不同的計算實例：

• 可用性：背景工作可能不需要與應用程式其他部分相同的可用性層級，特別是直接涉及使用者互動的 UI 和元件。 背景工作可能會有較高的延遲容錯、重試的連線失敗，以及影響可用性的其他因素，因為作業可以排入佇列。 不過，必須有足夠的容量，以防止備份的要求封鎖佇列並影響整個應用程式。

• 延展性：相較于 UI 和應用程式的互動式部分，背景工作可能會有不同的延展性需求。 您可能需要調整 UI 以符合需求尖峰。 未完成的背景工作可以在較不忙碌的時間執行，而且計算實例較少。

• 復原：如果只裝載背景工作的計算實例失敗，它可能不會嚴重影響整個應用程式。 這些工作的要求可以排入佇列或延後，直到工作可用為止。 如果計算實例或工作可以在適當的間隔內重新開機，它可能會影響應用程式使用者。

• 安全性：相較于 UI 或其他應用程式部分，背景工作可能會有不同的安全性需求或限制。 使用個別的計算實例來指定工作的不同安全性環境。 若要將安全性和隔離最大化，您也可以使用閘道管理員之類的模式來隔離背景計算實例與 UI。

• 效能：針對特別符合工作效能需求的背景工作，選擇計算實例的類型。 如果工作不需要與 UI 相同的處理功能，您可以使用成本較低的計算選項。 或者，如果工作需要更多容量和資源，您可以使用較大的實例。

• 管理性：相較于主要應用程式程式碼或 UI，背景工作可能會有不同的開發和部署節奏。 若要簡化更新和版本控制，請將背景工作部署到個別的計算實例。

• 成本：如果您新增計算實例來執行背景工作，裝載成本會增加。 請仔細考慮更多容量與額外成本之間的取捨。

如需詳細資訊，請參閱 領導者選擇模式 和 競爭取用者模式。

衝突

如果您有多個背景工作的實例，它們可能會競爭資源和服務的存取權，例如資料庫和儲存體。 此平行存取可能會導致資源爭用，這可能會導致服務可用性衝突，並損害儲存體中資料的完整性。 使用封閉式鎖定方法來解決資源爭用。 這種方法可防止工作的競爭實例同時存取服務或損毀資料。

另一個解決衝突的方法是將背景工作定義為單一工作，以便只執行一個實例。 不過，此方法可消除多個實例組態所提供的可靠性和效能優勢。 如果 UI 提供足夠的工作讓一個以上的背景工作忙碌，則特別適用這個缺點。

請確定背景工作可以自動重新開機，而且有足夠的容量來處理需求尖峰。 使用足夠的資源配置計算實例、實作佇列機制，以儲存要求在需求減少時執行，或使用這些技術的組合。

協調

背景工作可能十分複雜，而且需要執行多個工作。 在這些案例中，通常會將工作分成較小的離散步驟或多個取用者可執行檔子工作。 多步驟作業更有效率且更有彈性，因為個別步驟通常可在多個作業中重複使用。 新增、移除或修改步驟順序也很容易。

協調多個工作和步驟可能是一項挑戰，但有三種常見的模式可引導您的解決方案：

• 將工作分解成多個可重複使用的步驟。 可能需要應用程式，才能對它處理的資訊執行不同複雜度的各種工作。 實作這類應用程式的簡單但無彈性方法是以整合型模組的形式執行此處理。 但這種方法可能會降低重構程式碼、優化程式碼的機會，或如果應用程式需要其他位置的相同處理部分，則會重複使用它。 如需詳細資訊，請參閱管道與篩選模式(英文)。

• 管理工作步驟的協調流程。 應用程式可能會執行組成許多步驟的工作，其中有些可能會叫用遠端服務或存取遠端資源。 有時候個別步驟彼此獨立，但它們是由實作工作的應用程式邏輯所協調。 如需詳細資訊，請參閱排程器代理程式監督員模式(英文)。

• 管理失敗之工作步驟的復原。 如果一或多個步驟失敗，應用程式可能需要復原一系列步驟所執行的工作，這一起定義最終一致的作業。 如需詳細資訊，請參閱 補償交易模式。

恢復功能考量

建立復原的背景工作，為應用程式提供可靠的服務。 當您規劃和設計背景工作時，請考慮下列幾點：

• 背景工作需要正常處理重新開機，而不會損毀資料，或在應用程式中引入不一致的情況。 對於長時間執行或多步驟的工作，請考慮使用 檢查點。 使用檢查點將作業的狀態儲存在永續性儲存體中，或儲存為佇列中的訊息。 例如，您可以將狀態資訊儲存在佇列中的訊息中，並以工作進度累加更新此狀態資訊。 工作可以從最後一個已知的檢查點處理，而不是從頭重新開機。

  針對服務匯流排佇列，請針對此目的使用訊息會話。 使用訊息會話時，使用 SetState 和 GetState 方法來儲存和擷取應用程式處理狀態。 如需設計可靠多步驟進程和工作流程的詳細資訊，請參閱 排程器代理程式監督員模式。

• 當您使用佇列與背景工作通訊時，佇列可在應用程式高於一般負載時，作為緩衝區來儲存傳送給工作的要求。 工作可以在較不忙碌的期間趕上 UI，而重新開機不會封鎖 UI。 如需詳細資訊，請參閱 佇列型負載撫平模式。 如果某些工作比其他工作更重要，請考慮實作 優先順序佇列模式 ，以確保這些工作會先執行。

訊息

設定由訊息起始的背景工作，或處理訊息來處理不一致的情況，例如未依序送達的訊息、重複造成錯誤 (有害訊息) ，以及傳遞多次的訊息。 請考量下列建議事項：

• 有時候您需要以特定連續處理訊息，例如根據現有資料值變更資料的訊息，例如將值新增至現有的值。 訊息不一定會依傳送的順序送達。 此外，背景工作的不同實例可能會以不同的連續處理訊息，因為每個實例上的負載不同。

  對於必須以特定連續處理的訊息，請包含序號、索引鍵，或背景工作可用來以正確連續處理訊息的另一個指標。 針對服務匯流排，請使用訊息會話來保證傳遞的正確順序。 設計程式更有效率，因此訊息順序並不重要。 如需詳細資訊，請參閱 訊息排序和時間戳記。

• 一般而言，背景工作會查看佇列中的訊息，以暫時隱藏其他訊息取用者。 工作成功處理訊息之後，它會刪除訊息。 如果背景工作在處理訊息時失敗，該訊息會在查看逾時到期之後重新出現在佇列中。 工作的不同實例會處理訊息，或原始實例的下一個處理週期會處理訊息。

  如果訊息在取用者中持續造成錯誤，它會封鎖工作、佇列，最後當佇列已滿時應用程式本身。 從佇列中偵測和移除有害訊息非常重要。 如果您使用服務匯流排，請自動或手動將有害訊息移至相關聯的 寄不出的信件佇列。

• 佇列至少是 一次 傳遞機制，但可能會多次傳遞相同的訊息。 如果背景工作在處理訊息之後失敗，但在從佇列中刪除訊息之前，訊息就可以再次處理。

  背景工作應該具有等冪性，這表示當工作處理相同訊息多次時，它不會在應用程式的資料中造成錯誤或不一致。 某些作業自然具有等冪性，例如，如果預存值設定為特定的新值。 不過，某些作業會造成不一致的情況，例如，如果值新增至現有的預存值，但未驗證預存值仍然與最初傳送訊息時的值相同。 設定服務匯流排佇列以自動移除重複的訊息。 如需詳細資訊，請參閱 等冪訊息處理。

• 某些傳訊系統，例如 Azure 儲存體佇列和服務匯流排佇列，支援清除佇列計數屬性，指出從佇列讀取訊息的次數。 此資料適用于處理重複的訊息和有害訊息。 如需詳細資訊，請參閱 非同步傳訊入門 和 等冪模式。

調整和效能考量

背景工作必須提供足夠的效能，以確保它們不會在系統負載不足時封鎖應用程式或延遲作業。 一般而言，當您調整裝載背景工作的計算實例時，效能會改善。 當您規劃和設計背景工作時，請考慮下列與延展性和效能相關的重點：

• Azure 虛擬機器和Azure App 服務Web Apps功能可以裝載部署。 它們支援自動調整，包括相應放大和相應縮小。 自動調整取決於需求和負載或預先定義的排程。 使用自動調整來協助確保應用程式具有足夠的效能功能，同時將執行時間成本降至最低。

• 相較于應用程式的其他部分，某些背景工作有不同的效能功能，例如 UI 或元件，例如資料存取層。 在該案例中，將背景工作一起裝載在不同的計算服務中，讓 UI 和背景工作可以獨立調整以管理負載。 如果多個背景工作具有明顯不同的效能功能，請將其分割並獨立調整每個類型。 這項技術可能會增加執行時間成本。

• 若要避免在負載下遺失效能，您可能也需要調整儲存體佇列和其他資源，讓處理鏈結的單一點不會造成瓶頸。 請考慮其他限制，例如儲存體的最大輸送量，以及應用程式和背景工作所依賴的其他服務。

• 設計用於調整的背景工作。 例如，背景工作必須動態偵測已使用儲存體佇列的數目，以監視訊息或將訊息傳送至適當的佇列。

• 根據預設，WebJob 會與其相關聯的Web Apps實例進行調整。 不過，如果您想要讓 WebJob 只以單一實例的形式執行，您可以建立包含 JSON 資料的 { "is_singleton": true } Settings.job 檔案。 這個方法會強制 Azure 只執行一個 WebJob 實例，即使有多個相關聯的 Web 應用程式實例也一樣。 這項技術適用于只能以單一實例身分執行的排程工作。

• 背景工作可能會針對資料同步處理和程式協調建立挑戰，特別是當背景工作彼此相依或其他資料來源時。 例如，背景工作可能會處理資料一致性問題、競爭狀況、死結或逾時。

• 如果背景工作的結果呈現給使用者，背景工作可能會影響使用者體驗。 例如，背景工作可能需要使用者等候通知、重新整理頁面，或手動檢查工作的狀態。 這些行為可能會增加使用者互動的複雜度，並對使用者體驗造成負面影響。

取捨：背景作業會對系統引進更多元件和相依性，這會增加解決方案的複雜度和維護成本。 例如，背景工作可能需要個別的佇列服務、背景工作服務、監視服務和重試機制。

Azure 指導

下列各節說明可用來裝載、執行、設定和管理背景作業的 Azure 服務。

主機環境

有數個 Azure 平臺服務可以裝載背景工作：

• Web Apps和 WebJobs：使用 App Service 的 WebJobs 功能，根據您可以在 Web 應用程式中執行的不同腳本或程式來執行自訂作業。

• Azure Functions：針對長時間未執行的背景工作使用函式應用程式。 如果您在使用量過低App Service方案上裝載工作負載，您也可以使用函式應用程式。

• 虛擬機器：如果您有 Windows 服務或想要使用 Windows 工作排程器，請在專用 VM 中裝載您的背景工作。

• Azure Batch：Batch 是一項平臺服務，可用來排程在受控 VM 集合上執行的計算密集型工作。 ，而且可以自動調整計算資源。

• Azure Kubernetes Service (AKS) ：AKS為 Azure 上的 Kubernetes 提供受控裝載環境。

• Azure Container Apps：使用 Container Apps，您可以建置以容器為基礎的無伺服器微服務。

下列各節提供這些選項的考慮，協助您選擇最適合的選項。

Web Apps 和 WebJobs

您可以使用 WebJobs 功能，在 Web 應用程式中以背景工作的形式執行自訂作業。 WebJob 會在 Web 應用程式的內容中以連續進程的形式執行。 WebJob 也可以執行 以回應 Logic Apps 或外部因素的觸發程式事件，例如儲存體 Blob 或訊息佇列的變更。 WebJobs 可以視需要啟動和停止，並正常關閉。 如果持續執行的 WebJob 失敗，系統會自動重新開機。 您可以設定重試和錯誤動作。

當您設定 Web 工作時︰

• 如果您想要讓作業回應事件驅動觸發程式，請將它設定為 持續執行。 腳本或程式會儲存在名為 site/wwwroot/app_data/jobs/continuous 的資料夾。

• 如果您想要讓作業回應排程驅動觸發程式，請將它設定為 依排程執行。 指令碼或程式會儲存在名為 site/wwwroot/app_data/jobs/triggered 的資料夾中。

• 如果您在設定作業時選擇 [ 隨選 執行] 選項，它會在啟動作業時執行與 [依排程執行 ] 選項相同的程式碼。

WebJob 會在 Web 應用程式的沙箱中執行。 它可以存取環境變數，而且可以與 Web 應用程式共用資訊，例如連接字串。 WebJob 可以存取執行 WebJob 之電腦的唯一識別碼。 名為 AzureWebJobsStorage 的連接字串可讓您存取應用程式資料的儲存體佇列、Blob 和資料表。 它也可讓您存取服務匯流排以進行傳訊和通訊。 名為 AzureWebJobsDashboard 的連接字串可讓您存取 WebJob 動作記錄檔。

WebJobs 具有下列特性：

• 安全性：Web 應用程式的部署認證會提供 WebJobs 的保護。

• 支援的檔案類型：使用命令腳本定義 WebJobs (.cmd) ， 批次檔 (.bat) 、PowerShell 腳本 (.ps1) 、Bash 殼層腳本 (.sh) 、PHP 腳本 (.php) 、Python 腳本 (.py) 、JavaScript 程式碼 (.js) ，以及可執行程式 (.exe 和 .jar) 。

• 部署：您可以使用Azure 入口網站、Visual Studio或WebJobs SDK來部署腳本和可執行檔，也可以將它們直接複製到下列位置：

  • 針對觸發的部署：site/wwwroot/app_data/jobs/triggered/ < job name>

  • 針對持續部署：site/wwwroot/app_data/jobs/continuous/ < job name>

• 記錄檔： Console.Out 會被視為或標示為 INFO 。 Console.Error 會 ERROR 被視為 。 使用入口網站來存取監視和診斷資訊。 直接從網站下載記錄檔。 記錄檔會儲存在下列位置：

  • 針對觸發的部署：Vfs/data/jobs/triggered/ < job name>

  • 針對持續部署：Vfs/data/jobs/continuous/ < job name>

• 設定：使用入口網站、REST API 和 PowerShell 設定 WebJobs。 使用名為 settings.job 的組態檔，其位於與 WebJob 腳本相同的根目錄中，以提供 WebJob 的組態資訊。 例如：

  • { "stopping_wait_time": 60 }

  • { "is_singleton": true }

Web Apps和 WebJobs 考慮

• 根據預設，WebJobs 會跟據 Web 應用程式來調整自己。 若要將 WebJobs 設定為在單一實例上執行，請將組 is_singleton 態屬性設定為 true 。 單一實例 WebJobs 適用于您不想同時調整或執行多個實例的工作，例如重新編制索引或資料分析。

• 若要將 WebJobs 對 Web 應用程式效能的影響降到最低，請在新的App Service計畫中建立空的 Web 應用程式實例，以裝載長時間執行或耗用大量資源的 WebJobs。

Azure Functions

Azure Functions類似于 WebJobs。 Azure Functions是無伺服器，最適合短期執行的事件驅動觸發程式。 如果您將函式設定為在指定時間執行，您也可以使用Azure Functions透過計時器觸發程式執行排程工作。

不建議Azure Functions大型長時間執行的工作，因為函式可能會導致非預期的逾時。 不過，根據您的主控方案，請考慮針對排程驅動觸發程式使用函式。

Azure Functions考慮

如果您預期背景工作會在短時間內執行以回應事件，請考慮在取用計畫中執行工作。 您可以將執行時間設定為最大時間。 執行時間越長的函式，成本越高。 耗用更多記憶體的 CPU 密集作業可能成本更高。 如果您使用服務的額外觸發程式作為工作的一部分，則會個別計費。

如果您有數個簡短但持續執行的工作，則進階方案適合使用。 此方案更貴，因為其需要更多的記憶體和 CPU。 作為優點，您可以使用其他功能，例如虛擬網路整合。

如果您的工作負載已在專用計畫中執行，則專用計畫適用于背景工作。 如果您有使用量過低的 VM，您可以在相同的 VM 上執行專用計畫，並共用計算成本。

如需詳細資訊，請參閱：

• Azure Functions 裝載選項
• Azure Functions 的計時器觸發程序

虛擬機器

您可以實作背景工作，使其不會部署到Web Apps。 例如，您可以使用 Windows 服務、協力廠商公用程式或可執行程式來實作工作。 您也可以使用針對執行時間環境所撰寫的程式，其與裝載應用程式的環境不同。 例如，您可以使用想要從 Windows 或 .NET 應用程式執行的 Unix 或 Linux 程式。 從 Azure VM 的數個作業系統中選擇，然後在該 VM 上執行您的服務或可執行檔。

如需詳細資訊，請參閱：

• 選擇 Azure 計算服務
• Azure 中 VM 的大小
• 虛擬機器 Marketplace

若要在不同的 VM 中起始背景工作，您可以：

• 將要求傳送至工作公開的端點，以便直接從您的應用程式視需要執行工作。 要求會傳輸工作所需的資料。 端點會叫用工作。

• 使用所選作業系統中的排程器或計時器，將工作設定為依排程執行。 例如，在 Windows 上，您可以使用 Windows 工作排程器來執行腳本和工作。 如果您已在 VM 上安裝SQL Server，請使用 SQL Server Agent 來執行腳本和工作。

• 使用 Logic Apps 將訊息新增至工作所監視的佇列，或將要求傳送至工作公開的 API 來起始工作。

如需如何起始背景工作的詳細資訊，請參閱先前 的觸發程式 一節。

虛擬機器考慮

當您在 Azure VM 中部署背景工作時，請考慮下列幾點：

• 在不同的 Azure VM 中裝載背景工作，以提供對初始、部署、排程和資源配置的彈性和精確控制。 不過，如果您只針對背景工作部署 VM，執行時間成本會增加。

• 沒有功能可監視入口網站中的工作，也不會針對失敗的工作自動重新開機功能。 但您可以使用Azure Resource Manager Cmdlet來監視 VM 的狀態並加以管理。 沒有任何功能可控制計算節點中的進程和執行緒。 一般而言，如果您使用 VM，則必須實作機制，以從工作中的檢測收集資料，以及從 VM 中的作業系統收集資料。 您可以使用 System Center 管理元件來進行 此用途。

• 請考慮建立透過 HTTP 端點公開的監視探查。 您可以設定這些探查的程式碼來執行健康情況檢查，並收集作業資訊和統計資料。 您也可以使用探查來定序錯誤資訊，並將其傳回至管理應用程式。

如需詳細資訊，請參閱：

• 健全狀況端點監視模式
• 虛擬機器
• 虛擬機器常見問題集

Batch

如果您需要在數十、數百或數千部 VM 之間執行大型、平行高效能運算， (HPC) 工作負載，請考慮 Batch 。

使用 Batch 來準備 VM、將工作指派給 VM、執行工作、監視進度，以及自動相應放大 VM 以回應工作負載。 Batch 也提供作業排程，並支援 Linux 和 Windows VM。

批次考慮

Batch 適用于內部平行工作負載。 您可以使用 Batch 在結尾執行縮減步驟的平行計算，或針對需要在節點之間傳遞訊息的平行工作執行 訊息傳遞介面 (MPI) 應用程式 。

Batch 作業會在節點集區或 VM 上執行。 您只能在需要時組態集區，然後在作業完成後將其刪除。 此方法會最大化使用率，因為節點未閒置，但作業必須等候您配置節點。 或者，您可以事先建立集區。 這種方法可將作業啟動所花費的時間降到最低，但可能會導致節點閒置。

如需詳細資訊，請參閱：

• Batch 中的節點和集區
• 什麼是 Batch？
• Batch 中的作業和工作
• Azure 上的 HPC
• Batch 服務工作流程和資源

Azure Kubernetes Service

使用 AKS 來管理裝載的 Kubernetes 環境，讓您可以輕鬆地部署和管理容器化應用程式。

容器對於執行背景工作很有用。 以下是一些優勢：

• 容器支援高密度裝載。 您可以在容器中隔離背景工作，同時在每個 VM 中入放多個容器。

• 使用容器協調器來執行內部負載平衡、設定內部網路，以及執行其他設定工作。

• 您可以視需要啟動和停止容器。

• 透過Azure Container Registry，您可以在 Azure 界限內註冊容器，以提供安全性、隱私權和鄰近優勢。

AKS 考慮

AKS 需要瞭解如何使用容器協調器。

如需詳細資訊，請參閱

• Azure 中容器的概觀
• Azure 中的容器登錄簡介

容器應用程式

使用 Container Apps，您可以建置以容器為基礎的無伺服器微服務。 容器應用程式：

• 已針對執行一般用途容器進行優化，特別是跨越容器中部署許多微服務的應用程式。

• 由 Kubernetes 和開放原始碼技術提供，例如 Dapr、 Kubernetes 事件驅動自動調整 (KEDA) 和 Envoy。

• 支援 Kubernetes 樣式的應用程式和微服務，其中包含服務探索和流量分割等功能。

• 藉由支援根據流量和從 佇列等事件來源提取的調整，包括調整為零，以啟用事件驅動應用程式架構。

• 支援長時間執行的進程，並可執行 背景工作。

容器應用程式考慮

容器應用程式不提供基礎 Kubernetes API 的直接存取權。 如果您需要存取 Kubernetes API 和控制平面，請使用 AKS。 如果您想要建置 Kubernetes 樣式的應用程式，而且不需要直接存取原生 Kubernetes API 和叢集管理，請使用 Container Apps 以取得完全受控的體驗。 Container Apps 最適合用來建置容器微服務。

如需詳細資訊，請參閱：

• 容器應用程式概觀
• 快速入門：部署您的第一個容器應用程式

相關連結

• 補償交易模式
• 競爭取用者模式
• 領導者選擇模式
• 管道和篩選模式
• 優先順序佇列模式
• 佇列型負載調節模式
• 排程器代理程式監督員模式

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單