《互联网时代的软件革命-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、系统菜单框架、功能页面容器、功能引擎、扩展数据引擎、工作流引擎等配置实现，还包括配置数据和扩展数据。
下一篇可伸缩多租户
侵权请联系删除，谢谢！