《互联网时代的软件革命-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、系统菜单框架、功能页面容器、功能引擎、扩展数据引擎、工作流引擎等配置实现,还包括配置数据和扩展数据。

下一篇可伸缩多租户

侵权请联系删除,谢谢!