SaaS多租户架构技术方案实现设计
Eureka SaaS Architecture
SaaS 多租户方案
设计目标
- 隔离服务带来清晰的职责归属与数据隔离
- 减小 SaaS 化改造的影响半径
- 数据隔离透明
- 业务开发对 SaaS 化无感知
技术方案选型
[来源本人公司内部Confluence撰写的文档]
技术方案选型建议
选型考虑因素主要是 改造成本 及 费用成本 并结合公司目前的状况来做建议。
- 成本角度因素(隔离性越好,成本越高)
- 开发成本(改造成本越低,越倾向于共享)
- 租户数量(数量越多,越倾向于共享)
- 安全因素(客户安全性要求越高,越倾向于隔离)
多租户框架处理流程
1、在用户登录后,通过二级域名识别租户(也可以是其他租户识别方案),将 租户ID 放在用户的 Token 中返回给用户
2、每次用户的请求带上 Token,通过网关解析 Token 并将 租户ID 参数存入 Request
3、微服务统一拦截器,拦截 Request 中带有 租户ID 的字段,放入 ThreadLocal 中
4、SQL 执行拦截器,在执行前对SQL进行拦截,从 ThreadLocal 中获取 租户ID,并增加相关的 where 条件
4.1、准备所有需要租户隔离的数据表做一个集合
4.2、若 SQL 中包含集合中的表,则动态替换对应部分的 WHERE 条件增加 tenantId = x
4.3、返回对应的 SQL 给 JPA
1 | public class TenantInterceptor implements StatementInspector { |
全局数据聚合统计问题
SaaS化之后,各租户有各自的 Eureka 平台,但在我们公司的角度需要做一些全局上的后台,比如数据统计等功能,这种不管是查询上的复杂度,还是性能上多表 Join 拖垮单库的性能都是不理想的(复杂统计影响租户体验速度);
所以解决方案有2种:
1、对一些需要统计数据的场景,计划任务每日给需要统计的表做聚合,聚合数据以日为单位(按实际统计需求)存储到统一的一个表/库中,后续的聚合统计不管以年月日为单位,都可以根据日的数据做加法来聚合;
优点:实现简单
缺点:业务程序冗余了统计聚合等计划任务代码
2、配合大数据将数据储存到 ClickHouse 中,通过预聚合的方式存储日为单位的数据,同时存储明细数据做备份(定期清理较老的明细数据)
优点:业务和聚合程序分开
缺点:需要大数据组件
多租户其他资源隔离
每个租户使用独立的 S3 Bucket、SQS队列(同SQS服务实例);