Saas.弹性架构设计思考

目录

缘起

什么是弹性

业务弹性

架构的弹性

服务弹性

中间件弹性

RocketMQ消息队列

Activiti流程引擎

Quartz JOB调度异步计算

MyCat DB路由中间件

存储弹性

Mysql数据持久化

Redis缓存

Ftp文件服务器

弹性管理

资源共享和故障隔离的处理


缘起

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,每⼀个功能都应该有上限性设计,不可⽆限使⽤。

从租户角度看:

  1. 根据不同的租户开通不同的功能,如:开通OA协同功能
  2. 开通的功能添加可用的范围,如:租户存储的文件4G

从功能角度看:

Saas.弹性架构设计思考_第1张图片

架构的弹性

服务,中间件,存储的弹性 必须依赖架构的弹性。如果是单体架构风格,也就没法做到这些弹性。按照现有分布式微服务架构风格,底层是基于Iaas的虚拟化技术,是比较容易的做到这一点,要求就是在架构的时候,尤其微服务划分的时候需要考虑 可能的根据租户的弹性扩展。

架构弹性要求:

  1. 每层(服务,中间件,存储)都需要保持弹性,按需扩展
  2. 调用前需要根据规则进行路由
  3. 路由逻辑自定义实现

架构图:

Saas.弹性架构设计思考_第2张图片

服务弹性

服务弹性:依据租户权重弹性分配服务的能力。

保持弹性前提:

  1. 微服务化:大单体架构控制的粒度太粗
  2. 服务跟功能映射:微服务的拆分不仅仅需要考虑领域抽象,同时也需要考虑功能的映射,开通一个系统尽可能涉及到比较聚焦的几个服务中。
  3. 请求时根据权重或者分配规则路由服务,支持动态调整路由参数

示意图:

Saas.弹性架构设计思考_第3张图片

中间件弹性

RocketMQ消息队列

MQ消息队列具有的资源:

  1. MQ中会有很多Queue
  2. MQ消息消费的时候会有一个优先级

弹性变量:

  1. 权重
  2. 直接指定

弹性:

  1. 不同权重(直接指定)的租户使用不同的Queue
  2. 不同权重(直接指定)的租户使用不同的优先级

Activiti流程引擎

执行优先级不同

Quartz JOB调度异步计算

异步调度,可弹性的只有处理的前后

MyCat DB路由中间件

此中间件跟服务数量有关系

存储弹性

Mysql数据持久化

  1. 集中存储,添加TenantID
  2. 不同环境,试用,正式小客户,正式大客户可以使用不同环境条件下的DB
  3. 独立存储数据
  4. 针对一个客户做定制化处理,比如数据量累计比较大后
  5. 对数据归档处理,随着时间的推移,数据积累后需要归档处理才可以继续支持

区分规则:

  1. 试用客户,免费客户,付费客户 分别处理
  2. 普通付费客户,KA客户,灯塔客户分别处理

Redis缓存

  1. 存储的空间
  2. 支持的Node:独立存储,还是集中存储,集群中的Node个数

路由:ShardedJedis到不同RedisNode上

Ftp文件服务器

  1. 空间大小
  2. 给不同租户分配不同大小的磁盘空间(存储上传的文件)
  3. 在每次上传文件和上文件的时候统计使用和释放的空间大小

弹性管理

场景1:试用客户 转为付费 客户

  • 支持配置数据,以及测试数据的迁移
  • 需要修改服务,中间件,存储的路由规则

场景2:OA磁盘空间增购

  • 是重新分配磁盘空间呢,还是扩展磁盘容量呢
  • 重新分配后需要无感知支持文件迁移
  • 扩展磁盘容量:文件也只是进程逻辑上的隔离,不做物理隔离。扩展只是功能性的允许,而不做实际磁盘的扩展

技术点:

  1. 逃不过的一个点,修改了配置怎么能同步到各个服务中间件
  2. 同步过去数据怎么进行动态的调整
  3. 是否需要开发一个系统展示现有系统的弹性规则

资源共享和故障隔离的处理

  1. Saas就是用来共享服务逻辑,存储,计算等资源的架构模式
  2. 共享就势必会引入故障的蔓延,某个用户导入一个超大文件,影响其他用户的正常业务操作
  3. 故障蔓延是需要控制的,某个租户的问题绝对不允许扩散到其他租户
  4. 怎么平衡共享和隔离,可以参考的点是,逻辑共享,物理隔离。比如:AB两个租户用一个套代码,但可能在服务的环境,服务,中间件,存储等都是隔离的。这样就不会影响彼此了。
  5. 如果集中部署情况,怎么平衡? 可以参考的点是,分包处理,根据优先级可以插队。轻量HTTP请求可以通过服务间的负载均衡来解决,但日常的功能尤其是计算型功能比较耗CPU内存资源,或者对磁盘访问高的逻辑,如导入导出逻辑,如果按照事务进行控制,则小租户导入10W数据,会迅速占完CPU和内存,还有IO资源。如果拆分为100条为一个包一个包的处理我, 每个包处理则按照不同租户的优先级权重来处理,这样一个小租户的大批量导入就不会对整个系统影响了。
  6. 特别说明:共享和隔离是一对矛盾,但也需要同时兼顾的,需要根据实际情况分别处理,没有一个方案可以兼顾

END

你可能感兴趣的:(SAAS,数据库,java,Saas)