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