This topic created in 635 days ago, the information mentioned may be changed or developed.
假如我呀开发一个 saas 的项目,大概有 1000 家商户入驻。
```模式一
大家都用同一个数据库、同一个服务、同一个域名。
优势:代码部署、数据库管理都方便
劣势:数据库层面,大商户数据影响小商户,数据查询、服务并发等
模式二
每个商户创建独立数据库、独立的服务、独立的二级域名
优势:隔离互不影响,(数据、服务)
劣势:管理不方便
```
有没有开发过 saas 服务的项目,给分享分享底层的架构设计。
21 replies 2024-08-17 18:56:43 +08:00  | | 1 ZeawinL Aug 15, 2024 via iPhone 能不能跑?能不能创造价值长期运行? 设计哲学是并不完美, 但仍然有用。 |
 | | 4 flmn Aug 15, 2024 还是要结合业务场景,可能 1 、2 结合起来是更有扩展性的方案。 |
 | | 5 xiaogu2014 Aug 15, 2024 不会用模式二的。针对于第一个模式一的问题。可以开发两套系统。ka 和 smb 。两者的需求本来就不一样。 |
 | | 7 qhkobold Aug 15, 2024 就我的理解来说,你本身要做 saas 的话,那按照你的模式二来做,后期的维护 发版会恶心死人。 至于你模式一的问题,从技术层面来说你是可以都要的,一个配置服务,配置不同客户的数据库连接信息,然后操作服务做连接缓存,可以做到不同租户同库同表、异库,针对 pg 数据库还能做到同库不同 schema 的配置, 至于模式一的服务并发问题,则考虑将出现并发的部分提取为微服务,实现动态扩容 |
 | | 8 chenjiasange Aug 15, 2024 直接模式一,别搞什么租户隔离,后期商户与用户量多起来了,可以根据商户 ID 进行拆分表;目前我们现在就在 saas 行业。一线开发。。。苦逼的很。一定要说服你领导用模式一,不然苦的还是你们开发,同时维护成本低。 |
 | | 9 isSamle Aug 15, 2024 对大客户用二,其他尾部客户用一 |
 | | 10 csys Aug 15, 2024 1. 如果你的服务没有到一定规模,用模式一没有问题 2. 如果你的服务到了一定规模,那请直接选用可水平伸缩的数据库,比如 Cosmos 等,或者做数据分区+高可用方案
模式二的使用情况只有一种:你的重要客户不多,但是它们很重要,我只见过一个做 saas 的公司是用的模式二,就是类似这种情况 |
 | | 12 nextvay Aug 15, 2024 前公司做 Saas 项目 前期 不同 DB 实例+共用服务 后台 不同 DB 实例+独立部署,完全独立
现在公司做 Saas 项目 同实例不同库+共用服务
为啥?因为穷。。。。。 |
 | | 14 salmon5 Aug 15, 2024 模式二:一块钱的生意,投入十块钱。 |
 | | 15 wu00 Aug 15, 2024 老系统用的方案二,当时吵着闹着要重点支持独立部署,结果一个独立部署的都没。 后来全面重构,用了方案一,结果有一个商户要独立部署,哈哈哈。 |
 | | 16 salmon5 Aug 15, 2024 用 SaaS 的用户本质是省钱,模式二感情投入的钱不是自己的。 |
 | | 17 szzadkk Aug 15, 2024 目前用的 1 ,开发维护起来都比较方便,大客户数据量、请求量大,QPS 高,相应的要分库分表弹性扩容什么的,按需求来,而且要多收钱覆盖这部分成本。对于超大规模客户,与其使用 2 ,不如直接建议私有部署了 |
 | | 18 ClericPy Aug 15, 2024 路过,这种场景 Serverless tidb 能打不能打 |
 | | 20 RandomJoke Aug 16, 2024 就用模式一,保证每张表上有 字段可以区分,方便迁移出来就行了。大客户一般会考虑独立部署或者私有部署。 |