读书笔记《互联时代的软件革命-SaaS架构设计》

第一章

1.什么是SaaS

2.SaaS和ASP的区别
Application Service Provider（应用服务提供商），ASP模式就是将软件统一托管到应用服务提供商的服务器中。SaaS，Software as a Service软件即服务就是SaaS,SaaS的目标是软件的彻底服务化。

3.SaaS的优势和不足
优势：开通简单、无需维护、按需购买使用、不受时间空间限制、风险低、投入小、试错成本低
不足：依赖互联网、数据安全性和保密性有可能会泄漏。

第二章 SaaS 成熟度模型

1. SaaS的规模效应

在传统软件方式下，一个租户需要购买一套软件及硬件、网络和人员的投入。SaaS模式下，租户只需要购买一套软件服务即可，其它都是软件提供商的投入成本，用户不需要考虑。对于具备良好可扩展性的SaaS系统，通过用户数量的扩大，本均成本就越低。这就是SaaS系统的规模效应。

在Multi-Tenant架构，多租户架构。

2. SaaS成熟度模型

图片1.png

Level 1 定制开发

就按照客户的需，求来定制一个版本，每个客户的软件都有一份独立的代码。

Level 2 可配置

每个客户独立部署一个运行实例。只是每个运行实例运行的是同一份代码，通过配置的不同来满足不同客户的个性化需求。

Level 3 多租户架构

Level 4 可伸缩的多租户架构

将多用户的访问需求通过负载平衡层分配到不同的实例上，实现几乎无限制水平扩展。

SaaS系统特别可配置性、高性能、可伸缩性。

定制开发

可配置

多用户架构：

Multi-Tenant架构：多用户架构是实现SaaS的基础要求

多用户下的可伸缩性：优化系统的性能。

可配置：抓住客户主要需求，实现功能可配置。

可伸缩性：包括应用层可伸缩和数据库层可伸缩。

第三章 视图

逻辑视图，如果设计采用面向对象的方法，逻辑视图就是对象模型。逻辑视图重点在于功能，包括业务功能和系统功能。以及逻辑分层、模块划分和模块之间的关系。

开发视图，描述软件在开发环境下的静态组织。开发视图关注程序包，应用的统一框架，引用的类库、SDK和中间件，以及工程和包的划分规则等，规范、约束开发环境的结构。

过程视图，流程，描述系统的并发和同步等设计。视业务场景可省略。

场景视图（业务场景），也叫用例视图，描述用户的业务场景和复杂度可省略。

物理视图，也叫部署视图，描述软件如何映射到硬件，反映系统在分布/部署上的设计。物理视图需要解决最终如何安装和部署到服务器，以及网络分布的问题。

Multi-Tenant在数据存储上存在三种主要的方案

1. 独立数据库，一个Tenant一个Database

2. 共享数据库，隔离数据架构。即多个或所有租户共享Database,但一个Tenant一个Schema（表）。

3. 共享数据库，共享数据架构。即租户共享同一个Database、同一个Schema（表）,但在表中通过，TenantID（租户ID）区分租户的数据。

   
   图片2.png

SaaS成熟度模型不同等级的不同特点：

Level 1:设备托管；

Level 2:设备共享、可配置化；

Level 3:多租户、数据隔离、高性能。

第4章 高性能的Multi-Tenant的最佳方案

1. 数据库的优化

1）建立索引 2)消除大数据表连接3)避免复杂SQL

图片3.png

2. 应用层的优化

1）Cache优化：将常用到的用户数据、权限数据放到Cache中，

实施方法：可以考虑在系统启动时即载入Cache,在发生变化的时候，更新Cache。角色则应该在用户登录的时候,获取用户的角色信息，并放入用户Session中。如果cache访问失败，则访问数据库，并重新将其载入Cache中。

2）统计和报表计算

⑴对实时性要求不高的，制作定时任务计算。

⑵历史数据可修改的，对于修改的历史数据，重新计算。

⑶对于实时性要求高的，在原定时任务基础上增加增量的计算。

3）基础Tenant的索引搜索

4）异步操作

