多租户还是多实例？
我正在尝试构build一个基于Web的SaaS解决scheme，并且我走上了一条不确定使用多租户或多实例的道路。 我会试图描述我想要达到的目标，并且每种方法都有其优点和缺点（根据我的看法，我认为）。 请包括您的build议，以防万一我错过了任何一种方法。
正如我所提到的那样，我正在尝试构build的应用程序是一个SaaS解决scheme，在这个解决scheme中，公司可以创build他们的账户，而每个账户/公司都有自己的用户，客户，产品，服务等等。 每个用户; 谁是公司员工; 与一个帐户/公司相关的用户只能访问其公司客户，产品和服务。 公司可以拥有无限数量的客户，产品和服务，因此每个公司都应该拥有自己的数据中心。
为此，我决定创build一个共享数据库（保存用于login的所有用户凭据）和多个数据库共享模式（数据库每个帐户/公司）。 基本上， 多租户 。
然后有人build议使用多实例 ，而每个公司将有自己的应用程序实例（即代码，库，数据库，框架等）与其他公司完全分开。 这听起来更好，因为我不需要照顾额外的层，我需要确保每个租户的用户只能访问其公司的数据。 我认为我很高兴提到我依靠Docker来实现这个方法（我以前从来没有用过），但是我认为它将来还需要一些function（以后会详述）（至less我没有用一点searchfind他们）。
然而，每种方法都有利弊，所以我无法决定采用哪种方法。 这里列出了一个列表，但是由于我缺乏两者的知识，所以可能会有一些我不知道的东西，或者是一个我在网上找不到的问题的解决scheme：[每种方法都有一个有序的清单，我跟着一个一个的比较]
多租户 ：
- 共享主机/硬件，共享代码和多个数据库。
- 扩展代码的function并修复错误（共享代码） 更容易 。
- 扩展硬件（可以使用云服务）比较困难 ，或者将个体租户的数据库移动到另一个系统，而无需更改代码。
- 最重要的是，正如我之前提到的，我需要为系统添加一个额外的层，以确保用户实际上属于他/她的公司，而不是访问其他公司的信息。
多实例 ：
- 共享或非共享主机/硬件，每个实例的代码和每个实例的数据库。
- 很难扩展function或修复错误（我不确定在Docker中是否有一种方法可以将function/特性添加到一个实例或Docker容器中，并将其部署到其他）。
- 将整个实例移动到不同的主机/硬件更容易 。
- 作为实例，我不需要照顾那层，因为每个实例都有自己的数据库。
所有的优点和缺点是多余的，因为我想手动执行任何操作（为每个租户手动创build实例），这就是为什么我怀疑Docker解决scheme，除非有办法解决这个问题，这可能是主要的问题的原因。 如果您能够参考解决scheme回答问题，我将不胜感激，您为什么认为这种方法比其他方法更好？
如果这可能会有帮助（也许？），我们使用Laravel作为后端（所有RESTfully）的主要框架。
对于每个客户，如果要共享模式，则不需要使用不同的数据库。 大多数SaaS软件都是多租户的，并且以这种方式工作，这是一个具有应用程序逻辑的通用数据库，用于确保用户只能访问应该允许访问的内容。 例如，Facebook没有数十亿个数据库，每个用户都有一个数据库，以确保我们看不到彼此的非公开照片。
另外，您试图解决的问题看起来好像不应该影响应用程序的可移植性，或者将其移到云中的能力。 如果你把支持服务，比如数据库，作为附加资源，那么你是否有一个或者多个（尽pipe我还是build议你只有一个）并不重要。
我build议阅读SaaS开发和部署的12因子原则 。 对于构build可在云原生环境中轻松工作的软件，这是一个很好的起点。 我将专注于解决软件的业务问题，并以云原生的方式构build，例如按照12因子原则。
你所描述的问题没有任何事情表明，Docker与非Docker甚至是相关的问题。 也就是说，所有build议的方法都可以在没有Docker的情况下进行。 Docker解决了进程隔离，打包操作系统级依赖关系，减less计算资源开销，开发和生产之间的一致性等问题，而且似乎只是间接与你所追求的内容有关。
其他人之前有过这些问题。 例如有某事 那里叫做SaaS成熟度模型 。 我认为大多数成功的模式都是从function开始的，而平台则是次要的。 所以我会首先为每个客户策略提供一个实例。 无论如何，一开始会有多less客户？ 是否更有可能失败，因为客户不喜欢function，或者因为您使用多个实例来运行一个操作系统开销？
首先关注产品/function。 因此，瞄准1级，稍后关注其他级别。
有了Docker（至less从我的angular度来看，作为一个人，这并没有做很多）：你的发展的神器是一个可运行的容器图像。 当此工件发布到存储库时，更新所有实例以使用此新工件应该非常容易。 所以有了一点脚本，或许…… 像Kubernetes ，应该可以将很多实例移动到新版本。 所以我认为像Docker这样的新发展让多实例设置更加可行。
我也为我们公司做了一个SaaS产品。 对于我们来说，由于商业上的担忧，
- 我们的客户非常希望将数据与竞争对手分开。 多实例策略更容易展现。
- 客户有时想要对发布周期进行一些控制。 例如，他们必须向员工传达function变化，或者业务stream程正在进行，不允许升级。 所以他们可能想等一个新版本，甚至跳过它。 每个客户的实例再次更容易。
和往常一样，我在这里给出我的看法和经验。 这真的取决于你的用例 – SaaS有很多种类。
多租户是走的路，它是成本效益和更可维护的。 想象一下，你在10个不同版本的应用程序上有10个客户，支持他们就成了大问题。 借助多租户，您可以根据负载进行自动调整，并在负载较小时进行调整，多个实例可能必须确保每个客户至less有一个实例可用。
为什么我要用多租户去其他几个原因
- 一个版本来build立和部署
- 共享资源，如caching
- 只testing一个版本的应用程序
- 安全testing将被简化
- 有效利用CDN