多租户或多实例？

我试图构建一个基于Web的SaaS解决方案，但遇到了不确定使用多租户或多实例的道路。我将尝试描述我要实现的目标，以及每种方法的优缺点（根据我的阅读，我的观点）。请提出您的建议，以防万一我错过了其他任何方法。

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

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

然后有人建议使用多实例代替，每个公司将有自己的应用程序实例（即代码，库，数据库，框架等），与其他公司完全分开。这听起来更好，因为我不必在需要确保每个租户的用户只能访问其公司数据的额外层上打理。我认为值得一提的是，我依靠Docker来实现这种方法（我以前从未使用过），但是我认为它缺乏将来我将需要的功能（以后会更多）（至少我没有这样做）。一点点搜索就找不到它们）。

但是，每种方法都各有利弊，因此我无法决定采用哪种方法。这是一个列表，但由于我对它们都不了解，所以对我几乎一无所知，因此可能存在一些我不知道的问题，或者是针对我在网上找不到的问题的解决方案：[每种方法都有我跟着一个一个的比较的有序列表]

多租户：

1. 共享的主机/硬件，共享的代码和多数据库。
2. 这是容易扩展的代码并修复错误的功能（共享代码）。
3. 在不更改代码的情况下，很难扩展硬件（可以使用云服务）或将单个租户的数据库移至另一个系统。
4. 最重要的是，如前所述，我需要在系统中添加一个额外的层，以确保用户实际上属于他/她的公司，而不访问其他公司的信息。

多实例：

1. 共享或不共享的主机/硬件，每个实例的代码以及每个实例的数据库。
2. 这是很难扩展功能或修复的错误（我不知道是否有办法做到这一点在码头工人在那里你可以添加功能/特性，以一个实例或码头集装箱，并将其部署到其他人）。
3. 这是更容易对整个实例移动到不同的主机/硬件。
4. 作为实例，我不需要照顾该层，因为每个实例将拥有自己的数据库。

万一我想手动做任何事情（例如为每个租户手动创建一个实例），所有的优点和缺点都是多余的，这就是为什么我怀疑Docker解决方案的原因，除非有一种解决方法，这也许是主要的问题的原因。如果您能通过参考解决方案来回答问题，以及为什么您认为这种方法比其他方法更好，我将不胜感激。

如果有帮助（也许？），我们使用Laravel作为后端的主要框架（全部为RESTful）。

我现在问自己完全相同的问题。

我倾向于多实例单租户解决方案，但尚未做出明确的决定。让我分享一些想法：

多租户体系结构的主要历史优势是可以通过相互交互（单个OS，单个数据库，单个应用程序层）更好地利用基础结构资源，并更好地占用所述资源（当一个用户不在时另一个用户可以使用相同的资源） 。

它还极大地简化了软件生命周期：将一个新版本部署到一个实例中，同时更新所有客户。

但是，似乎云技术的最新发展使第一类优势在多实例（每个客户的实例）体系结构中大体上都可以使用（我在这里特别考虑的是Jelastic这样的平台，但我敢肯定还有其他优势提供相同的功能）：

• 基于容器的PaaS
• 调配和自动缩放容器（弹性容器）

因此，硬件和平台管理不再是软件提供商的关注点。在基础架构和平台级别，资源的交互比以前更加有效。

多实例仍然会有开销（某些应用程序和中间件将运行N次而不是一次），但比每个实例使用单独的（虚拟）机器要低得多。无论如何都可以共享数据库（每个实例一个模式，每个数据库服务器几个模式）

另外：

• 通过PaaS API可以自动创建新实例
• 通过PaaS API可以自动部署新版本，停机时间为零（需要进行一些工作）
• 缩放总是输出，永远不会增长。我们不必担心实例级别的庞大数据集。

当然，我们需要某种中央服务来自动管理所有这些（例如，当新用户创建帐户时创建实例）。这也将管理付款和许可问题，实例之间的交互等。此中央服务可能非常复杂且难以开发，但是好处是我们不必提前实施它（现在我们没有太多东西了）资源），而从一开始就需要将多租户纳入应用程序。

这使我获得了在早期（投资前）启动项目中开发单租户的最终优势：

• 可以将应用程序的相同（或几乎相同）版本作为虚拟设备或Docker容器在本地部署，甚至可以在客户管理的机器上部署（某些公司仍然不愿意使用Cloud，这可能有助于早期启动而不是推出重要的早期采用者）
• 更快地以有限的资源推出产品（应用程序层和数据库架构不太复杂），可以为早期采用者首先推出“哑”单实例单租户产品（MVP），并展示应用程序的业务价值给潜在的投资者，并在以后添加所有云自动化
• 可以将其视为担心数据安全性的客户的一个推销论据：由于每个客户都有自己的架构甚至数据库，因此可以更好地封装数据。“溢漏”的风险要小得多

注意：我在这里显然是在考虑一个商业应用程序，其中客户将是企业（每个都有多个个人用户）而不是个人。为每个用户单独运行一个应用程序实例是没有任何意义的（或者是？）

支持这两种选择也是可能的（跨多个实例的租户池）。

我赞成自然隔离的多实例原因。每个客户的实例都在其自己的流程中运行，并且其数据隔离在其自己的数据库中。您可以根据需要按每个客户/实例将实例升级到新版本。

基于租户的系统存在信息安全风险。只需考虑忘记“ WHERE tenantId = x”子句是多么容易。使用支持租户的系统的主要原因是性能，流程繁重，通过共享一个流程，您可以从一台机器上获得更多收益。我认为，在32位环境中，情况更是如此，如今在64位计算机上具有更多的RAM。

多实例系统可能需要更多工具来创建和配置环境，例如数据库和Web应用程序实例。有人可能会说您还需要针对单实例部署编写此脚本。这样做还有其他好处，例如可以设置开发和测试环境

在您找到理由之前，我将不考虑租户功能（工程成本与通过流程共享在（硬件）基础架构上节省的资金）。