將多個工作或作業合併成單一計算單位。 這會增加計算資源使用率，並降低與在雲端裝載應用程式中執行計算處理相關聯的成本和管理額外負荷。
內容和問題
雲端應用程式通常會實作各種作業。 在某些解決方案中，遵循考慮一開始分離的設計原則是合理的，並將這些作業分成個別裝載和部署的個別計算單位（例如，個別的 App Service Web 應用程式或個別的 虛擬機器）。 不過，雖然此策略有助於簡化解決方案的邏輯設計，但部署大量計算單位做為相同應用程式的一部分，可能會增加運行時間裝載成本，並讓系統管理更加複雜。
例如，此圖顯示使用多個計算單位實作之雲端裝載解決方案的簡化結構。 每個計算單位都會在其自己的虛擬環境中執行。 每個函式都已實作為個別的工作（標示為工作 A 到工作 E），其本身的計算單位中執行。
每一個計算單位都會耗用可收費的資源，即使它閑置或輕而易用。 因此，這不一定是最符合成本效益的解決方案。
在 Azure 中，此考慮適用於 App Services、Container Apps 和 虛擬機器。 這些專案會在自己的環境中執行。 執行個別網站、微服務或虛擬機的集合，其設計目的是要執行一組定義完善的作業，但需要作為單一解決方案的一部分進行通訊和合作，可能會沒有效率地使用資源。
解決方案
為了協助降低成本、提高使用率、提高通訊速度，並減少管理，可以將多個工作或作業合併成單一計算單位。
工作可以根據環境所提供的功能以及與這些功能相關聯的成本，根據準則來分組工作。 常見的方法是尋找具有類似配置檔的工作，其延展性、存留期和處理需求。 將這些群組在一起可讓它們調整為單位。 許多雲端環境所提供的彈性可讓計算單位的其他實例根據工作負載啟動和停止。 例如，Azure 提供可套用至 App Services 和 虛擬機器擴展集 的自動調整。 如需詳細資訊，請參閱 自動調整指引。
作為示範延展性如何用來判斷不應該群組在一起的作業的計數器範例，請考慮下列兩項工作：
- 工作 1 會輪詢傳送至佇列的不常、不區分時間的訊息。
- 工作 2 會處理大量網路流量高載。
第二個工作需要彈性，這牽涉到啟動和停止大量的計算單位實例。 將相同的調整套用至第一個工作，只會造成更多工作在相同佇列上接聽不常訊息，而且浪費資源。
在許多雲端環境中，可以指定計算單位可用的資源，以 CPU 核心數目、記憶體、磁碟空間等等。 一般而言，指定的資源越多，成本就越大。 為了節省成本，請務必將成本高昂的計算單位執行的工作最大化，而不會讓它長時間變成非使用中。
如果有需要大量 CPU 電源的工作在短高載中，請考慮將這些工作合併成提供必要電源的單一計算單位。 不過，必須平衡這一需求，讓昂貴的資源與爭用保持忙碌，如果資源過度緊張，就可能發生的爭用。 例如，長時間執行的計算密集型工作不應該共用相同的計算單位。
問題和考慮
實作此模式時，請考慮下列幾點：
延展性和彈性。 許多雲端解決方案會藉由啟動和停止單位的實例，在計算單位層級實作延展性和彈性。 請避免將相同計算單位中延展性需求衝突的工作分組。
存留期。 雲端基礎結構會定期回收裝載計算單位的虛擬環境。 當計算單位內有許多長時間執行的工作時，可能需要設定該單位以防止回收，直到這些工作完成為止。 或者，使用檢查點方法來設計工作，讓工作能夠完全停止，並在計算單位重新啟動時中斷時繼續工作。
釋放步調。 如果工作實作或設定經常變更，可能需要停止裝載更新程式碼的計算單位、重新設定和重新部署單位，然後重新啟動它。 此程式也需要停止、重新部署和重新啟動相同計算單位內所有其他工作。
安全性。 相同計算單位中的工作可能會共用相同的安全性內容，而且能夠存取相同的資源。 工作之間必須高度信任，且信任一項工作不會損毀或對另一個工作造成負面影響。 此外，增加計算單位中執行的工作數目會增加單位的攻擊面。 每個工作都和最弱點一樣安全。
容錯。 如果計算單位中的一個工作失敗或行為異常，它可能會影響在相同單位內執行的其他工作。 例如，如果某個工作無法正確啟動，可能會導致計算單位的整個啟動邏輯失敗，並防止相同單位中的其他工作執行。
爭用。 避免在競爭相同計算單位中資源的工作之間引入競爭。 在理想情況下，共用相同計算單位的工作應該會顯示不同的資源使用率特性。 例如，兩個計算密集型工作可能不位於相同的計算單位中，兩個工作都不應該耗用大量的記憶體。 不過，將計算密集型工作與需要大量記憶體的工作混合在一起是可行的組合。
注意
請考慮只針對生產環境中一段時間的系統合併計算資源，讓操作員和開發人員可以監視系統，並建立 熱度圖 ，以識別每個工作如何使用不同的資源。 此對應可用來判斷哪些工作是共用計算資源的良好候選專案。
複雜度。 將多個工作結合成單一計算單位，會增加單元中程式代碼的複雜性，可能使得測試、偵錯和維護更加困難。
穩定的邏輯架構。 設計和實作每個工作中的程序代碼，使其不需要變更，即使工作執行中的實體環境也會變更。
其他策略。 合併計算資源只是協助同時執行多個工作的相關成本的其中一種方式。 它需要仔細規劃和監視，以確保它仍然是一個有效的方法。 根據工作的性質以及執行這些工作的使用者所在位置，其他策略可能更合適。 例如，工作負載的功能分解（如計算數據分割指引所述）可能是較佳的選項。
使用此模式的時機
如果工作是在自己的計算單位中執行，請使用此模式來執行不符合成本效益的工作。 如果工作花費大部分時間閑置，在專用單元中執行此工作可能會很昂貴。
此模式可能不適合執行重大容錯作業的工作，或處理高度敏感或私人數據的工作，而且需要自己的安全性內容。 這些工作應該在個別的計算單位中，於自己的隔離環境中執行。
工作負載設計
架構設計人員應該評估計算資源匯總模式在工作負載的設計中如何使用，以解決 Azure 架構良好架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 成本優化著重於維持和改善工作負載的投資報酬率。 | 此模式可藉由透過集區基礎結構上的元件匯總，甚至是整個工作負載的匯總，避免未使用的布建容量，將計算資源的使用率最大化。 - CO：14 合併 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 匯總可能會導致更同質的計算平臺，其可簡化管理和可觀察性、減少作業工作的不同方法，並減少所需的工具數量。 - OE：07 監視系統 - OE：10 自動化設計 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 整合可藉由使用備用節點容量並減少過度布建的需求，將計算資源的使用率最大化。 大型（垂直縮放）計算實例通常用於這些基礎結構的資源集區中。 - PE：02 容量規劃 - PE：03 選取服務 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
應用程式平台選擇
視您使用的計算服務而定，可以透過不同的方式達成此模式。 請參閱下列範例服務：
- Azure App 服務 和 Azure Functions：部署代表主控伺服器基礎結構的共用 App Service 方案。 一或多個應用程式可設定為在相同的計算資源上執行 (或在相同的 App Service 方案中執行)。
- Azure Container Apps：將容器應用程式部署到相同的共用環境;特別是在您需要管理相關服務，或需要將不同的應用程式部署到相同的虛擬網路時。
- Azure Kubernetes Service （AKS）：AKS 是以容器為基礎的裝載基礎結構，其中多個應用程式或應用程式元件可以設定為在相同的運算資源（節點）上執行共置，並依 CPU 或記憶體需求（節點集區）等計算需求分組。
- 虛擬機：為所有租使用者部署單一虛擬機集以供使用，如此一來，管理成本就會跨租用戶共用。 虛擬機器擴展集 是支援共用資源管理、負載平衡和水準調整 虛擬機器 的功能。
相關資源
實作此模式時，下列模式和指引也可能相關：