背景工作

許多類型的應用程式需要執行與使用者介面 (UI) 無關的背景工作。 範例包括批次作業、大量處理的工作，以及長時間執行的處理序，例如工作流程。 背景作業可以在不需要和使用者互動的情形下執行。應用程式可以啟動此作業，然後繼續處理使用者的互動式要求。 這有助於減少應用程式 UI 的負載，如此可以改善可用性，並降低互動式回應時間。

例如，如果應用程式需要產生使用者所上傳影像的縮圖，它可以做為背景工作，並在完成時將縮圖儲存至記憶體，而不需要使用者等待程式完成。 同樣地，下訂單的使用者可以起始處理訂單的背景工作流程，而UI可讓使用者繼續流覽Web應用程式。 當背景工作完成時，它可以更新預存訂單數據，並將電子郵件傳送給確認訂單的使用者。

當您考慮是否實作工作做為背景工作時，主要準則是工作是否可以在沒有使用者互動的情況下執行，而不需要UI等待工作完成。 要求使用者或 UI 在完成時等候的工作可能不適合做為背景工作。

背景作業的類型

背景工作通常包含下列一或多個作業類型：

• 需要大量CPU的工作，例如數學計算或結構模型分析。
• I/O 密集作業，例如執行一系列記憶體交易或編製索引檔案。
• 批次作業，例如夜間數據更新或排程處理。
• 長時間執行的工作流程，例如訂單履行或布建服務和系統。
• 將工作移交給更安全的位置進行處理的敏感數據處理。 例如，您可能不想在 Web 應用程式中處理敏感數據。 相反地，您可以使用閘道守衛模式之類的模式，將數據傳輸到具有受保護記憶體存取權的隔離背景進程。

觸發程序

背景工作可以透過數種不同的方式起始。 它們分為下列其中一個類別：

• 事件驅動觸發程式。 工作會開始回應事件，通常是使用者或工作流程中的步驟所採取的動作。
• 排程驅動觸發程式。 工作會根據定時器依排程叫用。 這可能是週期性排程或稍後指定的一次性調用。

事件驅動觸發程式

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

• UI 或其他作業會將訊息放在佇列中。 訊息包含已執行的動作相關數據，例如使用者下訂單。 背景工作會接聽此佇列，並偵測新訊息的抵達。 它會讀取訊息，並使用其中的數據做為背景作業的輸入。 此模式稱為 異步訊息式通訊。
• UI 或其他作業會儲存或更新記憶體中的值。 背景工作會監視記憶體並偵測變更。 它會讀取數據，並將其作為背景作業的輸入。
• UI 或其他作業會對端點提出要求，例如 HTTPS URI，或公開為 Web 服務的 API。 它會在要求中傳遞完成背景工作所需的數據。 端點或 Web 服務會叫用背景工作，其會使用數據做為其輸入。

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

排程驅動觸發程式

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

• 在應用程式內或在應用程式作業系統中本機執行的定時器會定期叫用背景工作。
• 在不同的應用程式中執行的定時器，例如 Azure Logic Apps，會定期將要求傳送至 API 或 Web 服務。 API 或 Web 服務會叫用背景工作。
• 個別進程或應用程式會啟動定時器，讓背景工作在指定的時間延遲之後或特定時間叫用一次。

適用於排程驅動調用的工作典型範例包括批處理例程（例如根據使用者最近的行為更新相關產品清單）、例行數據處理工作（例如更新索引或產生累積結果）、每日報表的數據分析、數據保留清除和數據一致性檢查。

如果您使用必須以單一實例身分執行的排程驅動工作，請注意下列事項：

• 如果正在執行排程器的計算實例（例如使用 Windows 排程工作的虛擬機器）進行調整，您將會有多個執行排程器的實例。 這些可能會啟動工作的多個實例。 如需詳細資訊，請閱讀此 部落格文章，以瞭解等冪性。
• 如果工作執行的時間超過排程器事件之間的期間，排程器可能會啟動工作的另一個實例，而前一個實例仍在執行中。

傳回結果

背景工作會以異步方式在個別進程中執行，甚至在不同的位置，從叫用背景工作的UI或進程執行。 在理想情況下，背景工作是「引發和忘記」作業，而且其執行進度不會影響UI或呼叫程式。 這表示呼叫進程不會等候工作完成。 因此，它無法自動偵測工作何時結束。

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

