多租户还是多实例？

Question

我正在尝试构建基于Web的SaaS解决方案,并且我遇到了一条我不确定使用多租户或多实例的道路.我将尝试描述我想要实现的目标,以及每种方法的优点和缺点(我的观点,根据我所读到的).请提供您的建议,以防我错过任何一种方法而不是另一种方法.

正如我所提到的,我正在尝试构建的应用程序是一个SaaS解决方案,公司可以在其中创建帐户,每个帐户/公司都拥有自己的用户,客户,产品,服务等.每个用户; 谁是公司员工; 与一个帐户/公司相关的只能访问他/她公司的客户,产品和服务.公司可以拥有无​​限数量的客户,产品和服务,因此每家公司都应拥有自己的数据中心.

为此我决定创建一个共享数据库(为登录目的保存所有用户凭据)和多个数据库共享模式(每个帐户/公司的数据库).基本上,多租户.

然后有人建议使用Multi Instance,其中每个公司都有自己的应用程序实例(即代码,库,数据库,框架等)与其他公司完全分开.这听起来更好,因为我不需要处理额外的层,我需要确保每个租户的用户只能访问他们公司的数据.我认为值得一提的是我依赖Docker来实现这种方法(我之前从未使用过它),但我认为它缺乏功能(后面会更多)我将来需要(至少我没有通过一点点搜索找到它们.

但是,每种方法都有利有弊,所以我无法决定采用哪种方法.这是一个列表,但由于我缺乏对它们的了解,所以我可能会遇到一些我不知道的事情,或者是我在网上找不到的问题的解决方案:[每种方法都有一个有序列表,我跟着一个一个比较]

多租户:

1. 共享主机/硬件,共享代码和多数据库.
2. 这是比较容易扩展代码的功能并修复错误(共享代码).
3. 这是很难延长硬件(可以使用云服务),或个别租户的数据库移动到另一个系统没有做修改代码.
4. 最重要的是,正如我之前提到的,我需要在系统中添加一个额外的层,以确保用户实际上属于他/她的公司,而不是访问其他公司的信息.

多实例:

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

如果我想手动执行任何操作(因为手动为每个租户创建实例),所有优点和缺点都是多余的,这就是我怀疑Docker解决方案的原因,除非有办法解决这个问题,这可能是主要的问题的原因.如果您能够通过参考解决方案来回答问题,我将不胜感激,为什么您认为这种方法比其他方法更好.

如果有帮助(可能？),我们使用Laravel作为后端的主要框架(所有RESTful).

Answer 1

如果每个客户要拥有共享模式,则不需要不同的数据库.大多数SaaS软件都是多租户,并以这种方式工作,这是一个带有应用程序逻辑的通用数据库,可确保用户只能访问应该允许访问的内容.例如,Facebook没有数十亿个数据库,每个用户一个数据库,以确保我们无法看到彼此的非公开照片.

此外,您尝试解决的问题似乎并不像应用程序的可移植性或移动到云端的能力有任何影响.如果您将支持服务(例如数据库)视为附加资源,那么如果您有一个或多个(尽管我仍然建议您只有一个),这并不重要.

我建议阅读SaaS开发和部署的12因素原则.它们是思考构建软件的一个很好的起点,这些软件可以在云原生环境中轻松工作.我将专注于解决您的软件的业务问题,并以云原生的方式构建它,例如根据12因素原则.

没有关于你所描述的问题的建议表明Docker与非Docker在这个时候甚至是一个相关的问题.即使用/不使用Docker,所有提议的方法都可以完全相同.Docker解决了进程隔离,打包操作系统级依赖关系,减少计算资源开销,开发和生产之间的一致性等问题,并且只与您所追求的内容间接相关.

Answer 2

多租户是可行的方法，它具有成本效益且更易于维护。假设您有 10 个客户使用 10 个不同版本的应用程序，支持他们变得很重要。对于多租户，您可以根据负载自动扩展并在负载较少时缩减，对于多实例，您可能必须确保每个客户至少有一个实例可用。

我选择多租户的其他几个原因

1. 一个版本来构建和部署
2. 共享资源，如缓存
3. 仅测试应用程序的一个版本
4. 安全测试将被简化
5. 有效利用CDN

Answer 3

其他人以前也遇到过这些问题。例如，有某物。那里被称为SaaS 成熟度模型。我认为大多数成功的模型都是从功能开始的，而平台是次要的。因此，我会首先选择每个客户策略的实例。无论如何，一开始会有多少顾客？它更有可能失败，因为客户不喜欢该功能，还是因为您使用多个实例，当然会带来运营开销？

=> 首先关注产品/功能。因此，以第 1 级为目标，稍后再关注其他级别。

使用 Docker（至少从我作为一个人的角度来看，它并没有做太多事情）：开发的工件是一个可运行的容器镜像。当此工件发布到存储库时，应该很容易更新所有实例以使用此新工件。因此，只需编写一些脚本，也许还有其他东西。像Kubernetes一样，应该可以将大量实例迁移到新版本。因此，我认为像 Docker 这样的新发展确实使多实例设置变得更加可行。

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

1. 我们的客户非常热衷于将数据与竞争对手分开。使用多实例策略更容易显示这一点。
2. 客户有时希望对发布周期有一定的控制。例如，他们必须向员工传达功能的变化，或者正在进行的业务流程不允许升级。因此，他们可能想要等待新版本，甚至跳过它。每个客户都有一个实例，这又容易得多。

与往常一样，对于此类问题，我在这里给出我的意见和我的经验。这实际上取决于您的用例 - SaaS 有很多种。