《互联网时代的软件革命-SaaS架构》学习笔记三
1.Multi-Tenant应用的可配置性
1.1数据可配置
有些租户想要存储,对其有用,有些租户不想,对其无用,这种系统实现过滤中并不存在,而用户又需要保存的数据,称之为扩展数据。多租户的SaaS应用中,所有租户使用同一个应用实例,在同一个实例上如何实现大量租户各自不同的扩展数据需求?
- 定制字段
- 预分配字段
- 名称值对
1.1.1定制字段
根据客户的需求在数据表上增加相应的定制字段来保存扩展数据。
弊端:对多租户的SaaS应用来说,如果允许为每个租户都增加自定义的字段,这些字段多如牛毛,且这些字段对其他租户没有任何意义,并且破坏了数据表结构。显然不是解决多租户SaaS应用下数据可配置的理想方案。
1.1.2预分配字段
- 在用户可能扩展需求的表中预设一定数量的字段,当用户提出扩展需求时,使用其中的一个或多个字段来保护扩展数据。
- 这些预分配的字段没有特定含有,对不同租户这些字段保存不同含义的数据,对同一个人租户来说同一字段只能用来存储同一含义的数据。
- 为了更充分地利用预分配字段,可以将所有的扩展数据转换成字符串以后再来进行存储。那么不同租户同一字段存储数据类型不同,存储整数数据/字符串/其他,如何将数据转换成其原有的真是数据类型?保存前如何进行数据类型校验?—-对于租户使用各字段来保存真是数据类型,可以由租户来配置,并作为配置源数据进行管理。在使用数据时,系统可以根据元数据的配置信息,再转换成真是的数据类型。
- 对于预分配字段的含义和类型,就需要单独定义一个配置元数据的数据表来保存。对于不同租户使用各表中的每一个扩展字段,分别保存一条配置记录。
1.1.3名称值对
如果预分配太多,导致数据库表膨胀,产生很多无意义的空闲字段,造成浪费,如果太少,更多租户扩展数据没地方保存。可以考虑将扩展数据与原数据表分离,另外用一张统一的扩展数据表来保存。
扩展数据表将数据表的横向扩展列转换成纵向的数据集,将每一条原数据记录的没一个扩展字段,都保存成一条扩展数据行。将数据表中的数据记录与配置元数据表中的配置记录关联,构成扩展数据记录。
名称扩展对这种模式,给扩展数据的保存提供了非常大的灵活性,可以提供无限数量的自定义扩展字段。
1.2功能可配置
1.2.1原子功能划分
要实现功能配置,首先需要将整个系统的功能进行分解,需要分解成个个最基本的、相对独立的、互不重叠的原子功能。
划分原则:需要遵循用户价值驱动原则
- 每个功能都是有价值的;
- 每个功能都不可再细分;
- 功能间不互相重叠;
- 功能之间不循环依赖;
- 整个系统功能是完成的。
1.2.2功能定义及依赖
功能定义:对原子功能进行描述,定义他的名称、关键字、内容等相关信息,以及他依赖的功能列表。定义key作为使用功能和功能校验的唯一关键字,系统内唯一。
1.2.3功能包设计
根据用户的类型和使用场景,对原子功能进行打包,然后为每一个用户挑选其合适的功能包。
销售包设计,可以是最小版、标准版。完整版,或按行业分。
1.2.4功能使用校验
不管用户购买的是扫描版本或扫描功能包,系统只对原子功能进行校验。
要确定用户再系统中可以使用和操作那些原子功能,需要根据租户所购买的版本,递归查找所包含的功能包,再取出所有的功能包所包含的原子功能,从而构成租户再系统中可以使用的原子功能集合。
实现原理:只要再原子功能被使用前,对当前用户是否可以使用该原子功能进行校验就可以了。从体验上讲,再系统展示界面之前,就应该线校验用户所具备的原子功能,不具备的或可以不显示或不可以状态或隐藏。
1.3界面可配置
界面可配置包括:系统菜单可配置、页面内容可配置
1.3.1系统菜单可配置
除了系统菜单名字可配置外,菜单的层次结构及分布,不同租户可能也会有不同的要求,需要考虑一下问题:
- 一个租户一套菜单
- 一个菜单可以关联一个原子功能
- 组织成树状结构,构成上下级菜单结构
- 同级菜单之间还存在显示顺序的问题
1.3.2页面元素可配置
各功能界面上的内容是供用户与系统交互的界面元素,不同租户可能会有各种不同需求,无论是对页面元素的个数、位置、顺序,还是元素的定义,租户都可能会由一些个性化的需求。
由于租户可以自定义扩展数据,这些数据是需要在页面上展示的,因此,对于不同租户,页面元素个数可能不同,另外,同一页面上同一元素可能代表的含义是不一样的。
解决方法是采用标签语言来描述,自行了解。
1.4流程可配置
流程可配置是工作流系统要解决的问题,租户之间的流程和数据是要隔离的,除了应用预设的流程模板外,其他的都是由租户自己来定义和设计的。
- 首先,工作流系统要能支持多租户的工作流设计。系统提供通用模板,租户在模板基础上自定义。
- 其次,工作流引擎在运行时,总是能根据当前用户所属的租户,去查找属于该租户的流程,然后实例化流程。
1.5配置元数据管理
对于一个完整的SaaS应用来说,会有很多的功能模板都需呀实现可配置的特征,对于不同的业务模板来说,其可配置性的要求并没有差别,如在数据可配置上,无论是客户数据配置还是产品数据配置,要是使用名称值对方法来实现,其实实现完全一样,因此对同一种类的多项配置可以进行同一实现,即摆脱业务逻辑实现统一公共的数据可配置、功能可配置、界面可配置。
前面介绍的数据、功能、界面、流程,分别介绍了4个方面的配置要求和配置的各种参数,表面上这些参数各不相同,但是如果对其进行抽象,可以分析出4者之间的很多共性,只是在可配置参数的关联上是可能统一的。———-4种可配置的参数在元数据上能得到统一,那么可以考虑提供统一的公共的接口,用来使用和操作这些配置数据。
1.5.1配置元数据
如何实现这些系统可配置参数的统一管理,在原理上可以参考MDA(Model Driven Architecture,模型驱动架构)基于元数据管理的思想。SaaS应用中要管理的可配置参数包括一下几种:表、原子功能、功能包、菜单、页面、页面元素、流程等,这些配置类型称之为配置元。配置元之间的关系:
- 原子功能之间的依赖
- 功能包对原子功能的包含
- 功能包对功能包的包含
- 菜单和菜单的上下级包含关系
- 菜单到功能之间的关联关系
- 页面对页面元素的包含关系
1.5.2租户配置数据
基于配置元模型和配置元数据,由租户管理员根据租户的需求来定义相应的配置信息:
- 数据表扩展字段
- 租户购买包
- 自定义菜单
- 自定义页面元素
只有租户购买包是由系统管理员进行设置的,其他均有租户管理员进行配置。
1.5.3配置元数据服务
系统中的个业务模块如何是由这些元数据?这就需要实现公共的配置元数据服务,就是要提高一套统一操作这些元数据的服务接口,以及一套可以直接是由元数据的控件,供业务模块开发时是由。
1.6可配置系统运行
前面子啊数据、功能、界面、流程4个方面要解决的可配置问题,以及配置元数据相关管理进行阐述,那么这些可配置内容如何在系统中发生作用?系统如何基于这些配置数据运行?
- 首先,元数据服务。
- 其次,所有这些配置数据要在系统中生效的话,需要在系统界面上体现,包含:系统菜单体系,功能页面上体系。
- 最后,有关各类配置数据的使用逻辑及调度控制,通过3个特殊引擎来完成。流程可配置数据的使用与控制,由工作流引擎来完成;有关扩展数据的查询、使用、提交及相应的检查等,由专门的扩展数据引擎来完成;设计单独的功能引擎,复杂系统内功能的调度和租户对功能的使用。
因此,可配置系统运行,需要包括:元数据服务、租户配置UI、系统菜单框架、功能页面容器、功能引擎、扩展数据引擎、工作流引擎等配置实现,还包括配置数据和扩展数据。
下一篇可伸缩多租户
侵权请联系删除,谢谢!