• 將狀態指標值寫入UI或呼叫端工作可存取的記憶體，以視需要監視或檢查此值。 背景工作必須返回呼叫端的其他數據可以放在相同的記憶體中。
• 建立 UI 或呼叫端接聽的回復佇列。 背景工作可以將訊息傳送至指出狀態和完成的佇列。 背景工作必須傳回給呼叫端的數據可以放入訊息中。 如果您使用 Azure 服務匯流排，您可以使用 ReplyTo 和 CorrelationId 屬性來實作這項功能。
• 從UI或呼叫端可以存取的背景工作公開 API 或端點，以取得狀態資訊。 背景工作必須傳回給呼叫端的數據可以包含在回應中。
• 讓背景工作透過 API 回呼 UI 或呼叫端，以指出預先定義點或完成時的狀態。 這可能是透過本機引發的事件，或透過發行和訂閱機制引發。 背景工作必須傳回給呼叫端的數據可以包含在要求或事件承載中。

主控環境

您可以使用各種不同的 Azure 平台服務來裝載背景工作：

• Azure Web Apps 和 WebJobs。 您可以使用 WebJobs，根據 Web 應用程式內容中的各種不同類型的腳本或可執行程式來執行自定義作業。
• Azure Functions。 您可以針對長時間執行的背景工作使用函式。 另一個使用案例是，如果您的工作負載已裝載於App Service方案上，且使用量過低。
• Azure 虛擬機器。 如果您有 Windows 服務，或想要使用 Windows 工作排程器，通常會在專用虛擬機中裝載背景工作。
• Azure Batch。 Batch 是一項平台服務，可排程在受控虛擬機集合上執行的計算密集型工作。 它可以自動調整計算資源。
• Azure Kubernetes Service (AKS)。 Azure Kubernetes Service 為 Azure 上的 Kubernetes 提供受控裝載環境。
• Azure Container Apps。 Azure 容器應用程式可讓您根據容器建置無伺服器微服務。

下列各節會更詳細地描述這些選項，並包含可協助您選擇適當選項的考慮。

Azure Web Apps 和 WebJobs

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

當您設定 WebJob 時：

• 如果您想要讓作業回應事件驅動觸發程式，您應該將其設定為 持續執行。 腳本或程式會儲存在名為site/wwwroot/app_data/jobs/continuous 的資料夾。
• 如果您想要讓作業回應排程驅動觸發程式，您應該將它設定為 依排程執行。 腳本或程式會儲存在名為site/wwwroot/app_data/jobs/triggered 的資料夾。
• 如果您在設定作業時選擇 [ 隨選 執行] 選項，當您啟動作業時，它會執行與 [依排程 執行] 選項相同的程序代碼。

Azure WebJobs 會在 Web 應用程式的沙箱內執行。 這表示他們可以存取環境變數，並與 Web 應用程式共用資訊，例如 連接字串。 作業可以存取執行作業之計算機的唯一標識碼。 名為 AzureWebJobsStorage 的 連接字串 可讓您存取應用程式數據的 Azure 儲存體 佇列、Blob 和數據表，以及存取傳訊和通訊 服務匯流排。 名為 AzureWebJobsDashboard 的 連接字串 可讓您存取作業動作記錄檔。

Azure WebJobs 具有下列特性：

• 安全性：WebJobs 受到 Web 應用程式的部署認證保護。
• 支援的文件類型：您可以使用命令腳本 （）、批處理檔.bat （）、PowerShell 腳本 （.cmd）、Bash 殼層腳本 （.ps1）、PHP.php 腳本 （.sh）、Python 腳本.py （）、JavaScript 程式代碼 （.js） 和可執行程式 （.exe、 .jar等等） 來定義 WebJobs。
• 部署：您可以使用 Azure 入口網站、使用 Visual Studio、使用 Azure WebJobs SDK，或直接將它們複製到下列位置，來部署腳本和可執行檔：
  • 針對觸發的執行：site/wwwroot/app_data/jobs/triggered/{job name}
  • 針對連續執行：site/wwwroot/app_data/jobs/continuous/{job name}
