https://mp.weixin.qq.com/s/Ktj7uonq_YAPMCwMWpzitQ
对于OCBC 的BASE services，
不同Region：使用了不同数据库。
不同服务：存在共享数据库、独立Schema。
同一个服务的不同Channel（没有做Channel隔离）：比如ms-cust-auth-my和ms-cust-auth-corpmy，共享数据库、共享Schema，共享表。
同一个服务的不同Channel（有做Channel隔离）：比如ms-cust-auth-sg和ms-cust-auth-corpsg，不同数据库，共享Schema（和别的服务），共享表。
方案一：独立数据库模式
优缺点分析
优点：
- • 数据隔离级别最高，安全性最佳
- • 租户可以使用不同的数据库版本或类型
- • 易于实现租户特定的数据库优化
- • 故障隔离，一个租户的数据库问题不影响其他租户
- • 便于独立备份、恢复和迁移
缺点：
- • 资源利用率较低，成本较高
- • 运维复杂度高，需要管理多个数据库实例
- • 跨租户查询困难
- • 每增加一个租户需要创建新的数据库实例
- • 数据库连接池管理复杂
适用场景
- • 高要求的企业级SaaS应用
- • 租户数量相对较少但数据量大的场景
- • 租户愿意支付更高费用获得更好隔离性的场景
方案二：共享数据库，独立Schema模式
优缺点分析
优点：
- • 资源利用率高于独立数据库模式
- • 较好的数据隔离性
- • 运维复杂度低于独立数据库模式
- • 容易实现租户特定的表结构
- • 数据库级别的权限控制
缺点：
- • 数据库管理复杂度增加
- • 可能存在Schema数量限制
- • 跨租户查询仍然困难
- • 无法为不同租户使用不同的数据库类型
- • 所有租户共享数据库资源，可能出现资源争用
适用场景
- • 中型SaaS应用
- • 租户数量中等但增长较快的场景
- • 需要较好数据隔离但成本敏感的应用
- • PostgreSQL或MySQL等支持Schema/数据库隔离的数据库环境
方案三：共享数据库，共享Schema，独立表模式
优缺点分析
优点：
- • 简单易实现，特别是对现有应用的改造
- • 资源利用率高
- • 跨租户查询相对容易实现
- • 维护成本低
- • 租户间表结构可以不同
缺点：
- • 数据隔离级别较低
- • 随着租户数量增加，表数量会急剧增长
- • 数据库对象（如表、索引）数量可能达到数据库限制
- • 备份和恢复单个租户数据较为复杂
- • 可能需要处理表名长度限制问题
适用场景
- • 租户数量适中且表结构相对简单的SaaS应用
- • 需要为不同租户提供不同表结构的场景
- • 快速原型开发或MVP(最小可行产品)
- • 从单租户向多租户过渡的系统
方案四：共享数据库，共享Schema，共享表模式
优缺点分析
优点：
- • 资源利用率最高
- • 维护成本最低
- • 实现简单，对现有单租户系统改造容易
- • 跨租户查询简单
- • 节省存储空间，特别是当数据量小时
缺点：
- • 数据隔离级别最低
- • 安全风险较高，一个错误可能导致跨租户数据泄露
- • 所有租户共享相同的表结构
- • 需要在所有数据访问层强制租户过滤
适用场景
- • 租户数量多但每个租户数据量小的场景
- • 成本敏感的应用
- • 原型验证或MVP阶段
方案五：混合租户模式
优缺点分析
优点：
- • 最大的灵活性，可根据租户需求提供不同隔离级别
- • 可以实现资源和成本的平衡
- • 可以根据业务价值分配资源
- • 适应不同客户的安全和性能需求
缺点：
- • 实现复杂度最高
- • 维护和测试成本高
- • 需要处理多种数据访问模式
- • 可能引入不一致的用户体验
- • 错误处理更加复杂
适用场景
- • 需要提供灵活定价模型的应用
- • 资源需求差异大的租户集合
方案对比
