我正在尝试构建基于Web的SaaS解决方案，并且我遇到了一条我不确定使用多租户或多实例的道路。我将尝试描述我想要实现的目标，以及每种方法的优点和缺点（我的观点，根据我所读到的）。请提供您的建议，以防我错过任何一种方法而不是另一种方法。
正如我所提到的，我正在尝试构建的应用程序是一个SaaS解决方案，公司可以在其中创建帐户，每个帐户/公司都拥有自己的用户，客户，产品，服务等。每个用户;谁是公司员工;与一个帐户/公司相关的只能访问他/她公司的客户，产品和服务。公司可以拥有无限数量的客户，产品和服务，因此每家公司都应拥有自己的数据中心。
为此，我决定创建一个共享数据库（为登录目的保存所有用户凭据）和多个数据库共享模式（每个帐户/公司的数据库）。基本上，多租户。
然后有人建议使用多实例，其中每个公司都有自己的应用程序实例（即代码，库，数据库，框架等）与其他公司完全分离。这听起来更好，因为我不需要处理额外的层，我需要确保每个租户的用户只能访问他们公司的数据。我认为值得一提的是，我依靠 Docker 来实现这种方法（我之前从未使用过它），但我认为它缺乏功能（后面会有更多内容）我将来需要（至少我没有通过一点点搜索找到它们）。
然而，每种方法都有利有弊，所以我无法决定采用哪种方法。这是一个列表，但由于我缺乏对它们的了解，所以我可能会遇到一些我不知道的事情，或者是我在网上找不到的问题的解决方案：[每种方法都有一个有序的清单，我跟着一个一个比较]
多租户：
多重实例：
如果我想手动执行任何操作（因为手动为每个租户创建实例），所有优点和缺点都是多余的，这就是我怀疑Docker解决方案的原因，除非有办法解决这个问题，这是也许是问题的主要原因。如果你能回答这个问题并提到解决方案，我将不胜感激，为什么你认为这种方法比另一方更好。
如果有帮助（可能？），我们使用Laravel作为后端的主要框架（所有RESTful）。
答案 0 :(得分：7)
如果每个客户都要拥有共享模式，那么您不需要不同的数据库。大多数SaaS软件都是多租户，并以这种方式工作，这是一个带有应用程序逻辑的通用数据库，可确保用户只能访问应该允许访问的内容。例如。 Facebook没有数十亿个数据库，每个用户一个数据库，以确保我们无法看到彼此的非公开照片。
此外，您尝试解决的问题似乎与应用程序的可移植性或移动到云端的能力有关。如果你treat backing services, e.g. database(s), as attached resources那么，如果你有一个或多个（实际上我仍然建议你只有一个），这并不重要。
我建议您阅读12-factor principles以进行SaaS开发和部署。它们是思考构建软件的一个很好的起点，这些软件可以在云原生环境中轻松工作。我将专注于解决您的软件的业务问题，并以云原生的方式构建它，例如根据12因素原则。
您所描述的问题没有任何内容表明Docker与非Docker在此时甚至是一个相关问题。即所有提议的方法都可以使用/不使用Docker来完成。 Docker解决了进程隔离，打包操作系统级依赖关系，减少计算资源开销，开发和生产之间的一致性等问题，并且只与您所追求的内容间接相关。
答案 1 :(得分：3)
其他人以前遇到过这些问题。例如。那是......在那里叫SaaS Maturity Model。我认为大多数成功的模型都是先从功能开始，然后是平台作为次要问题。所以我会首先考虑每个客户策略的实例。无论如何，一开始会有多少客户？它是否更有可能失败，因为客户不喜欢这个功能，或者因为你正在使用多个实例当然会带来操作开销？
=＆GT;首先关注产品/功能。所以瞄准1级，稍后关注其他级别。
使用Docker（至少在我看来，作为一个人，它没有做很多事情）：你的开发工件是一个可运行的容器图像。将此工件发布到存储库时，应该可以非常轻松地更新所有实例以使用此新工件。所以用一点脚本，也许是某事。像Kubernetes一样，将大量实例移动到新版本应该是可行的。所以我认为像Docker这样的新开发确实使多实例设置更加可行。
我正在为我们公司做一个SaaS产品。对于我们来说，由于业务问题，它也是多实例：
就像这些问题一样，我在这里给出了我的观点和经验。这实际上取决于您的使用案例 - SaaS有很多种。
答案 2 :(得分：3)
多租户是可行的方式，它具有成本效益且更易于维护。想象一下，您在10个不同版本的应用程序中拥有10个客户，支持它们变得非常重要。使用多租户，您可以根据负载自动扩展，并在负载较小时缩小，使用多实例时，您可能必须确保每个客户至少有一个实例可用。
为什么我会选择多租户