• 記錄：Console.Out 會被視為 INFO。 Console.Error 會被視為 ERROR。 您可以使用 Azure 入口網站 來存取監視和診斷資訊。 您可以直接從網站下載記錄檔。 它們會儲存在下列位置：
  • 針對觸發的執行：Vfs/data/jobs/triggered/jobName
  • 針對連續執行：Vfs/data/jobs/continuous/jobName
• 組態：您可以使用入口網站、REST API 和 PowerShell 來設定 WebJobs。 您可以使用與作業文稿相同的根目錄中名為 settings.job 的組態檔來提供作業的組態資訊。 例如：
  • { “stopping_wait_time”： 60 }
  • { “is_singleton”： true }

考量

• 根據預設，WebJobs 會隨著 Web 應用程式進行調整。 不過，您可以將 is_singleton 組態屬性設定為 true，將作業設定為在單一實例上執行。 單一實例 WebJobs 對於您不想同時調整或執行多個實例的工作很有用，例如重新編製索引、數據分析和類似的工作。
• 若要將作業對 Web 應用程式效能的影響降到最低，請考慮在新的 App Service 方案中建立空的 Azure Web 應用程式實例，以裝載長時間執行或耗用大量資源的 WebJobs。

Azure Functions

類似於 WebJobs 的選項是 Azure Functions。 此服務是無伺服器，最適合短期執行的事件驅動觸發程式。 當設定為在設定為在設定時執行時，函式也可用來透過定時器觸發程式執行排程的工作。

Azure Functions 不是大型長時間執行工作的建議選項，因為它們可能會導致非預期的逾時問題。 不過，視主控方案而定，可以考慮排程驅動觸發程式。

考量

如果背景工作預期會在短時間內執行以回應事件，請考慮在取用方案中執行工作。 運行時間最多可以設定為最長的時間。 執行較長成本的函式。 此外，耗用更多記憶體的CPU密集型作業可能更昂貴。 如果您在工作中針對服務使用其他觸發程式，則會個別計費這些觸發程式。

如果您有大量簡短但預期會持續執行的工作，進階方案會更合適。 此方案成本更高，因為它需要更多記憶體和 CPU。 優點是您可以使用虛擬網路整合等功能。

如果您的工作負載已在背景作業上執行，則專用方案最適合其使用。 如果您有使用量過低的 VM，您可以在相同的 VM 上執行它，並共用計算成本。

如需詳細資訊，請參閱下列文章：

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

Azure 虛擬機器

背景工作可能以防止部署至 Azure Web Apps 的方式實作，或這些選項可能不方便。 典型的範例包括 Windows 服務，以及第三方公用程式和可執行程式。 另一個範例可能是針對與裝載應用程式不同的執行環境所撰寫的程式。 例如，它可能是您想要從 Windows 或 .NET 應用程式執行的 Unix 或 Linux 程式。 您可以從 Azure 虛擬機的一系列作業系統中選擇，並在該虛擬機上執行您的服務或可執行檔。

若要協助您選擇何時使用 虛擬機器，請參閱 Azure App 服務、雲端服務 和 虛擬機器 比較。 如需 虛擬機器 選項的相關信息，請參閱 Azure 中 Windows 虛擬機的大小。 如需適用於 虛擬機器 之操作系統和預先建置映像的詳細資訊，請參閱 Azure 虛擬機器 Marketplace。

若要在個別的虛擬機中起始背景工作，您有一系列選項：

• 您可以將要求傳送至工作公開的端點，直接從應用程式執行工作。 這會傳入工作所需的任何數據。 此端點會叫用工作。
• 您可以使用所選取作業系統中可用的排程器或定時器，將工作設定為依排程執行。 例如，在 Windows 上，您可以使用 Windows 工作排程器來執行腳本和工作。 或者，如果您已在虛擬機上安裝 SQL Server，您可以使用 SQL Server Agent 來執行腳本和工作。
• 您可以使用 Azure Logic Apps 來起始工作，方法是將訊息新增至工作接聽的佇列，或將要求傳送至工作公開的 API。

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

考量

當您決定是否要在 Azure 虛擬機中部署背景工作時，請考慮下列幾點：

