Saas系统架构的思考,多租户Saas架构设计分析

转载:https://blog.csdn.net/cnpinpai/article/details/91967335

ToB Saas系统最近几年都很火。很多创业公司都在尝试创建企业级别的应用 cRM, HR,销售, Desk Saas系统。很多Saas创业公司也拿了大额风投。毕竟Saas相对传统软件的优势非常明显。   

最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都比满意。整个系统创建过程,踩了很多坑,收获也比较多。总结一下Saas系统架构一些特点:

Saas系统分级:

SaaS系统架构成熟度模型的5个级别——从“混乱”到“乌托邦“

第0级(混乱):每次新增一个客户,都会新增软件的一个实例。
第1级(受控的混乱):所有客户都运行在软件的同一个版本上,而且任何的定制化都通过修改配置来实现。
第2级(多租户[multi-tenant]、高层建筑[Highrise]):所有的客户都已经可以在软件的同一个版本上运行了,而且他们都在同一个“实例”上运行。
第3级(多租户, 扩建[Build-Out]):此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展(scale-out)的方式来进行扩充。
第4级(乌托邦):如同第3级,除非你可以找出有效的方式,以在不同的“实例”上运行不同版本的软件。

应用程序必须支持多租户:

  多租户可以分为几个不同的类别(如列表下方的图所示):
    1.1,云中的简单虚拟化,其中只对硬件进行共享。
    1.2,共享应用程序,对每个租户使用不同的数据库。
    1.3,共享应用程序和数据库(效率最高,真正的多租户)。

1.分层设计
Saas系统分层大概是:


Saas系统分层
 

Saas系统分层:租户识别>应用层>数据访问层>缓存层>数据库

业务代码都是写在应用层。

租户识别可以用spring拦截器实现,然后使用ThreadLocal传递给后端

数据库和缓存层对应用层应该是透明的。程序员在写代码的时候,只关心业务逻辑,不应该担心多租户的问题。


2.数据隔离要透明
saas系统说起来很简单,任何系统似乎加个tenant_id(租户id)就变成saas系统了。比如原来的用户登录是:

select username,password from users where email=\'abc@qq.com\'
改成

select username,password from users where email=\'abc@qq.com\' and tenant_id =1;
对于复杂业务的saas系统,这样做法非常危险,而且开发效率很低。你想想如果那个程序员写sql时候忘了加 “ and tenant_id =1” . 结果不堪设想。

比较好做法是在数据库访问层对SQL进行改写。

TenantContext.exec("select username,password from users where email=\'abc@qq.com\' ");
在连接池根据TenatnContext改写Sql. 

这样做好处是,一来程序猿最多把系统搞down了,也不至于信息串了互相泄露。二来将来做分表分库也很方便,上层应用不用修改。

3. 租户识别方案
比较好做法是通过url识别租户。系统是给租户生成一个随机的三级域名,比如 abc.crm.baidu.com.   如果客户想使用自己的域名,可以在cname到我们生成的三级域名,并在管理系统里面做绑定。

这样一个租户可以有两个域名,访问saas,一个随机生成的三级域名,另外一个租户自己的域名.代码里面可以根据过来的域名,判断是那个租户然后初始化TenantContext.

如果不想通过域名来做,也可以通过登录名来判断。这种方式要涉及到租户切换问题。

4. 智能DNS
以后补充。

5. 租户管理系统(计费,订购,定制,充值,催缴)
Saas系统是必须考虑计费系统和租户控制系统。这个系统需要都是独立设计。比如那个租户购买了那些模块,一个月多少钱。租户可以创建最多的用户数。计费到期邮件提醒等功能。

计费方式一般有两种,周期性计费,类似月租方案,和使用量计费,用多少付多少。 周期性计费比较简单。也可以两者结合起来。

6. 定制化开发
SAAS的优势在于一套系统多人使用,似乎和定制化开发有冲突。比如A客户想要A功能,B客户不想要。但定制化开发是无法避免的,比如CRM系统这样复杂的系统,不可能一套系统满足所有公司的要求。定制化开发尽可能分系统,分模块去做。然后通过控制台中配置不同租户订购不同模块,那些模块可以在前端页面上显示。不同的子系统需要分开部署。前端可通过nginx根据url分发,比如 abc.crm.baidu.com/bi/xxx/xx这个地址,就分发到BI子系统。不要尝试OSGI去搞模块化,这个是个大坑。

还有开发和产品,现有需求一定要分析清楚,不要一上线发现后患无穷。新功能尽量做的独立可以配置。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwfyfj.html