3. Web层的性能优化

1）内容类：减少http请求数、减少DNS查找、避免无效的跳转、缓存ajax等

2）服务器业与Cookie类：使用CDN、Gzip压缩网页、配置实体标签、减少cookie体积等。

3）Javascript、CSS、图片类：把脚本置于页面底部、使用外部jS 和CSS、减少不必要的JS和CSS等。

4）移动应用类：保持单个内容小于25K、打包组件成复合文本

4. 性能监控

第五章 多用户应用的可配置性

一、数据可配置

1. 定制字段。

根据客户的需求在数据表上增加相应的定制字段来保存扩展数据。

2. 预分配字段。

预分配字段是指在用户可能有扩展需求的表中预设一定数量的字段。当用户提出扩展需求时，使用其中的一个或多个字段来保存扩展数据。

3. 名称值对

虑将扩展数据的保存与原数据表分离，另外用一张统一的扩展数据表来保存。

三种方案优势比较

图片4.png

功能可配置

实施流程

1. 原子功能划分

拆分原则：每一个原子功能都要能够给用户带来某方面的价值。在保证原子功能对于用户有价值的前提下，功能分解要尽量细化，直到不能再细分为止。

2. 功能包设计

是根据用户的类型和使用的场景，对原子功能进行打包，然后为每一个用户挑选其合适的功能包。功能包的设计要遵循高内聚、低耦合的原则。

二、界面可配置

1. 系统菜单可配置

主要是指不同的租户可以同时购买和使用系统内不同的功能集合。

2. 页面元素可配置

各功能页面上的内容也是供用户与系统交互的界面元素。无论是对页面元素的个数、位置、顺序，还是元素的含义，租户都可能会有一些个性化的需求。

三、流程可配置

四、配置元数据管理

1.对同一种类的多项配置可以进行统一实现。即脱离业务逻辑实现统一公共的数据可配置、功能可配置、界面可配置和流程可配置。出SaaS应用中要管理的可配置参数包括以下几种：表、原子功能、功能包、菜单、页面、页面元素、流程等。对于以上配置类型称之为配置元。

配置元之间存在三种关系类型：包含、依赖、关联。根据上面的抽象，可以得到配置元模型。

3. 租户配置数据

租户配置数据，是指基于配置元模型和配置元数据，由租户管理员根据租户的需要来定义相应的配置信息。

五、可配置系统运行

有关各类配置数据的使用逻辑及调度控制，通过3个特殊的引擎来完成。1.流程可配置数据的使用与控制，由工作流引擎来实现。2.有关扩展数据的查询、使用、提交及相应的检查等，由专门的扩展数据引擎来完成。3.设计单独的功能引擎，负责系统内功能的调度和租户对功能的使用。

1. 系统菜单框架：系统菜单框架需要依赖功能引擎来装载租户菜单所对应的功能。在菜单被单击使用的时候，需要通过功能引擎来实现对原子功能的调度和使用。

2. 功能页面容器

功能页面容器主要解决页面要素展示、页面功能可用性控制、可配置数据展示、可配置数据提交4个方面的问题。

1）页面要素展示就是要根据系统页面的设计和租户的配置，来展示页面上的各种展示要素。如文字、图片、音视频。

2）页面功能可用性控制，就是根据租户购买的原子功能列表，来确定页面内的功能是否可用。如：通话功能、直播发言功能。

3）可配置数据展示，就是根据租户针对页面实体定义可配置数据列表，在页面内自动展示。如：数据列。

4）可配置数据提交，就是根据租户针对页面实体设计的可配置数据项，当页面提交时从界面上收集可配置项的数据内容，与数据实体一并提交。如：数据列可修改保存。

3. 扩展数据引擎

数据可配置性的实现，主要包括扩展数据的展示、扩展数据的提交、扩展数据的校验与保存。

4. 功能引擎

功能引擎，就是要根据租户所购买的功能包，来查找租户所有的“可用原子功能”

集合，结合其购买的期限，来确定当前租户是否可执行相应的<u>功能</u>或<u>操作</u>，以及实现对相应原子功能的调度。