多租使用者解決方案中傳訊的架構方法
建置由數個內部和外部服務組成的分散式應用程式時，異步傳訊和事件驅動通訊是重要的資產。 當您設計多租用戶解決方案時，進行初步分析非常重要，以定義如何共用或分割與不同租使用者相關的訊息。
共用相同的傳訊系統或事件串流服務可以大幅降低營運成本和管理複雜性。 不過，針對每個租使用者使用專用的傳訊系統可提供更佳的數據隔離、降低數據外泄的風險、消除 Noisy Neighbor 問題，並可讓您輕鬆地將 Azure 成本收取回租使用者。
在本文中，您可以找出訊息和事件之間的差異，而且在決定在多租使用者解決方案中用於傳訊或事件基礎結構時，解決方案架構設計人員可以遵循的指導方針。
訊息、數據點和離散事件
所有傳訊系統都有類似的功能、傳輸通訊協定和使用案例。 例如，大部分的新式傳訊系統都支援使用揮發性或永續性佇列、AMQP 和 HTTPS 傳輸通訊協定、至少一次傳遞等異步通訊。 不過，藉由更仔細地查看已發佈信息的類型，以及用戶端應用程式如何取用和處理數據，我們可以區分不同類型的訊息和事件。 傳遞事件和傳送訊息的系統的服務之間有基本的區別。 如需詳細資訊，請參閱以下資源：
事件
事件是情況或狀態變更的輕量型通知。 事件可能是離散單元或系列的一部分。 事件是通常不會傳達發行者意圖的訊息，而不是通知。 事件會擷取事實，並將它傳達給其他服務或元件。 事件的取用者可以視需要處理事件，而且無法滿足發行者保留的任何特定期望。 我們可以將事件分類為兩個主要類別：
- 離散事件 會保存發佈應用程式已執行之特定動作的相關信息。使用異步事件驅動通訊時，應用程式會在其網域內發生情況時發佈通知事件。 一或多個取用的應用程式必須注意此狀態變更，例如產品目錄應用程式中的價格變更。 取用者會訂閱事件，以異步方式接收事件。 當指定的事件發生時，取用的應用程式可能會更新其網域實體，這可能會導致發佈更多整合事件。
- 數列事件 會攜帶參考數據點，例如來自裝置的溫度讀數，以分析或點擊分析解決方案中的用戶動作，做為進行中連續串流中的元素。 事件數據流與特定內容相關，例如現場裝置所報告的溫度或濕度。 與相同內容相關的所有事件都有嚴格的時態順序，在使用事件串流處理引擎處理這些事件時很重要。 分析攜帶數據點的事件串流需要在跨越所需時間範圍的緩衝區中累積這些事件。 或者，它可以在選取的項目數目中，然後使用近乎即時的解決方案或機器定型演算法來處理這些事件。 一系列事件的分析可能會產生訊號，例如跨越閾值的時間範圍所測量值的平均值。 然後，這些訊號可以引發為離散且可採取動作的事件。
離散事件會報告狀態變更，而且可採取動作。 事件承載具有所發生事件的相關信息，但一般而言，它沒有觸發事件的完整數據。 例如，事件會通知取用者報告應用程式在記憶體帳戶中建立新檔案。 事件承載可能有檔案的一般資訊，但它本身沒有檔案本身。 離散事件非常適合需要調整的無伺服器解決方案。
系列事件會報告情況且可供分析。 離散事件是時間排序和相互關聯的。 在某些內容中，取用者必須接收完整的事件順序，以分析所發生的情況，並採取必要的動作。
訊息
訊息包含由服務所產生的原始數據，以在其他地方取用或儲存。 訊息通常會傳遞接收服務所需的資訊，以在工作流程或處理鏈結中執行步驟。 這類通訊的範例是 命令模式。 發行者也可能預期訊息的接收者會執行一系列動作，並使用異步訊息回報其處理結果。 訊息發行者和訊息接收者之間存在合約。 例如，發行者會傳送含有一些原始數據的訊息，並預期取用者會從該數據建立檔案，並在完成時傳回回應消息。 在其他情況下，傳送者進程可能會傳送異步的單向訊息，要求另一個服務執行指定的作業，但不需要從中取得通知或回應訊息。
這種合約訊息處理與發行者向消費者代理程式對象發佈離散事件的發行者大不相同，而不需要任何特定的預期來處理這些通知。
範例案例
以下是訊息、數據點和離散事件的一些範例多租使用者案例清單：
- 離散事件：
- 音樂共用平台會追蹤特定租使用者中特定使用者接聽特定音樂曲目的事實。
- 在在線商店 Web 應用程式中，目錄應用程式會使用 Publisher-Subscriber 模式 將事件傳送給其他應用程式，以通知他們專案價格已變更。
- 製造公司會將即時資訊推送給客戶和第三方，以了解設備維護、系統健康情況和合約更新。
- 資料點：
- 建築物控制系統會接收遙測事件，例如來自屬於多個客戶的感測器的溫度或濕度讀數。
- 事件驅動監視系統會以近乎即時的方式從多個服務接收及處理診斷記錄，例如網頁伺服器。
- 網頁上的用戶端文本會收集用戶動作，並將其傳送至點擊分析解決方案。
- 訊息：
- B2B 財務應用程式會收到訊息，以開始處理租用戶的銀行記錄。
- 長時間執行的工作流程會收到觸發下一個步驟執行的訊息。
- 在線商店應用程式的購物籃應用程式會使用異步的持續性訊息，將 CreateOrder 命令傳送給排序應用程式。
重要考量與需求
您為解決方案選擇的部署和租用模型會對安全性、效能、數據隔離、管理以及租使用者交叉收取資源成本的能力產生深厚的影響。 此分析包含您為傳訊和事件基礎結構選取的模型。 在本節中，我們會檢閱您在規劃多租使用者解決方案中訊息系統時必須做出的一些重要決策。
調整
租用戶數目、訊息流程和事件數據流的複雜度、訊息數量、預期的流量配置檔，以及隔離等級應在規劃訊息或事件基礎結構時驅動決策。
第一個步驟包括進行詳盡的容量規劃，並在輸送量方面建立訊息系統所需的最大容量，以正確處理一般或尖峰流量下預期的訊息數量。
某些服務供應專案，例如 Azure 服務匯流排 進階層，會在 CPU 和記憶體層級提供資源隔離，讓每個客戶工作負載以隔離方式執行。 此資源容器稱為「傳訊單位」 。 每個進階命名空間都會被配置至少一個傳訊單位。 您可以為每個 服務匯流排 Premium 命名空間購買 1、2、4、8 或 16 個傳訊單位。 單一工作負載或實體可以跨越多個傳訊單位，而且您可以視需要變更傳訊單位數目。 結果是 服務匯流排 型解決方案的可預測且可重複的效能。 如需詳細資訊，請參閱 服務匯流排 進階和標準傳訊層。 同樣地，Azure 事件中樞 定價層可讓您根據預期的輸入和輸出事件量來調整命名空間的大小。 例如，進階供應專案是由 處理單位 （PUS） 計費，其對應於基礎結構中隔離資源的共用（CPU、記憶體和記憶體和記憶體）。 每個 PU 的有效擷取和數據流輸送量將取決於下列因素：
- 產生者及取用者數量
- 承載大小
- 分割區計數
- 輸出要求率
- 事件中樞擷取、結構描述登錄和其他進階功能的使用情況
如需詳細資訊，請參閱 事件中樞 Premium 概觀。
當您的解決方案處理大量租使用者時，您決定為每個租用戶採用個別的傳訊系統時，您必須有一致的策略，以自動化每個基礎結構的部署、監視、警示和調整，彼此分開。
例如，使用基礎結構即程序代碼 （IaC） 工具，例如 Terraform、Bicep 或 Azure Resource Manager （ARM） JSON 範本，以及 Azure DevOps 系統，例如 Azure DevOps 或 GitHub Actions，即可在布建程式期間部署指定租使用者的傳訊系統。 如需詳細資訊，請參閱 多租用戶解決方案部署和設定的架構方法。
訊息系統的大小可能會以每單位一個單位的訊息輸送量上限來調整。 如果系統支援動態自動調整，其容量可能會根據流量狀況和計量自動增加或減少，以符合預期的服務等級協定。
效能可預測性和可靠性
在為少數租用戶設計及建置傳訊系統時，使用單一傳訊系統可能是一個很好的解決方案，以符合輸送量方面的功能需求，而且可以降低總擁有成本。 多租使用者應用程式可能會共用相同的傳訊實體，例如多個客戶的佇列和主題。 或者，他們可能會針對每個元件使用一組專用的元件，以增加租用戶隔離。 另一方面，跨多個租用戶共用相同的傳訊基礎結構，可能會向 Noisy Neighbor 問題公開整個解決方案。 一個租用戶的活動可能會損害其他租使用者，就效能和操作性而言。
在此情況下，訊息系統應該適當地重設大小，以在尖峰時間維持預期的流量負載。 在理想情況下，它應該支援自動調整。 當流量增加時，傳訊系統應該動態相應放大，並在流量減少時相應縮小。 每個租使用者的專用傳訊系統也可以降低 Noisy Neighbor 風險，但管理大量傳訊系統可能會增加解決方案的複雜性。
多租使用者應用程式最終可以採用混合式方法，其中核心服務會在單一共用傳訊系統中使用相同的佇列和主題集，以實作內部異步通訊。 相反地，其他服務可能會針對每個租用戶採用一組專用的傳訊實體，甚至是專用的傳訊系統，以減輕 Noisy Neighbor 問題並保證數據隔離。
將傳訊系統部署至虛擬機時，您應該與計算資源共置這些虛擬機，以減少網路等待時間。 這些虛擬機不應與其他服務或應用程式共用，以避免訊息基礎結構與其他系統競爭系統資源，例如 CPU、記憶體和網路頻寬。 虛擬機也可以分散到 可用性區域，以增加業務關鍵性工作負載的區域內復原和可靠性，包括傳訊系統。 假設您決定在虛擬機上裝載傳訊系統，例如 RabbitMQ 或 Apache ActiveMQ。 在此情況下，建議您將其部署至虛擬機擴展集，並根據 CPU 或記憶體等計量進行自動調整。 如此一來，裝載傳訊系統的代理程序節點數目會根據流量狀況適當地相應放大和相應縮小。 如需詳細資訊，請參閱 使用 Azure 虛擬機擴展集自動調整的概觀。
同樣地，在 Kubernetes 叢集上裝載傳訊系統時，請考慮使用節點選取器和污點來排程其 Pod 在專用節點集區上執行，而不是與其他工作負載共用，以避免 Noisy Neighbor 問題。 將傳訊系統部署至區域備援 AKS 叢集時，請使用 Pod 拓撲散佈條件約束 來控制 Pod 如何分散到失敗網域之間的 AKS 叢集，例如區域、可用性區域和節點。 在 AKS 上裝載第三方傳訊系統時，請使用 Kubernetes 自動調整，在流量增加時動態相應放大背景工作節點數目。 使用 水準 Pod 自動調整程式和 AKS 叢集自動調整程式，節點和 Pod 磁碟區會即時動態調整，以符合流量狀況，並避免容量問題所造成的停機時間。 如需詳細資訊，請參閱 自動調整叢集以符合 Azure Kubernetes Service （AKS） 上的應用程式需求。 如果您想要根據指定佇列的長度相應放大 Kubernetes 裝載傳訊系統的 Pod 數目，例如 RabbitMQ 或 Apache ActiveMQ，請考慮使用 Kubernetes Even-Driven Autoscaling （KEDA）。 透過 KEDA，您可以根據需要處理的事件數目，推動 Kubernetes 中任何容器的調整。 例如，您可以使用 KEDA 根據 Azure 服務匯流排 佇列、RabbitMQ 佇列或 ActiveMQ 佇列的長度來調整應用程式。 如需 KEDA 的詳細資訊，請參閱 Kubernetes 事件驅動自動調整。
隔離
設計多租使用者解決方案的傳訊系統時，您應該考慮不同類型的應用程式需要不同類型的隔離，這以租使用者的效能、隱私權和稽核需求為基礎。
- 多個租用戶可以在相同的傳訊系統中共用相同的傳訊實體，例如佇列、主題和訂用帳戶。 例如，多租使用者應用程式可以從單一 Azure 服務匯流排 佇列接收多租用戶數據的訊息。 此解決方案可能會導致效能和延展性問題。 如果某些租用戶產生的訂單數量比其他租使用者大，這可能會導致訊息積壓。 此問題也稱為 「Noisy 芳鄰」問題，可能會降低某些租用戶的延遲服務等級協定。 如果取用者應用程式以嚴格的時間順序讀取和處理來自佇列的訊息，以及處理訊息所需的時間取決於承載中的專案數目，則問題更為明顯。 在多個租用戶之間共用一或多個佇列資源時，傳訊基礎結構和處理系統應該能夠容納以規模和輸送量需求為基礎的預期流量。 此架構方法適用於多租使用者解決方案採用單一背景工作進程集區的情況，以便接收、處理及傳送所有租用戶的訊息。
- 多個租用戶共用相同的傳訊系統，但使用不同的主題或佇列資源。 由於系統管理員必須布建、監視及維護更多佇列資源，因此此方法可提供更高的成本隔離和數據保護、增加作業複雜度，以及降低靈活度。 此解決方案可確保所有租使用者的一致且可預測的體驗，就效能和服務等級協定而言，因為它可防止任何租使用者建立可能影響其他租用戶的瓶頸。
- 每個租用戶都會使用不同的專用傳訊系統。 例如，多租用戶解決方案可以使用每個租使用者的不同 Azure 服務匯流排 命名空間。 此解決方案會以較高的複雜度和營運成本，提供最高程度的隔離。 此方法保證一致的效能，並允許根據特定租使用者需求微調傳訊系統。 當新的租用戶上線時，除了完全專用的傳訊系統之外，布建應用程式可能也需要建立個別的受控識別或服務主體，並具有適當的 RBAC 許可權來存取新建立的命名空間。 例如，當 Kubernetes 叢集由相同 SaaS 應用程式的多個實例共用時，每個租使用者各有一個，而每個租使用者則每個實例在個別命名空間中執行時，每個應用程式實例可能會使用不同的服務主體或受控識別來存取專用傳訊系統。 在此內容中，傳訊系統可以是完全受控的 PaaS 服務，例如 Azure 服務匯流排 命名空間或 Kubernetes 裝載的傳訊系統，例如 RabbitMQ。 從系統刪除租使用者時，應用程式應該移除訊息系統，以及先前為租使用者建立的任何專用資源。 這種方法的主要缺點是，其會增加作業複雜度，並減少靈活度，尤其是在租用戶數量隨著時間成長時。
檢閱下列其他考慮和觀察：
- 如果租使用者需要使用自己的密鑰來加密和解密訊息，多租使用者解決方案應該為每個租使用者提供個別 Azure 服務匯流排 Premium 命名空間的選項。 如需詳細資訊，請參閱設定客戶管理的金鑰，以加密待用 Azure 服務匯流排 數據。
- 如果租使用者需要高層級的復原和商務持續性，多租用戶解決方案應提供在已啟用異地災害復原和可用性區域的情況下布建 服務匯流排 Premium 命名空間的能力。 如需詳細資訊，請參閱 Azure 服務匯流排地理災害復原。
- 針對每個租使用者使用不同的佇列資源或專用傳訊系統時，合理採用個別的背景工作進程集區，讓每個租使用者增加數據隔離等級，並減少處理多個傳訊實體的複雜性。 處理系統的每個實例都可以採用不同的認證，例如 連接字串、服務主體或受控識別，以存取專用傳訊系統。 此方法提供更佳的安全性層級和租用戶之間的隔離，但需要身分識別管理的複雜性增加。
同樣地，事件驅動應用程式可以提供不同等級的隔離：
- 事件驅動應用程式會透過單一共享 Azure 事件中樞 實例，從多個租使用者接收事件。 此解決方案提供高層級的靈活度，因為上線新租使用者不需要建立專用的事件擷取資源，但它提供低數據保護層級，因為它會在相同數據結構中的多個租用戶之間混用訊息。
- 租使用者可以選擇專用的事件中樞或 Kafka 主題，以避免 Noisy Neighbor 問題 ，並符合其數據隔離需求，當事件不得與其他租使用者共同混用時，安全性與數據保護。
- 如果租使用者需要高層級的復原和商務持續性，多租使用者應提供布建事件中樞 Premium 命名空間的能力，並啟用異地災害復原和 可用性區域 。 如需詳細資訊，請參閱 Azure 事件中樞 - 異地災害復原。
- 應針對需要將事件封存至 Azure 儲存體 帳戶的客戶，建立已啟用事件中樞擷取的專用事件中樞，基於法規合規性原因和義務。 如需詳細資訊，請參閱在 Azure Blob 儲存體 或 Azure Data Lake Storage 中透過 Azure 事件中樞 擷取事件。
- 單一多租使用者應用程式可以使用 Azure 事件方格，將通知傳送至多個內部和外部系統。 在此情況下，應該為每個取用者應用程式建立個別的 Event Grid 訂用帳戶。 如果您的應用程式使用多個事件方格實例將通知傳送給大量外部組織，請考慮使用 事件網域，讓應用程式將事件發佈至數千個主題，例如每個租使用者的一個。 如需詳細資訊，請參閱 瞭解管理事件方格主題的事件網域。
實作的複雜度
設計多租用戶解決方案時，請務必考慮系統在中長期發展的方式，以防止其複雜性隨著時間成長，直到需要重新設計部分或整個解決方案。 此重新設計可協助您應付越來越多的租使用者。 設計傳訊系統時，您應該在未來幾年內考慮訊息量和租使用者的預期成長，然後建立可相應放大的系統，以跟上預測的流量，並減少布建、監視和維護等作業的複雜性。
每當租使用者應用程式佈建或取消布建時，解決方案應該會自動建立或刪除必要的傳訊實體，而不需要手動作業。
多租用戶數據解決方案特別關心的是您支援的自定義層級。 每當部署單一租使用者或多租使用者應用程式時，應用程式布建系統（例如 DevOps 系統）應該自動設定及套用任何自定義專案，這是以一組初始參數為基礎。
管理和作業的複雜性
從一開始規劃您打算如何操作、監視和維護傳訊和事件基礎結構，以及您的多租使用者方法如何影響您的作業和程式。 例如，請考慮下列可能性：
- 您可能打算在一組專用的虛擬機中裝載應用程式所使用的傳訊系統，每個租使用者各一個。 如果是，您打算如何部署、升級、監視和相應放大這些系統？
- 同樣地，如果您在共用 Kubernetes 叢集中容器化和裝載傳訊系統，您要如何規劃部署、升級、監視和相應放大個別傳訊系統？
- 假設您在多個租用戶之間共用傳訊系統。 您的解決方案如何收集和報告每個租使用者使用計量，或節流每個租使用者可以傳送或接收的訊息數目？
- 當您的傳訊系統利用 PaaS 服務，例如 Azure 服務匯流排 時，您應該詢問下列問題：
- 如何根據租使用者所要求的功能和隔離等級（共用或專用）來自定義每個租用戶的定價層？
- 如何建立個別租使用者管理身分識別和 Azure 角色指派，以只將適當的許可權指派給租使用者可以存取的訊息實體，例如佇列、主題和訂用帳戶？ 如需詳細資訊，請參閱使用 Microsoft Entra ID 驗證受控識別，以存取 Azure 服務匯流排 資源。
- 如果您需要移至不同類型的傳訊服務、不同的部署或其他區域，您要如何移轉租使用者？
成本
一般而言，租使用者對部署基礎結構的密度越高，布建該基礎結構的成本就越低。 不過，共用基礎結構會增加像 Noisy Neighbor 問題這樣的問題的可能性，因此請仔細考慮取捨。
要考慮的方法和模式
Azure 架構中心的數 個雲端設計模式 可以套用至多租用戶傳訊系統。 您可以選擇一致地遵循一或多個模式，或根據您的需求考慮混合和比對模式。 例如，針對大部分租使用者，您可能會使用多租使用者 服務匯流排 命名空間，但您可以針對支付更多或更高需求的租使用者部署專用的單一租使用者 服務匯流排 命名空間。 同樣地，使用部署戳記來調整通常是很好的作法，即使您在戳記中使用多租使用者 服務匯流排 命名空間或專用命名空間也一樣。
部署戳記模式
如需部署戳記模式和多租使用者的詳細資訊，請參閱 多租用戶架構方法的部署戳記模式一節。 如需租使用者模型的詳細資訊，請參閱 多租使用者解決方案要考慮的租用模型。
共用傳訊系統
您可以考慮部署共用傳訊系統，例如 Azure 服務匯流排，並在所有租用戶之間共用。
此方法會將租使用者密度最高的租使用者提供給基礎結構，因此可降低總擁有成本。 它也會降低管理額外負荷，因為有單一傳訊系統或資源可管理及保護。
不過，當您跨多個租使用者共用資源或整個基礎結構時，請考慮下列注意事項：
- 請記住，並考慮有問題的資源限制、調整功能、配額和限制。 例如，Azure 訂用帳戶中 服務匯流排 命名空間數目上限、單一命名空間中的事件中樞數目上限或最大輸送量限制，最終可能會成為硬式封鎖程式，如果您的架構成長以支援更多租使用者， 請仔細考慮您需要根據每個單一 Azure 訂用帳戶的命名空間數目或每個單一命名空間的佇列數目達到的最大規模。 然後，先比較您目前和未來的估計值與所選傳訊系統的現有配額和限制，再選取此模式。
- 如上述各節所述，當您跨多個租使用者共享資源時， Noisy Neighbor 問題 可能會成為一個因素，特別是當某些租用戶特別忙碌，或它們產生高於其他租使用者的流量時。 在此情況下，請考慮套用節流模式或速率限制模式來減輕這些影響。 例如，您可以限制單一租用戶可以在時間單位中傳送或接收的訊息數目上限。
- 您可能難以監視活動，並 測量單一租用戶的資源耗用量 。 某些服務，例如 Azure 服務匯流排，會收取傳訊作業的費用。 因此，當您跨多個租使用者共用命名空間時，您的應用程式應該能夠追蹤代表每個租使用者完成的傳訊作業數目，以及其退款成本。 其他服務不提供相同層級的詳細數據。
租用戶對於安全性、區域內復原、災害復原或位置可能有不同的需求。 如果這些不符合您的傳訊系統組態，您可能無法只使用單一資源來容納它們。
分區化模式
分區化模式牽涉到部署多個稱為分區的傳訊系統，其中包含一或多個租用戶的傳訊實體，例如佇列和主題。 不同於部署戳記，分區並不表示整個基礎結構重複。 您可以分區傳訊系統，而不用在解決方案中複製或分區化其他基礎結構。
每個傳訊系統或 分區 在可靠性、SKU 和位置方面都可以有不同的特性。 例如，您可以根據租使用者在效能、可靠性、數據保護或商務持續性方面的位置或需求，跨具有不同特性的多個傳訊系統分區化租使用者。
使用分區化模式時，您必須使用 分區化策略，才能將指定的租用戶對應至包含其佇列的傳訊系統。 查閱 策略 會使用對應，根據租用戶名稱或標識符來分割目標傳訊系統。 多個租使用者可能會共用相同的分區，但單一租使用者所使用的傳訊實體不會分散到多個分區。 對應可以使用單一字典來實作，該字典會將租用戶的名稱對應至目標傳訊系統的名稱或參考。 對應可以儲存在可存取的分散式快取中、由多租使用者應用程式的所有實例，或永續性存放區，例如關係資料庫中的數據表或記憶體帳戶中的數據表。
分區化模式可以調整為非常大量的租使用者。 此外，視您的工作負載而定，您可能能夠達到分區的高密度租使用者，因此成本可能很有吸引力。 分區化模式也可用來解決 Azure 訂用帳戶和服務配額、限制和服務限制。
具有每個租使用者專用傳訊系統的多租用戶應用程式
另一個常見方法是部署單一多租用戶應用程式，每個租使用者都有專用的傳訊系統。 在此租用模型中，您有一些共用元件，例如計算資源，而其他服務則使用單一租使用者專用部署方法來布建和管理。 例如，您可以建置單一應用層，然後為每個租使用者部署個別傳訊系統，如下圖所示。
如果您發現系統上大部分負載都是因為您可以針對每個租用戶個別部署的特定元件，水準分割部署可協助您減輕嘈雜的鄰近問題。 例如，您可能需要針對每個租使用者使用不同的傳訊或事件串流系統，因為單一實例不足以跟上多個租使用者所產生的流量。 針對每個租使用者使用專用傳訊系統時，如果單一租使用者造成大量的訊息或事件，這可能會影響共用元件，但不會影響其他租使用者的傳訊系統。
因為您為每個租使用者布建專用資源，因此這種方法的成本可能高於共用裝載模型。 另一方面，採用此租用模型時，較容易將專用系統的資源成本退款給使用此租使用者的唯一租使用者。 這種方法可讓您達到其他服務的高密度，例如計算資源，並降低這些元件的成本。
使用水準分割的部署，您必須採用自動化程式來部署和管理多租使用者應用程式的服務，特別是單一租使用者所使用的服務。
地理區域模式
Geode 模式牽涉到將後端服務的集合部署到一組地理節點。 每個都可以服務任何區域中任何用戶端的任何要求。 此模式可讓您透過分散全球的要求處理，以主動-主動樣式提供要求，藉此改善延遲並增加可用性。
Azure 服務匯流排 和 Azure 事件中樞 支援元數據災害復原、主要和次要災害復原命名空間，以及跨不同區域和可用性區域，以支援最佳的區域內復原能力。 此外，Azure 服務匯流排 和 Azure 事件中樞 實作一組同盟模式，以主動復寫相同的邏輯主題、佇列或事件中樞，以在多個命名空間中取得，最終位於不同的區域。 如需詳細資訊，請參閱以下資源：
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Paolo Salvatori | FastTrack for Azure 首席客戶工程師
其他投稿人：
- John Downs | 主任軟體工程師
- 克萊門斯·瓦瑟斯 |主要架構師、傳訊服務和標準
- Arsen Vladimirskiy | 主任客戶工程師，FastTrack for Azure
下一步
如需傳訊設計模式的詳細資訊，請參閱下列資源：