開發背景工作的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| 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提供足夠的工作來讓多個背景工作忙碌，則此缺點尤其如此。
請確定背景工作可以自動重新啟動，而且有足夠的容量來處理需求尖峰。 配置具有足夠資源的計算實例、實作佇列機制，以儲存需求減少時執行的要求，或使用這些技術的組合。
協調多個工作
背景工作可能很複雜，且需要執行多個工作。 在這些案例中，通常會將工作分成多個取用者可執行的較小離散步驟或子工作。 多步驟作業更有效率且更有彈性，因為個別步驟在多個作業中通常可重複使用。 也很容易新增、移除或修改步驟的順序。
協調多個工作和步驟可能是一項挑戰，但有三種常見的模式可引導您的解決方案：
將工作分解成多個可重複使用的步驟。 應用程式可能需要針對處理的信息執行不同複雜度的各種工作。 實作這類應用程式的簡單但不靈活方法是以整合型模組的形式執行此處理。 但是，這種方法可能會減少重構程式代碼、優化程式代碼的機會，或如果應用程式需要其他地方相同處理的部分，則將其重複使用。 如需詳細資訊，請參閱 管道和篩選模式。
管理工作步驟的協調流程。 應用程式可能會執行包含許多步驟的工作，其中有些可能會叫用遠端服務或存取遠端資源。 有時候個別步驟彼此獨立，但是由實作工作的應用程式邏輯所協調。 如需詳細資訊，請參閱 排程器代理程式監督員模式。
管理失敗之工作步驟的復原。 如果一或多個步驟失敗，應用程式可能需要復原一系列步驟所執行的工作，這一起定義最終一致的作業。 如需詳細資訊，請參閱 補償交易模式。
讓作業具有復原性
建立具復原性的背景工作，為應用程式提供可靠的服務。 當您規劃和設計背景工作時，請考慮下列幾點：
背景工作需要正常處理重新啟動，而不會損毀資料或導致應用程式不一致。 對於長時間執行或多步驟的工作，請考慮使用 檢查點。 使用檢查點將作業的狀態儲存在永續性記憶體中，或儲存為佇列中的訊息。 例如，您可以將狀態資訊儲存在佇列中的訊息中，並以工作進度累加更新此狀態資訊。 您可以從最後一個已知的檢查點處理工作，而不是從頭重新啟動。
針對 服務匯流排 佇列，請針對此目的使用訊息會話。 使用訊息會話時，使用State和 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 方案上裝載工作負載，您也可以使用函式應用程式。
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 失敗，它會自動重新啟動。 您可以設定重試和錯誤動作。
當您設定 WebJob 時：
如果您想要讓作業回應事件驅動觸發程式，請將它設定為 持續執行。 腳本或程式會儲存在名為site/wwwroot/app_data/jobs/continuous 的資料夾。
如果您想要讓作業回應排程驅動觸發程式，請將它 設定為依排程執行。 腳本或程式會儲存在名為site/wwwroot/app_data/jobs/triggered 的資料夾。
如果您在設定作業時選擇 [ 隨選 執行] 選項，它會在啟動作業時執行與 [依排程 執行] 選項相同的程序代碼。
WebJob 會在 Web 應用程式的沙箱中執行。 它可以存取環境變數，而且可以與 Web 應用程式共用資訊，例如 連接字串。 WebJob 可以存取執行 WebJob 之電腦的唯一標識碼。 名為 AzureWebJobsStorage 的 連接字串 可讓您存取應用程式數據的記憶體佇列、Blob 和數據表。 它也提供傳訊和通訊 服務匯流排的存取權。 名為 AzureWebJobsDashboard 的 連接字串 可讓您存取 WebJob 動作記錄檔。
WebJobs 具有下列特性：
安全性：Web 應用程式的部署認證提供 WebJobs 的保護。
支援的檔類型：使用命令腳本（.cmd）、批處理檔（.bat）、PowerShell 腳本（.ps1）、Bash 殼層腳本（.sh）、PHP 腳本（.php）、Python 腳本（.py）、JavaScript 程式代碼（.js）和可執行程式（.exe和.jar）來定義 WebJobs。
部署：您可以使用 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 上執行專用方案，並共用計算成本。
如需詳細資訊，請參閱
虛擬機器
您可以實作背景工作，使其不會部署到 Web Apps。 例如，您可以使用 Windows 服務、第三方公用程式或可執行程式來實作工作。 您也可以使用針對與裝載應用程式環境不同的運行時間環境所撰寫的程式。 例如，您可以使用想要從 Windows 或 .NET 應用程式執行的 Unix 或 Linux 程式。 從 Azure VM 的數個作業系統中選擇，並在該 VM 上執行您的服務或可執行檔。
如需詳細資訊，請參閱
若要在個別的 VM 中起始背景工作，您可以：
將要求傳送至工作公開的端點，以直接從您的應用程式視需要執行工作。 要求會傳送工作所需的數據。 端點會叫用工作。
使用所選取作業系統中的排程器或定時器，將工作設定為依排程執行。 例如，在 Windows 上，您可以使用 Windows 工作排程器來執行腳本和工作。 如果您已在 VM 上安裝 SQL Server，請使用 SQL Server Agent 來執行腳本和工作。
使用 Logic Apps 將訊息新增至工作監視的佇列，或將要求傳送至工作公開的 API，以起始工作。
如需如何起始背景工作的詳細資訊，請參閱先前 的觸發程式 一節。
虛擬機器 考慮
當您在 Azure VM 中部署背景工作時，請考慮下列幾點：
在不同的 Azure VM 中裝載背景工作，以提供彈性和精確控制起始、部署、排程和資源配置。 不過，如果您只針對背景工作部署 VM，運行時間成本會增加。
沒有任何功能可以監視入口網站中的工作，也沒有失敗工作的自動重新啟動功能。 但您可以使用 Azure Resource Manager Cmdlet 來監視 VM 的狀態並加以管理。 計算節點中沒有控制進程和線程的功能。 一般而言，如果您使用 VM，則必須實作機制，以從工作中檢測以及 VM 中的作業系統收集數據。 您可以使用適用於 Azure 的 System Center 管理元件來進行此目的。
請考慮建立透過 HTTP 端點公開的監視探查。 您可以設定這些探查的程式代碼，以執行健康情況檢查並收集作業資訊和統計數據。 您也可以使用探查來定序錯誤資訊，並將其傳回管理應用程式。
如需詳細資訊，請參閱
Batch
如果您需要跨數十、數百或數千部 VM 執行大型平行高效能運算 （HPC） 工作負載，請考慮 Batch 。
使用 Batch 來準備 VM、將工作指派給 VM、執行工作、監視進度，以及自動相應放大 VM 以回應工作負載。 Batch 也提供作業排程，並支援 Linux 和 Windows VM。
批次考慮
Batch 適用於內部平行工作負載。 您可以使用 Batch 在結尾執行縮減步驟的平行計算，或針對需要節點之間傳遞訊息的平行工作執行 訊息傳遞介面 （MPI） 應用程式 。
Batch 作業會在節點集區或 VM 上執行。 您只能在需要時配置集區，然後在作業完成之後將其刪除。 這種方法會最大化使用率，因為節點未閑置，但作業必須等候您配置節點。 或者，您可以事先建立集區。 這種方法可將作業啟動所花費的時間降到最低，但可能會導致節點閑置。
如需詳細資訊，請參閱
Azure Kubernetes Service
使用 AKS 來管理裝載的 Kubernetes 環境，讓您可以輕鬆地部署和管理容器化應用程式。
容器對於執行背景作業很有用。 以下是一些優勢：
容器支援高密度裝載。 您可以在容器中隔離背景工作，同時在每個 VM 中放置多個容器。
使用容器協調器來執行內部負載平衡、設定內部網路，以及執行其他組態工作。
您可以視需要啟動和停止容器。
使用 Azure Container Registry，您可以在 Azure 界限內註冊容器，以提供安全性、隱私權和鄰近性優點。
AKS 考量
AKS 需要瞭解如何使用容器協調器。
如需詳細資訊，請參閱
容器應用程式
使用 Container Apps，您可以建置以容器為基礎的無伺服器微服務。 容器應用程式：
已針對執行一般用途容器進行優化，特別是跨越容器中部署之許多微服務的應用程式。
由 Kubernetes 和開放原始碼技術提供技術支援，例如 Dapr、Kubernetes 事件驅動自動調整 （KEDA）和 Envoy。
藉由支持根據流量和從佇列等事件來源提取的調整，包括調整為零，來啟用事件驅動應用程序架構。
支援長時間執行的進程，而且可以執行 背景工作。
容器應用程式考慮
容器應用程式不提供基礎 Kubernetes API 的直接存取權。 如果您需要存取 Kubernetes API 和控制平面，請使用 AKS。 如果您想要建置 Kubernetes 樣式的應用程式，而且不需要直接存取原生 Kubernetes API 和叢集管理，請使用 Container Apps 取得完全受控的體驗。 容器應用程式最適合用來建置容器微服務。
如需詳細資訊，請參閱
相關連結
可靠性檢查清單
請參閱一組完整的建議。