Architecture 多租户还是多实例？

我正在尝试构建一个基于web的SaaS解决方案，但我遇到了一个问题，我不确定是否要使用多租户或多实例。我将试着描述我试图实现的目标，以及每种方法的优缺点（根据我所读的内容，我的观点）。请提供您的建议，以防我在一种方法中遗漏了任何内容

正如我所提到的，我试图构建的应用程序是一个SaaS解决方案，公司可以在其中创建自己的帐户，每个帐户/公司都有自己的用户、客户、产品、服务……等等。每个用户；谁是公司员工；与一个账户/公司相关的信息只能访问其公司客户、产品和服务。公司可以拥有无限数量的客户、产品和服务，因此每个公司都应该有自己的数据中心

为此，我决定创建一个共享数据库（保存所有用户凭据以供登录）和多个数据库共享模式（每个帐户/公司的数据库）。基本上，多租户

然后有人建议使用多实例，每个公司都有自己的应用程序实例（即代码、库、数据库、框架等），与其他公司完全分离。这听起来更好，因为我不需要额外考虑一层，我需要确保每个租户的用户只能访问他们公司的数据。我想最好提到我依靠它来实现这种方法（我以前从未使用过），但我认为它缺少我将来需要的功能（稍后会有更多的功能）（至少我没有通过一点搜索找到它们）

然而，每种方法都有利弊，所以我无法决定采用哪种方法。这里有一个列表，但请耐心听我说，因为我对这两种方法都缺乏了解，所以可能有一些我不知道的东西，或者是我在网上没有找到的问题的解决方案：[每种方法都有一个有序的列表，我会逐一比较]

多租户：

共享主机/硬件、共享代码和多数据库

扩展代码的功能和修复bug（共享代码）更容易

要扩展硬件（可以使用云服务），或者在不更改代码的情况下将单个租户的数据库移动到另一个系统，难度更大

最重要的是，正如我前面提到的，我需要在系统中添加一个额外的层，以确保用户实际上属于他/她的公司，而不是访问其他公司的信息

多实例：

共享或非共享主机/硬件、每个实例的代码和每个实例的数据库

扩展功能或修复bug更加困难（我不确定是否有办法在Docker中实现这一点，在Docker中，您可以将功能/特性添加到一个实例或Docker容器中，并将其部署到其他实例或容器中）

将整个实例移动到不同的主机/硬件更容易

作为实例，我不需要处理该层，因为每个实例都有自己的数据库

如果我想手动执行任何操作（例如手动为每个租户创建一个实例），那么所有的优点和缺点都是多余的，这就是为什么我怀疑Docker解决方案，除非有解决方法，这可能是问题的主要原因。如果您能回答这个问题并参考解决方案，我将不胜感激。为什么您认为这种方法比另一种更好

---

如果这有帮助的话（也许？），我们将使用它作为后端的主要框架（都是RESTfull）。

其他人以前也有过这些问题。外面有一种东西叫。我认为大多数成功的模型首先是从功能开始的，其次是平台。因此，我将首先使用每个客户的一个实例策略。不管怎样，一开始会有多少客户？是因为客户不喜欢该功能，还是因为您使用的多个实例当然会带来ops开销，所以失败的可能性更大

=>首先关注产品/功能。因此，瞄准第1级，稍后关注其他级别

对于Docker（至少从我个人的角度来看，这并没有做太多）：您开发的工件是一个可运行的容器映像。当此工件发布到存储库时，更新所有实例以使用此新工件应该非常容易。因此，通过编写一点脚本或者类似的东西，将大量实例移动到新版本应该是可行的。所以我认为像Docker这样的新开发确实使多实例设置更加可行

我还在为我们公司做SaaS产品。对于我们来说，由于业务问题，它也是多实例的：

我们的客户非常希望将数据与竞争对手分开。使用多实例策略更容易显示这一点

客户有时希望对发布周期进行一些控制。例如，他们必须向员工传达功能更改，或者正在进行不允许升级的业务流程。因此，他们可能想等待一个新版本，甚至跳过它。同样，使用每个客户一个实例更容易

---

和往常一样，我在这里给出我的观点和经验。这实际上取决于您的用例—SaaS有很多种类。

如果每个客户都想要共享模式，您不需要为他们提供不同的数据库。大多数SaaS软件是多租户的，并以这种方式工作，这是一个带有应用程序逻辑的公共数据库，以确保用户只能访问他们应该被允许访问的内容。例如，Facebook没有数十亿个数据库，每个用户一个，以确保我们看不到对方的非公开照片

还有，你正在尝试的问题