SaaS软件的多租户框架技术方案设计

前言

什么是多租户技术

百科：多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。

多用户共用系统或组件这块是目前一般软件系统都支持的，重点是用户间的数据隔离，普通软件系统基本没有隔离或者说是仅逻辑隔离，这类系统用户的数据往往是在一个存储上，比如同一个数据库和数据表中，不具备严格意义上的隔离性。我们一般说到隔离通常有逻辑隔离和物理隔离，传统多用户系统基本都是逻辑隔离（数据表中根据用户id进行识别），而标准的多租户系统可以根据租户需求轻易做到物理隔离，比如某个租户可以有自己单独的硬件资源，单独的存储单独的数据库，单独的软件实例，多租户系统可以基于租户更方便做软硬件定制及更方便的资源计费。

多租户下的租户与客户、用户区别

谁是客户谁是用户

先讲客户与用户区别，我们用两个例子看你是否能区分出谁是客户谁是用户，如果能准确区分出那后面租户部分也较容易理解：

1、A公司从B公司购买了几台电脑给员工使用

2、王大爷买了个按摩椅给自己用

答案：

例子1中A公司是客户而员工是用户，例子2王大爷即使客户也是用户。

解释

客户一般是指消费者，即与另外一个主体有合同或者约定，是产品或服务的请求方、支付者，客户是购买产品或服务的直接主体，而第二个例子王大爷有买卖合同，买了之后又给自己使用，所以即使客户又是用户，谁使用谁是用户。所以到底是客户还是用户不同场景可能需要区分对待，但我们通常说客户一般都是某个组织，这个组织可以是一个公司、政府、个体等，在软件系统中大部分使用的人都是用户。

谁是租户

租户往往与客户对等，租户的背后就是客户这个主体，租户是在特定场景下的代称概念或逻辑概念，比如现实中小张租了一套房可以称小张就是租户，在软件系统中A公司在某个云厂商购买了一些资源，云厂商系统中就存在了一个A公司这样一个租户，在现实法律层面或日常沟通交流上一般说A公司是客户，但在软件系统层面通常会把A公司称为一个租户，这个租户就代指A客户。之后A公司购买了服务又给员工用，那此时员工就是用户，所以用户一定是在租户下的，用户是归属于某个租户的，传统软件没有租户这一层，所有的用户都归属于一个系统。云厂商要支持更多租户都可以购买使用，又要保证租户之间不互相影响，就要加入多租户技术在里面，根据租户进行隔离或者路由，多租户的系统也因此更复杂。

  基于目前项目需求及未来规划，在saas层、paas层都需要具备多租户能力，我们需要一个标准统一的多租户框架技术规范来减少不必要的重复设计及踩坑，也需要多租户框架技术做为公司的技术基础设施并提供一定的技术竞争力。

设计目标

• 建立paas、saas层软件统一的多租户技术框架规范，让paas与saas层租户信息无缝互通

• 能够提供逻辑隔离、物理隔离定制能力，满足业务诉求上的稳定性、安全性要求

• 降低多租户应用开发的难度，做到对开发人员透明

方案

   租户标识规范

  租户标识是在多租户框架中是比较重要的一块，有好的标识规范好在实际应用中会有诸多便利，比如快速识别租户方便排查问题，不会占用过多计算和存储资源，在特殊场景也不会对系统带来复杂的额外设计。

   在多租户框架下，租户标识除了用于标识业务数据所属租户外，很多情况下还要基于租户标识来做流量的路由，无论是在saas层还是paas层，因此我们要考虑怎么基于标识做路由：

• 第一种

       常见做法是先取到租户标识，然后再根据租户标识获取对应场景下的租户路由配置信息，这种设计好处是便于管理及扩展性较强，缺点是设计较复杂一些，也要考虑为不同的中间件、应用提供相应的获取路由配置接口。

• 第二种

       另一种思路是是否可以直接基于租户标识进行路由，比如租户标识包括区域和业务信息，这样在比如nginx上就可以直接使用正则或前后缀匹配进行路由，这样设计好处是比较简单在前期能快速支撑业务，若后续业务及中间件规模上来后再结合实际场景使用第一种扩展性上也不会存在太大问题。

  下面举例一种适用于为多个地区组织提供业务的租户标识设计：

• 租户编码组成

  • 由区域.组织简写或全拼组成，如下：

    • 省.市.组织

  • 说明

    • 每一部分的编码可以全称也可以缩写，能达成统一共识方便识别即可，比如河南可以用ha代替，郑州用zz代替，南阳用ny代替

    • 租户编码各段以逗号或横线分隔，最少三位，最长四位，第四位可以是某组织下细分业务的租户

    • 国家默认为中国，后续若走向国际化，新的租户可以再加国家前缀，老租户默认为中国

• 租户编码示例

• ha.zz.gov - 河南郑州政府 租户

• ha.ny.gov - 河南南阳

• ha.zz.edu - 河南郑州教育租户

• ha.zz.gov.livelihood - 河南郑州政府下民生相关业务租户

• 租户省市拼音简写字典表

  省	市
  BJ 北京市
  SH 上海市
  TJ 天津市
  CQ 重庆市
  HE 河北省	石家庄/shijiaz
  SX 山西省
  NM 内蒙古自治区
  LN 辽宁省
  JL 吉林省
  HL 黑龙江省
  JS 江苏省
  ZJ 浙江省
  AH 安徽省
  FJ 福建省
  JX 江西省
  SD 山东省
  HA 河南省	新乡/xinx
  	郑州/zhengz
  HB 湖北省
  HN 湖南省	长沙/changs
  GD 广东省
  GX 广西壮族自治区
  HI 海南省
  SC 四川省
  GZ 贵州省
  YN 云南省
  XZ 西藏自治区
  SN 陕西省
  GS 甘肃省
  QH 青海省
  NX 宁夏回族自治区
  XJ 新疆维吾尔自治区
  TW 台湾
  HK 香港
  MO 澳门

  租户模型 TENANT

字段	类型	长度	说明
id	int	10	租户id
created_at	datetime		创建时间(默认：now())
updated_at	datetime		修改时间(默认：now())
tenant_code	varchar	64	租户code
tenant_alias_code	varchar	64	租户别名code, 在某些特殊场景不适合暴露或使用租户code时使用
tenant_name	varchar	200	租户名称
tenant_status	tinyint	1	租户状态：0待启用，1 正常、2禁用
tenant_domain	varchar	500	租户域名，域名不一定必须包含租户信息，但要全局唯一
tenant_ext	varchar	2000	扩展属性，可以存放json结构
tenant_country	varchar	20	租户所属国家
tenant_province	varchar	20	租户所属省份
tenant_city	varchar	20	租户所属城市
org_name	varchar	200	租户所属组织名称,可以是企业、政府、学校等
org_code	varchar	100	租户所属组织code
remark	varchar	1000	备注

• 租户信息存储设计要求

  • 多租户信息能够方便进行维护，并且在不同的应用和中间件上能够快速获取到租户信息

多租户构架下的水平扩展

一旦系统中引入多租户设计，下面这个模式是最基础也是最经典的集群模式，所有涉及租户的系统设计理论上都要能够实现以下这种集群架构方式

多租户架构图

多租户SDK

   sdk设计主要是提供租户信息的统一获取及租户的识别，可以让各个业务应用能够方便使用。sdk这块代码暂时先不提供了，后缀大家有兴趣可以关注私信我。

任何框架设计都要基于业务诉求，多租户框架同样，本文主要是提供一种多租户框架设计思路。