多租户或多实例? [英] Multi tenancy or multi instance?

问题描述

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

I'm trying to build a web-based SaaS solution, and I hit a road where I'm not sure to use multi tenancy or multi instance. I will try to describe what I'm trying to achieve, and each approach advantages and disadvantages (my opinion, according to what I read). Please include your suggestions in case I missed anything in one approach over the other.

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

The application that I'm trying to build is, as I mentioned, a SaaS solution where companies can create their accounts, and each account/company has it's own users, customers, products, services...etc. Each user; who is a company employee; related to one account/company will have access only to his/her company customers, products, and services. Companies could have unlimited number of customers, products and services, thus each company should have it's own data center.

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

For that I decided to create a shared database (saving all users credentials for login purposes) and multiple databases shared schema (database per account/company). Basically, Multi Tenancy.

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

Then somebody suggested to use Multi Instance instead, where each company will have its own instance of the application (i.e. code, libraries, database, frameworks... etc) totally separated from the other companies. This sounds better as I don't have to take care of an extra layer where I need to make sure that each tenant's users have access only to their company's data. I think it's good to mention that I'm depending on Docker to achieve this approach (I've never used it before), but I think it lacks features (more on those later) I will need in the future (at least I didn't find them with a little bit of search).

但是，每种方法都各有利弊，所以我无法决定采用哪种方法.这是一个列表，但是请耐心等待，因为我俩都不具备这些知识，因此可能会有一些我不知道的问题，或者是我在网上找不到的问题的解决方案:[每种方法都有我跟着一个比较的有序列表]

However, each approach comes with pros and cons, so I couldn't make a decision with which approach to go. Here is a list, but bear with me as I lack the knowledge in them both, so there could be something that I'm not aware of, or a solution for a problem I didn't find on the web: [Each approach has an ordered list of which I followed a one by one comparison]

多租户:

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

1. Shared host/hardware, shared code, and multi database.
2. It's easier to extend the functionality of the code and fix bugs (shared code).
3. It's harder to extend the hardware (could use a cloud service), or move the database of individual tenant to another system without doing changes to the code.
4. Most importantly, as I mentioned before, I need to add an extra layer to the system to make sure that the user is actually belongs to his/her company, and not accessing other company's information.

多实例:

1. 共享或不共享的主机/硬件，每个实例的代码以及每个实例的数据库.
2. 扩展功能或修复错误更困难(我不确定在Docker中是否有一种方法可以在其中向一个实例或Docker容器添加功能/功能，以及部署给其他人).
3. 将整个实例移动到其他主机/硬件很容易.
4. 作为实例，我不需要照顾该层，因为每个实例都有自己的数据库.

1. Shared or unshared host/hardware, code per instance, and database per instance.
2. It's harder to extend the functionality or fix bugs (I'm not sure if there is a way to do it in Docker where you can add functionality/feature to one instance or Docker container, and deploy it to the others).
3. It's easier to move the whole instance to a different host/hardware.
4. As the instance, I don't need to take care of that layer as each instance will have its own database.

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

All of the advantages and disadvantages are redundant in case I want to do anything manually (as creating an instance for each tenant manually), and that's why I doubt the Docker solution, unless there is a way to solve that, which is maybe the main reason of the question. I would appreciate it if you would answer the question with references to the solutions, and why do you think this approach is better than the other.

如果有帮助(也许?)，我们使用 Laravel 作为背面的主要框架-end(全部为RESTfully).

In case that would help (maybe?), we're using Laravel as the main framework for the back-end (all RESTfully).

推荐答案

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

You don't need different databases for each customer if they are going to have shared schemas anyways. Most SaaS software is multi-tenant and works in this fashion, a common database with application logic to make sure users can only access things they should be allowed to access. E.g. Facebook doesn't have billions of databases, one for each user, to make sure we can't see each other's non-public photos.

此外，您要解决的问题似乎与应用程序的可移植性或将它们移至云的能力无关.如果您处理支持服务，例如数据库，作为附加资源，那么您是否拥有一个或多个并不重要(尽管我仍然建议您只有一个).

Also, the problems you're trying to solve for don't seem as though they should have any bearing on the portability of your application, or your ability to move them to the cloud. If you treat backing services, e.g. database(s), as attached resources then it doesn't really matter if you have one or many (though I still recommend you have just the one).

我建议阅读有关SaaS开发和部署的 12要素原则.它们是考虑构建可在云原生环境中轻松工作的软件的一个很好的起点.我会专注于解决您软件的业务问题，并以云原生的方式(例如，按照12要素原则.

I'd recommend reading the 12-factor principles for SaaS development and deployment. They are a great starting point for thinking about architecting software that will work easily in a cloud-native environment. I would focus on solving the business problems of your software, and architecting it in a cloud-native way, e.g. per the 12-factor principles.

关于您所描述的问题的任何内容都表明，此时Docker与非Docker甚至是一个相关问题. IE.使用/不使用Docker，所有您提议的方法都可以非常相似地完成. Docker解决了进程隔离，打包OS级依赖关系，减少计算资源开销，开发与生产之间的一致性等问题，并且似乎仅与您所追求的目标间接相关.

Nothing about the problems you've described suggest that Docker vs. not-Docker is even a relevant concern at this time. I.e. all your proposed approaches could be done fairly similarly with/without Docker. Docker solves problems of process isolation, packaging OS-level dependencies, reducing compute resource overhead, consistency between development and production, etc. and only seems indirectly related to what you're after.

这篇关于多租户或多实例?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！