多租户saas 架构_碧桂园DevOps平台多租户SAAS架构设计思考与分析
随着公司的信息化建设快速发展，也随着业务不断地扩展，DevOps平台陆续接入了数管中心、博智林机器人、基础院、信管院、研究院等诸多子公司的业务系统，平台后续还会持续接入更多子公司业务，其中部分子公司为防止数据/代码泄漏，对安全性要求非常严格。此外，笔者心中和领导有着一个共同的建设蓝图(将整个DevOps运维服务打包做成商务化)，为避免每一个子公司部署一套DevOps平台，减少运维成本，同时需解决数据安全性问题，那么将DevOps平台做成多租户SAAS架构就刻不容缓了。
那么，什么是多租户saas架构呢？笔者这里为大家解说一下，所谓多租户(Multi-Tenant )，即多个租户共用一个实例，租户的数据既有隔离又有共享，说到底是要解决数据存储的问题。
笔者认为此次SAAS架构设计应该具备以下几个特点：
SAAS系统分层设计：租户识别>应用层>数据访问层>缓存层>数据库
此次租户来源包含：公司内部组织(各个中心部门、子公司等)、外部公司。
租户识别可以前端存放Header请求中传送给后端。
业务代码可以全部写到应用层，数据库和缓存层对应用层应该是透明的。这样笔者和同事在写代码的时候，只需关心业务逻辑，不需担心多租户的问题。
数据隔离要透明
常用的数据存储方式有三种：独立数据库；共享数据库，隔离数据架构；共享数据库，共享数据架构；
结合公司对安全性要求和未来规划，此次设计，笔者将会选择第一种方式，即独立数据库。虽然成本较高。但是隔离级别最高、最安全，同时数据备份和恢复相对简单。结合目前实际场景要求，数据库设计如下：
公共库：用于存储租户信息、菜单、license收费等共享数据
若干分库：数据库名为租户编码，用于存储每个租户的业务数据，比如某个租户下的用户表、角色、操作日志等等数据
后端django数据库配置如下图所示：
对应的app目录结构应如下图所示：
切记，后台python django 编译租户数据库的时候需要带上租户编码，若不加，则编译的是公共数据库，比如：
python3 manage.py migrate --database 租户编码
租户识别方案
租户识别方案有多种，比如通过域名识别、登录名识别等等。笔者分析用户登录有三个场景：平台登录、LDAP登录、SSO登录。其中SSO统一身份认证登录是公司内部目前主要使用的登录方式，而平台账号和AD账号登录主要为外部公司用户使用。设计构思如下：
平台账号多为注册账号，这部分账号在申请注册的时候，就已绑定了租户组织。
AD方式登录的时候需要选择租户组织后方可登录校验
针对SSO登录，若为首次登录，前端自动跳转租户选择页面，待用户选择租户组织之后，需等待运营管理员审批，审批通过之后，后续将直接跳转目标页，其原理类似玩游戏首次需选择区域，后续进入则默认加载该区域数据。
不管用户是以那种模式登录，前端都将存储用户的租户编码到缓存/Cookie中，然后通过Header请求传送给后端，django后端业务视图根据接收的租户编码进入到对应的分库去处理业务数据。如下图所示：
租户管理系统(计费，订购，定制，充值，催缴)
SAAS系统是必须考虑计费系统和租户控制系统。这个系统需要都是独立设计。比如哪个租户购买了那些模块，一个月多少钱。租户可以创建最多的用户数。计费到期邮件提醒等功能。
计费方式一般有两种，周期性计费，类似月租方案，和使用量计费,用多少付多少。周期性计费比较简单。也可以两者结合起来。最终后端编译到公共库中，如下图所示：
定制化开发
SAAS的优势在于一套系统多人使用，似乎和定制化开发有冲突。比如A客户想要A功能，B客户不想要。但定制化开发是无法避免的，比如DevOps系统这样复杂的系统，不可能一套系统满足所有公司的要求。定制化开发尽可能分系统，分模块去做。然后通过控制台中配置不同租户订购不同模块，那些模块可以在前端页面上显示。不同的子系统需要分开部署。还有开发和产品，现有需求一定要分析清楚，不要一上线发现后患无穷。新功能尽量做的独立可以配置。
灰度升级
SAAS付费企业客户对系统问题都会特别敏感。为了减少升级可能出现问题的影响范围，一般都采用灰度升级策略。这块到时候笔者将考虑使用nignx_lua来写一些扩展模块来做自定义灰度
以上是笔者对“多租户SAAS架构设计分析与思考”的分享，从SAAS平台架构处理数据可以看出saas平台的应用有很强的优势，如用户使用SAAS非常方便简单只要浏览器或本地客户端接口，SAAS平台处理数据要经过层层认证SAAS产品安全可靠等。
目前该多租户SAAS架构正处于建设中，欢迎大家来提供/分享一些建设性意见，也诚邀一些有志之士来一起共建平台。
聚人才，倍放光彩；纳贤士，共享未来！