目录
缘起
Saas平台是为多租户公用服务,以及支撑架构的中间件,存储,硬件计算资源。
如果一个免费用户和一个KA用户是否需要共享呢?
结论当然不是,必须保证KA用户正式环境的可用性。
如果资源没有限制,如存储空间。那么免费用户,试用用户无限制上传文件就会对环境有较大的冲击。如果是导入导出服务,那么消耗的资源就更大。
Saas是共享资源,但也需要优先保证大客户,重要功能得可用性和高性能。
什么是弹性
Saas平台既要解决逻辑功能复用,也需要对资源进行复用。但同时需要根据不同租户对使用的功能进行限制,以及技术架构上进行隔离。这就是一门复用和隔离的艺术,既要极可能做到功能和资源的复用,同时也需要根据租户需求,付费特征区分对待,进行优先级的划分,也需要保证租户间故障隔离。
场景1:试用用户,允许100个用户,用1核2G内存机器的服务,使用公用的MQ队列,试用环境Redis,DB使用共享库,磁盘只有4G的空间。
场景2:KA用户,允许1W个用户,独立4核8G的机器部署服务,使用KA专有MQ队列,Redis专用,DB使用独立的数据库,磁盘空间2T空间。
根据上述总结:
业务弹性:用户,实体个数,流程个数,Enable功能,
服务弹性:后台服务根据租户进行负载均衡的区分,Job任务调度,批量处理优先处理
中间件弹性:Redis缓存,Cache服务内缓存,Mycat中间件
存储弹性:DB,文件磁盘空间
业务弹性
不同租户应分配不同的功能弹性能⼒,依据租户权重限定功能使⽤的弹性限界范围。在进⾏功能设计时,应充分考虑每⼀个功能的Limit,每⼀个功能都应该有上限性设计,不可⽆限使⽤。
从租户角度看:
- 根据不同的租户开通不同的功能,如:开通OA协同功能
- 开通的功能添加可用的范围,如:租户存储的文件4G
从功能角度看:
架构的弹性
服务,中间件,存储的弹性 必须依赖架构的弹性。如果是单体架构风格,也就没法做到这些弹性。按照现有分布式微服务架构风格,底层是基于Iaas的虚拟化技术,是比较容易的做到这一点,要求就是在架构的时候,尤其微服务划分的时候需要考虑 可能的根据租户的弹性扩展。
架构弹性要求:
- 每层(服务,中间件,存储)都需要保持弹性,按需扩展
- 调用前需要根据规则进行路由
- 路由逻辑自定义实现
架构图:
服务弹性
服务弹性:依据租户权重弹性分配服务的能力。
保持弹性前提:
- 微服务化:大单体架构控制的粒度太粗
- 服务跟功能映射:微服务的拆分不仅仅需要考虑领域抽象,同时也需要考虑功能的映射,开通一个系统尽可能涉及到比较聚焦的几个服务中。
- 请求时根据权重或者分配规则路由服务,支持动态调整路由参数
示意图:
中间件弹性
RocketMQ消息队列
MQ消息队列具有的资源:
- MQ中会有很多Queue
- MQ消息消费的时候会有一个优先级
弹性变量:
- 权重
- 直接指定
弹性:
- 不同权重(直接指定)的租户使用不同的Queue
- 不同权重(直接指定)的租户使用不同的优先级
Activiti流程引擎
执行优先级不同
Quartz JOB调度异步计算
异步调度,可弹性的只有处理的前后
MyCat DB路由中间件
此中间件跟服务数量有关系
存储弹性
Mysql数据持久化
- 集中存储,添加TenantID
- 不同环境,试用,正式小客户,正式大客户可以使用不同环境条件下的DB
- 独立存储数据
- 针对一个客户做定制化处理,比如数据量累计比较大后
- 对数据归档处理,随着时间的推移,数据积累后需要归档处理才可以继续支持
区分规则:
- 试用客户,免费客户,付费客户 分别处理
- 普通付费客户,KA客户,灯塔客户分别处理
Redis缓存
- 存储的空间
- 支持的Node:独立存储,还是集中存储,集群中的Node个数
路由:ShardedJedis到不同RedisNode上
Ftp文件服务器
- 空间大小
- 给不同租户分配不同大小的磁盘空间(存储上传的文件)
- 在每次上传文件和上文件的时候统计使用和释放的空间大小
弹性管理
场景1:试用客户 转为付费 客户
- 支持配置数据,以及测试数据的迁移
- 需要修改服务,中间件,存储的路由规则
场景2:OA磁盘空间增购
- 是重新分配磁盘空间呢,还是扩展磁盘容量呢
- 重新分配后需要无感知支持文件迁移
- 扩展磁盘容量:文件也只是进程逻辑上的隔离,不做物理隔离。扩展只是功能性的允许,而不做实际磁盘的扩展
技术点:
- 逃不过的一个点,修改了配置怎么能同步到各个服务中间件
- 同步过去数据怎么进行动态的调整
- 是否需要开发一个系统展示现有系统的弹性规则
资源共享和故障隔离的处理
- Saas就是用来共享服务逻辑,存储,计算等资源的架构模式
- 共享就势必会引入故障的蔓延,某个用户导入一个超大文件,影响其他用户的正常业务操作
- 故障蔓延是需要控制的,某个租户的问题绝对不允许扩散到其他租户
- 怎么平衡共享和隔离,可以参考的点是,逻辑共享,物理隔离。比如:AB两个租户用一个套代码,但可能在服务的环境,服务,中间件,存储等都是隔离的。这样就不会影响彼此了。
- 如果集中部署情况,怎么平衡? 可以参考的点是,分包处理,根据优先级可以插队。轻量HTTP请求可以通过服务间的负载均衡来解决,但日常的功能尤其是计算型功能比较耗CPU内存资源,或者对磁盘访问高的逻辑,如导入导出逻辑,如果按照事务进行控制,则小租户导入10W数据,会迅速占完CPU和内存,还有IO资源。如果拆分为100条为一个包一个包的处理我, 每个包处理则按照不同租户的优先级权重来处理,这样一个小租户的大批量导入就不会对整个系统影响了。
- 特别说明:共享和隔离是一对矛盾,但也需要同时兼顾的,需要根据实际情况分别处理,没有一个方案可以兼顾
END