• 在不同的 Azure 虛擬機中裝載背景工作可提供彈性，並允許精確控制初始、執行、排程和資源配置。 不過，如果虛擬機必須部署以執行背景工作，則會增加運行時間成本。
• 沒有任何功能可以監視 Azure 入口網站 中的工作，也沒有失敗工作的自動重新啟動功能，不過您可以監視虛擬機的基本狀態，並使用 Azure Resource Manager Cmdlet 來管理它。 不過，沒有任何功能可控制計算節點中的進程和線程。 一般而言，使用虛擬機需要額外的努力，才能實作機制，以從工作中的檢測，以及從虛擬機中的操作系統收集數據。 其中一個可能適合的解決方案是使用適用於 Azure 的 System Center 管理元件。
• 您可以考慮建立透過 HTTP 端點公開的監視探查。 這些探查的程式代碼可以執行健康情況檢查、收集作業資訊和統計數據，或定序錯誤資訊，並將其傳回管理應用程式。 如需詳細資訊，請參閱 健全狀況端點監視模式。

如需詳細資訊，請參閱

• 虛擬機器
• Azure 虛擬機器常見問題集

Azure Batch

如果您需要跨數十、數百或數千部 VM 執行大型平行高效能運算 （HPC） 工作負載，請考慮 Azure Batch 。

Batch 服務會布建 VM、將工作指派給 VM、執行工作，以及監視進度。 Batch 可以自動相應放大 VM 以回應工作負載。 Batch 也提供作業排程。 Azure Batch 同時支援 Linux 和 Windows VM。

考量

Batch 適用於內部平行工作負載。 它也可以透過結尾的縮減步驟執行平行計算，或針對需要節點之間傳遞訊息的平行工作執行 訊息傳遞介面 （MPI） 應用程式 。

Azure Batch 作業會在節點集區上執行（VM）。 其中一種方法是只在需要時配置集區，然後在作業完成之後將其刪除。 這會最大化使用率，因為節點不是閑置，但作業必須等候節點配置。 或者，您可以事先建立集區。 這種方法可將作業啟動所需的時間降到最低，但可能會導致節點閑置。 如需詳細資訊，請參閱 集區和計算節點存留期。

如需詳細資訊，請參閱

• 什麼是 Azure Batch？
• 使用 Batch 開發大規模的平行計算解決方案
• 適用於大規模運算工作負載的 Batch 和 HPC 解決方案

Azure Kubernetes Service

Azure Kubernetes Service （AKS） 會管理裝載的 Kubernetes 環境，讓您輕鬆部署及管理容器化應用程式。

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

• 容器支援高密度裝載。 您可以在容器中隔離背景工作，同時在每個 VM 中放置多個容器。
• 容器協調器會處理內部負載平衡、設定內部網路和其他設定工作。
• 您可以視需要啟動和停止容器。
• Azure Container Registry 可讓您在 Azure 界限內註冊容器。 這包括安全性、隱私權和鄰近性優點。

考量

• 需要瞭解如何使用容器協調器。 視 DevOps 小組的技能集而定，這可能或可能不是問題。

如需詳細資訊，請參閱

• Azure 中容器的概觀

• 私人 Docker 容器登錄簡介

Azure 容器應用程式

Azure 容器應用程式可讓您根據容器建置無伺服器微服務。 容器應用程式的獨特功能包括：

• 已針對執行一般用途容器進行優化，特別是針對跨容器中部署多個微服務的應用程式。
• 由 Kubernetes 和開放原始碼技術提供技術支援，例如 Dapr、Kubernetes 事件驅動自動調整 （KEDA）和 envoy。
• 支援 Kubernetes 樣式的應用程式和微服務，其中包含服務探索和流量分割等功能。
• 支援根據流量調整並從佇列等事件來源提取，包括調整為零，以啟用事件驅動應用程式架構。
• 支援長時間執行的進程，而且可以執行 背景工作。

考量

Azure 容器應用程式不提供基礎 Kubernetes API 的直接存取權。 如果您需要存取 Kubernetes API 和控制平面，則應該使用 Azure Kubernetes Service。 不過，如果您想要建置 Kubernetes 樣式應用程式，而且不需要直接存取所有原生 Kubernetes API 和叢集管理，容器應用程式會根據最佳做法提供完全受控的體驗。 基於這些原因，許多團隊可能偏好開始使用 Azure 容器應用程式建置容器微服務。

