支持多租户

将单租户应用程序转换为多租户应用程序时会遇到哪些典型挑战？安全性和数据隔离使我感到最重要。还有什么？

我是从事相当大的自动化工作的架构师之一，从历史上看，这只是我们公司在使用它。我们希望其他人也可以使用它。每次我们谈论“使其成为多租户”时，讨论都围绕使一个租户的用户远离另一租户拥有的数据，并确保拥有一个租户的用户不能（有意或无意）对另一租户产生影响租户的环境。我想知道的是，安全/数据隔离是否真的是这里唯一的主要问题，还是我们只是没有在考虑其他一些主要问题。

除了孤立数据之外，您可能还会遇到以下问题

1. 可用性-一个租户，他们只能自己进行DoS，但是即使数据被正确隔离，租户仍会耗尽资源。
2. 日志记录-所有日志消息均假定为一个租户。除非您为每个租户分配孤岛日志，否则日志消息可能会变得用处不大。
3. 并发性-单个租户应用程序可能在中等负载下运行，或者争用一些锁的高争用可能会有效地序列化某些操作。如果每个租户的锁倍增，您可能会开始看到以前从未发生过的操作交错。极不可能出现的比赛条件现在可能会出现。
4. 资源争用的新来源-在以前可能有n个套接字和m个文件句柄的位置，现在将每个租户相乘。
5. 可配置性/向后兼容性的折衷-在您推出替换组件之前可以过时的组件之前，现在可能有一个租户要求一个组件，而一个租户要求其替换的旧组件无限期地存在。
6. 传票目标-当前，您是与公司相关问题的传票目标。对于多租户，即使您不是法律诉讼的当事方，您也可能必须响应传票请求。

其中一些假设您正在同一地址空间（计算机或群集）中运行所有租户。如果每个租户都在其硬件上运行您的软件，则可以对上述内容进行模拟并添加：

1. 难以访问机器进行调试。
2. 对较旧版本的支持请求。
3. 请求允许第三方承包商进行配置。
4. 对其运行的硬件的控制较少。
5. 对其运行的操作系统的补丁/更新周期的控制较少。

我认为多租户中最大的问题是定制。如果要向企业出售业务应用程序，通常会发生这种情况。它的范围从简单到每个客户都希望拥有自己的皮肤的能力到配置其他字段，规则，表单和报告的能力。您需要支持的定制级别在体系结构中至关重要。

Mike的回答非常好，由于其中的简短程度，那里的许多要点几乎掩盖了它们的复杂性，因此请牢记这些。

我要补充的一点是，您应该具有用于​​创建（以及以后管理）新租户的良好管理工具。根据您所使用的物理体系结构，这可能并非易事，并且经常被忽略。仅当有大量租户时，软件即服务产品的好处才会真正发挥作用，因此应为此付出相当大的努力。

扩展斯里拉姆的答案；严格禁止按租户自定义，租户可能要更改的所有内容都应该是可配置的。例如，如果您的解决方案不能满足至少几个关键领域中动态添加数据字段的需求，那么您可能会被大量的自定义请求所困扰。这是为数不多的情况下，一点点额外的复杂性的前期不实际还清一个（让我们说这违背了YAGNI，或至少，这一级别的配置几乎是一个关键要求，所以你是要去需要它）。