全面分析web 应用程序转化为多租户 SaaS技术探讨及 解决方案

典型的 web 应用程序和 SaaS

Web应用销售肯定需要搭建软硬件环境以及系统部署及数据库安装。
SaaS 区别于其他应用程序的主要特征就是能够使客户在使用应用程序时按照使用量付费。他们不需要为软件购买许可，也不需要安装、托管和管理它。这方面的操作全部由提供 SaaS 软件的组织负责。

未命名文件 (1).png

简单来说就是以上三种：

1.租户各自独立使用应用和数据库服务。

实现思路：租户购买服务后，需要单独部署系统和数据库。nginx（或者其他服务器）也需要配置对应的租户服务的跳转。跳转可以根据二级域名（每个租户分配一个独立的二级域名。通过二级域名访问单独的应用或应用集群，应用访问该租户独立的数据库实例。）或者使用租户指定的域名。
【性能高，运维成本大，开发成本基本为零，硬件成本增加】

2.租户共用一组应用服务，各自单独的数据库服务。

实现思路：租户在注册时，会分配一个租户编码。当租户通过统一的域名访问系统时，应用会根据用户的会话ID或Token信息，获取用户的租户编码，并根据租户编码，将租户对应的数据源绑定到当前请求中。
【改造成本适中】

3.租户合用一组应用服务和单独的数据库服务。

实现思路：租户在注册时，会分配一个租户编码。当租户通过统一的域名访问系统时，应用会根据用户的会话ID或Token信息，感知用户的租户编码，并根据租户编码，在数据库找到对应的单独表或者筛选属于该租户的数据。
【开发成本大，后期运营成本小，开发成本大】

实现方式

第一种情况无开发成本，只需运维部署
以下只探讨情况二的实现方式。
融合第二种情况和第三种情况

改造内容

负载均衡改造内容

1. 缓存数据共享
2. 文件资源共享
3. 数据库资源共享

具体改造

1. ecache切换为redis缓存，整合redis框架
2. 缓存结构调整、以及旧方法改造
3. redis操作工具类 【优先调整已用方法】
4. 缓存序列化方式选择
5. session redis缓存共享改造
6. 文件系统通过挂载云盘方式 【可靠后、暂排后期】？或者七牛云【工期较长】
7. redis可视化管理界面（由于序列化问题，导致redis客户端无法查看缓存具体内容）【暂未实现】

多租户改造内容

1. 动态数据源创建
2. 数据源自动根据组织ID切换 【包括redis数据源】
3. 数据源手动切换
4. 数据库事务问题【尽量不涉及到多数据源事务】

过程解决的问题

参见整理文档

orgId维护思路

1）组织机构、人员添加组织ID字段 orgId
2）添加新增租户组织机构的方式：通过该方式能够制定该机构的ID（不用原有机构ID生成策略），并设置orgId = this.id 【即orgId等于此机构的ID】
3）修改原机构update和insert：设置其orgId = 上级机构的orgId
4）对于其他业务数据表改造原则：

graph LR
A[业务表] -->|不含公司ID|B2(业务表)
A[业务表] -->|含公司ID|B1(业务表)
A[业务表] -->|含UserID|B3(业务表)
A[业务表] -->|不含含UserID|B4(业务表)
B1 -->|业务数据量大|D1[新增OrgId]
B1 -->|业务数据量小|D2[关联office表查询]
B2-->D1
B3 -->|业务数据量小|D2
B4-->|无论数据量大小|D3[新增OrgId]

5）单独维护orgId参数表：包含数据库连接信息、失效时间、人员的数量限制。

参考资料

https://www.jianshu.com/p/54f35fa2f374

https://www.ibm.com/developerworks/cn/cloud/library/cl-multitenantsaas/

数据层的多租户浅谈

https://www.jb51.net/article/133074.htm