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

从功能角度看：

架构的弹性

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

架构弹性要求：

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

架构图：

服务弹性

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

保持弹性前提：

1. 微服务化：大单体架构控制的粒度太粗
2. 服务跟功能映射：微服务的拆分不仅仅需要考虑领域抽象，同时也需要考虑功能的映射，开通一个系统尽可能涉及到比较聚焦的几个服务中。
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