當您考慮多租使用者架構時，您需要進行數個決策，以及需要考慮的元素。
在多租用戶架構中，您可以與租用戶共用某些或全部的資源。 此流程表示多租用戶架構可提供成本和作業效率。 然而，多租用戶會增加複雜程度，包括下列事項：
- 如何為特定解決方案定義 租 使用者是什麼？ 租用戶是否對應至客戶、使用者或一群使用者 (類似小組)？
- 您會如何部署基礎結構以支援多租用戶，以及在租用戶間保持多少隔離？
- 您的解決方案會提供哪些商業定價模型，以及您的定價模型如何影響您的多租使用者需求？
- 您需要提供租用戶何種等級的服務？ 請考慮效能、復原、安全性和合規性需求，如資料落地。
- 您預計如何拓展業務或解決方案，並將其調整為預期的租用戶數量？
- 租用戶是否有不尋常或特殊的需求？ 例如，最大的客戶是否需要比其他客戶更高的效能或更好的保證？
- 您會如何監視、管理、自動化、調整和治理 Azure 環境，以及多租用戶是否會有影響？
- 解決方案的哪些元件會處理租使用者上線和管理，以及如何設計這些元件？
規格需求
無論您的架構為何，您都必須清楚瞭解客戶或租使用者的需求。 如果您已對客戶提出銷售承諾，或您有合約義務或合規性需求要符合，則當您建構解決方案時，必須知道這些需求是什麼。 但同樣地，您的客戶可能會隱含地預期 應該 如何運作，或 應該 如何運作，這可能會影響您設計多租使用者解決方案的方式。
例如，假設您正在建置多租使用者解決方案，以銷售給金融服務產業中的企業。 您的客戶有非常嚴格的安全性需求，而且您需要提供解決方案使用之每個功能變數名稱的完整清單，讓他們可以將它新增至防火牆的允許清單。 此需求會影響您使用的 Azure 服務，以及租使用者之間必須提供的隔離等級。 他們也需要其解決方案具有最低層級的復原能力。 您可能需要在整個解決方案中考慮許多類似的預期，包括明確和隱含。
在本節中，我們會概述您應該給予的考慮、您應該提出的需求，以及您在規劃多租使用者架構時所需的一些取捨。
目標對象
本節中的文章特別與技術決策者相關，例如技術長 (CTO) 和架構設計人員，以及產品經理。 物件也包含獨立軟體廠商 (ISV) 和開發 SaaS 解決方案的啟始者。 此外，任何使用多租使用者架構的人員都應該熟悉這些原則和取捨。
下一步
請考慮解決方案的不同 租用模型 。