如需詳細資訊，請參閱

• Azure 容器應用程式概觀

您可以使用快速入門開始建置您的第一個容器應用程式。

資料分割

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

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

• 延展性：背景工作可能會有不同於UI和應用程式互動式部分的延展性需求。 調整UI可能需要符合需求尖峰，而未處理的背景工作可能會因為較少的計算實例，在較不忙碌的時段內完成。

• 復原：如果這些工作的要求可以排入佇列或延後，只裝載背景工作的計算實例可能會對整個應用程式造成嚴重影響，直到工作再次可供使用為止。 如果計算實例或工作可以在適當的間隔內重新啟動，則應用程式的使用者可能不會受到影響。

• 安全性：背景工作可能有不同的安全性需求或限制，而不是 UI 或應用程式的其他部分。 藉由使用不同的計算實例，您可以為工作指定不同的安全性環境。 您也可以使用 Gatekeeper 之類的模式來隔離背景計算實例與 UI，以最大化安全性和區隔。

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

• 管理性：背景工作可能會有與主要應用程式程序代碼或 UI 不同的開發和部署節奏。 將它們部署到個別的計算實例可以簡化更新和版本設定。

• 成本：新增計算實例來執行背景工作會增加裝載成本。 您應該仔細考慮額外的容量與這些額外成本之間的取捨。

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

衝突

如果您有多個背景作業實例，他們可能會爭相存取資源與服務，例如資料庫和記憶體。 此並行存取可能會導致資源爭用，這可能會導致服務可用性與記憶體中數據完整性發生衝突。 您可以使用悲觀鎖定方法來解決資源爭用。 這可防止工作競爭的實例同時存取服務或損毀數據。

另一個解決衝突的方法是將背景工作定義為單一工作，以便只執行一個實例。 不過，這可消除多個實例組態可以提供的可靠性與效能優點。 如果UI可以提供足夠的工作來讓多個背景工作忙碌，這尤其如此。

請務必確保背景工作可以自動重新啟動，而且有足夠的容量來應付需求尖峰。 您可以藉由使用足夠的資源配置計算實例、實作佇列機制，以在需求減少時儲存後續執行的要求，或使用這些技術的組合來達成此目的。

協調

背景工作可能相當複雜，而且可能需要執行多個個別工作來產生結果或滿足所有需求。 在這些案例中，將工作分成較小的謹慎步驟，或多個取用者可執行的子工作很常見。 多步驟作業可以更有效率且更有彈性，因為個別步驟在多個作業中可能可重複使用。 也很容易新增、移除或修改步驟的順序。

協調多個工作和步驟可能具有挑戰性，但有三種常見模式可用來引導解決方案的實作：

• 將工作分解成多個可重複使用的步驟。 應用程式可能需要針對處理的信息執行各種複雜度不同的工作。 實作此應用程式的簡單但不靈活方法，可能是以整合模組的形式執行此處理。 不過，這種方法可能會減少重構程式代碼、優化程式代碼或重複使用程式代碼的機會，前提是應用程式內其他地方需要相同處理的部分。 如需詳細資訊，請參閱 管道和篩選模式。

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

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

恢復功能考量

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

• 背景工作必須能夠正常處理重新啟動，而不會損毀數據或引入應用程式不一致的情況。 對於長時間執行或多步驟的工作，請考慮使用 檢查點 ，方法是將作業的狀態儲存在永續性記憶體中，或作為佇列中適當的訊息。 例如，您可以在佇列中的訊息中保存狀態資訊，並以工作進度累加更新此狀態資訊，以便從最後一個已知的良好檢查點處理工作，而不是從頭重新啟動。 使用 Azure 服務匯流排 佇列時，您可以使用訊息會話來啟用相同的案例。 會話可讓您使用 SetState 和 GetState 方法來儲存和擷取應用程式處理狀態。 如需設計可靠多步驟程式和工作流程的詳細資訊，請參閱 排程器代理程式監督員模式。

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

