当你考虑某种多租户体系结构时，需要做出几项决策并考虑某些要素。
在多租户体系结构中，可以在租户之间共享部分或全部资源。 此过程意味着多租户体系结构可以让你节省成本、提高运营效率。 然而，多租户带来了复杂性。 你需要问自己以下问题：
- 对于具体解决方案，如何定义租户的含义？ 一个租户是对应于一个客户、一个用户，还是一组用户（如一个团队或家庭）？
- 如何部署基础结构以支持多租户，以及你在租户之间有多少隔离？
- 解决方案将提供哪些商业定价模型，定价模型如何影响多租户要求？
- 在性能、复原能力、安全性和合规性要求（如数据驻留）等方面，你需要为租户提供什么级别的服务？
- 你计划如何发展业务或解决方案？ 它会扩展到你期望的租户数量吗？
- 你的任何租户是否有不寻常的或特殊的要求？ 例如，你最大的客户是否需要比其他客户更高的性能或更强的保证？
- 你将如何监视、管理、自动执行、缩放和治理 Azure 环境，以及多租户将如何影响管理策略？
- 解决方案的哪些组件可处理租户加入和管理，应如何设计这些组件？
无论体系结构是什么，都必须清楚地了解客户或租户的要求。 如果你已向客户做出销售承诺，或者需要满足合同义务或合规性要求，则在架构解决方案时需要知道这些要求是什么。 但同样，客户可能对解决方案的运作方式或你的行为方式有隐含的预期，这可能会影响多租户解决方案的设计方式。
例如，假设你正在构建一个多租户解决方案，该解决方案将出售给金融服务行业的企业。 客户有非常严格的安全要求，他们需要你提供该解决方案使用的每个域名的完整列表，以便可将它添加到防火墙的允许列表。 此要求会影响你使用的 Azure 服务，以及必须在租户之间提供的隔离级别。 他们还要求其解决方案提供最低级别的复原能力。 客户可能存在许多类似的明确或隐含预期，你需要在整个解决方案中考虑到这些预期。
本部分将概述在规划多租户体系结构时应考虑的一些因素、应该得出的要求以及需要做出的一些取舍。
目标受众
本部分提到的文章特别适合首席技术官 (CTO)、架构师和产品经理等技术决策者。 受众还包括独立软件供应商 (ISV) 和开发 SaaS 解决方案的初创公司。 此外，任何使用多租户体系结构的人都应熟悉这些原则和利弊权衡。
后续步骤
为解决方案考虑不同的租户模型。