请教大佬一个 Saas 服务的模式问题？

[longmeier90]

假如我呀开发一个 saas 的项目，大概有 1000 家商户入驻。
```模式一
大家都用同一个数据库、同一个服务、同一个域名。
优势：代码部署、数据库管理都方便
劣势：数据库层面，大商户数据影响小商户，数据查询、服务并发等

模式二
每个商户创建独立数据库、独立的服务、独立的二级域名
优势：隔离互不影响，（数据、服务）
劣势：管理不方便
```
有没有开发过 saas 服务的项目，给分享分享底层的架构设计。

[ZeawinL]

能不能跑？能不能创造价值长期运行？
设计哲学是并不完美, 但仍然有用。

[zen1]

可参考： https://learn.microsoft.com/zh-cn/azure/architecture/guide/multitenant/considerations/tenancy-models
取决于你的服务有多大。大型 saas 服务一般是第一个模式。至于大商户影响小商户，可以与模式二结合使用，也可以分库处理

[mercurylanded]

用 1 ，真有要用到 2 的时候已经发了

[flmn]

还是要结合业务场景，可能 1 、2 结合起来是更有扩展性的方案。

[xiaogu2014]

不会用模式二的。针对于第一个模式一的问题。可以开发两套系统。ka 和 smb 。两者的需求本来就不一样。

[johnwilson]

你说的这个叫租户隔离

[qhkobold]

就我的理解来说，你本身要做 saas 的话，那按照你的模式二来做，后期的维护 发版会恶心死人。
至于你模式一的问题，从技术层面来说你是可以都要的，一个配置服务，配置不同客户的数据库连接信息，然后操作服务做连接缓存，可以做到不同租户同库同表、异库，针对 pg 数据库还能做到同库不同 schema 的配置，
至于模式一的服务并发问题，则考虑将出现并发的部分提取为微服务，实现动态扩容

[chenjiasange]

直接模式一，别搞什么租户隔离，后期商户与用户量多起来了，可以根据商户 ID 进行拆分表；目前我们现在就在 saas 行业。一线开发。。。苦逼的很。一定要说服你领导用模式一，不然苦的还是你们开发，同时维护成本低。

[isSamle]

对大客户用二，其他尾部客户用一

[csys]

1. 如果你的服务没有到一定规模，用模式一没有问题
2. 如果你的服务到了一定规模，那请直接选用可水平伸缩的数据库，比如 Cosmos 等，或者做数据分区+高可用方案

模式二的使用情况只有一种：你的重要客户不多，但是它们很重要，我只见过一个做 saas 的公司是用的模式二，就是类似这种情况

[crysislinux]

给你一个鲜活的例子，Salesforce 够大了吧，他们就是用的方案一 https://architect.salesforce.com/fundamentals/platform-multitenant-architecture

[nextvay]

前公司做 Saas 项目
前期 不同 DB 实例+共用服务
后台 不同 DB 实例+独立部署，完全独立

现在公司做 Saas 项目
同实例不同库+共用服务

为啥？因为穷。。。。。

[horizon]

1
关键词「多租户」

[salmon5]

模式二：一块钱的生意，投入十块钱。

[wu00]

老系统用的方案二，当时吵着闹着要重点支持独立部署，结果一个独立部署的都没。
后来全面重构，用了方案一，结果有一个商户要独立部署，哈哈哈。

[salmon5]

用 SaaS 的用户本质是省钱，模式二感情投入的钱不是自己的。

[szzadkk]

目前用的 1 ，开发维护起来都比较方便，大客户数据量、请求量大，QPS 高，相应的要分库分表弹性扩容什么的，按需求来，而且要多收钱覆盖这部分成本。对于超大规模客户，与其使用 2 ，不如直接建议私有部署了

[ClericPy]

路过，这种场景 Serverless tidb 能打不能打

[salmon5]

@ClericPy #18 ，能打？给自己挖坑

[RandomJoke]

就用模式一，保证每张表上有 字段可以区分，方便迁移出来就行了。大客户一般会考虑独立部署或者私有部署。