• 由訊息或處理訊息起始的背景工作必須設計成處理不一致的情況，例如不依序抵達的訊息、重複導致錯誤的郵件（通常稱為 有害訊息），以及傳遞多次的訊息。 請考慮下列事項：

  • 必須依特定順序處理的訊息，例如根據現有數據值變更數據的訊息（例如，將值新增至現有值），可能不會以傳送數據的原始順序抵達。 或者，由於每個實例上的負載不同，背景工作的不同實例可能會以不同的順序來處理它們。 必須依特定順序處理的訊息應包含序號、索引鍵，或背景工作可用來確保以正確順序處理訊息的一些其他指標。 如果您使用 Azure 服務匯流排，您可以使用訊息會話來保證傳遞順序。 不過，設計程式通常更有效率，因此訊息順序並不重要。

  • 一般而言，背景工作會查看佇列中的訊息，這會暫時隱藏其他訊息取用者。 然後，它會在訊息成功處理之後刪除訊息。 如果背景工作在處理訊息時失敗，該訊息會在查看逾時到期后重新出現在佇列上。 工作的另一個實例或在此實例的下一個處理週期內，它將會進行處理。 如果訊息一致在取用者中造成錯誤，它會封鎖工作、佇列，最後當佇列滿時應用程式本身。 因此，偵測和移除佇列中的有害訊息非常重要。 如果您使用 Azure 服務匯流排，可能會導致錯誤的訊息可以自動或手動移至相關聯的寄不出的信件佇列。

  • 佇列至少 保證一次 傳遞機制，但可能會多次傳遞相同的訊息。 此外，如果背景工作在處理訊息之後失敗，但在從佇列中刪除訊息之前，訊息將會再次可供處理。 背景工作應該是等冪的，這表示多次處理相同的訊息不會在應用程式的數據中造成錯誤或不一致。 某些作業自然具有等冪性，例如將預存值設定為特定的新值。 不過，將值新增至現有預存值的作業，而不檢查預存值是否仍與最初傳送訊息時相同，將會導致不一致。 Azure 服務匯流排 佇列可以設定為自動移除重複的訊息。 如需至少一次訊息傳遞挑戰的詳細資訊，請參閱 等冪訊息處理的指引。

  • 某些傳訊系統，例如 Azure 佇列記憶體和 Azure 服務匯流排 佇列，支援清除佇列計數屬性，指出從佇列讀取訊息的次數。 這在處理重複和有害訊息方面很有用。 如需詳細資訊，請參閱 異步傳訊入門 和 等冪模式。

調整和效能考慮

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

• Azure 支援 根據目前的需求和負載，或根據預先定義的排程，針對 Web Apps 和 虛擬機器 裝載的部署，自動調整（同時相應放大和相應縮小）。 使用這項功能可確保整個應用程式具有足夠的效能功能，同時將運行時間成本降至最低。

• 背景工作具有與應用程式其他部分不同的效能功能（例如，UI 或數據存取層等元件），將背景工作一起裝載在個別計算服務中，可讓UI和背景工作獨立調整以管理負載。 如果多個背景工作彼此有顯著的不同效能功能，請考慮將其分割，並獨立調整每個類型。 不過，請注意，這可能會增加運行時間成本。

• 只要調整計算資源可能不足以防止負載下遺失效能。 您可能也需要調整記憶體佇列和其他資源，以防止整體處理鏈結的單一點成為瓶頸。 此外，請考慮其他限制，例如記憶體的最大輸送量，以及應用程式和背景工作所依賴的其他服務。

• 背景工作必須專為調整而設計。 例如，它們必須能夠動態偵測使用中的記憶體佇列數目，以便接聽或傳送訊息至適當的佇列。

• 根據預設，WebJobs 會與其相關聯的 Azure Web Apps 實例進行調整。 不過，如果您想要讓 WebJob 僅以單一實例的形式執行，您可以建立包含 JSON 數據的 Settings.job 檔案 { “is_singleton”： true }。 這強制 Azure 只執行一個 WebJob 實例，即使有多個相關聯的 Web 應用程式實例也一樣。 對於只能以單一實例身分執行的排程工作而言，這可以是一種有用的技術。

下一步

• 計算數據分割指引
• 異步傳訊入門
• 等冪模式

相關資源

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