SaaS模式设计总结.docx

SaaS模式设计总结.docx

《SaaS模式设计总结.docx》由会员分享，可在线阅读，更多相关《SaaS模式设计总结.docx（15页珍藏版）》请在冰点文库上搜索。

SaaS模式设计总结

SaaS架构设计

SaaS成熟度模型分级

依照SaaS应用是不是具有可配置性、高性能、可伸缩性的特性，SaaS成熟度模型被分成四级。

每一级都比前一级增加以上三种特性的一种。

可配置

高性能

可伸缩性

特点

Level1

定制开发

×

×

×

设备托管

Level2

可配置

√

×

×

设备共享、可配置化

Level3

高性能的多租户架构

（Multi-Tenant）

√

√

×

多租户、数据隔离、高性能

Level4

可伸缩性的多租户架构

√

√

√

支撑应用规模的增长

Level1定制开发:

有一个客户项目，就按客户需求定制一个版本，每一个客户的软件都有一份独立的代码，不同客户软件之间能够共享和重用的只有少量的可重用组件、库和开发人员的体会

Level2可配置:

客户能够通过简单的配置，让通用型的软件能够知足自己的一些个性经需求。

为每一个客户独立部署一个运行实例，只只是每一个运行实例运行的是同一份代码。

Level3高性能的多租户架构:

多租户单实例的应用架构才是通常真正意义上的SAAS应用架构，也确实是咱们通常所说的Multi-Tenant架构。

Level4可伸缩性的多租户架构：

在用户数大量增加情形下，不必更改架构，而仅通过硬件设备的增加，支撑应用规模的增加

 SaaS平台的应用

 企业内部治理

办公自动化（OA）、客户关系治理（CRM）、供给链治理（SCM）、人力资源治理（HR）、项目治理（PM）、内容治理（CM）等治理系统大量应用在企业内部的治理中。

 外部展现效劳

动态网站、网站商铺、在线定单、产品目录、会员注册、下载中心、物流跟踪等应用系统借助互联网的普及和阅读的方便性使得SaaS平台取得式的普遍应用。

 工具软件

E-MAIL、短信、QQ、MSN、彩信、即时通信、在线应用开发工具、在线客户化工具、在线自主建站等工具软件也迅速地取得进展。

3. 应用处景分析

 企业注册、开通进程

 应用处景分析

   企业要利用SaaS平台系统，但是SaaS平台所提供的效劳不只一个，因此应该明白他是需要利用哪个软件。

软件是分为模块的，有些模块是用户所需要租用的，有的可能用户是不关切的，不同模块功能不同，访问权限及访问方式不同，同时价钱也不同，因此，企业注册时应该清楚自己注册的是哪级模块。

不同企业有不同要求，如企业1要求数据要独立寄存，咱们就应该为企业1开辟独立的数据库。

企业2要求他的数据放在自己的数据上，这时咱们的数据地址要指向企业2的数据效劳器地址，因此SaaS平台的所有应用系统的数据连接都是动态的由平台来治理的。

   企业申请后，咱们是要审核其合法性，如租用的资金到帐没有，企业是不是可联系到人。

通过审核合法，咱们开通其申请，这时平台治理员分派给相应企业帐号及业务模块、就近原那么分派应用效劳器、数据库并成立企业治理员帐号及权限。

   最后通知申请成功并转告登录帐号及其功能等。

   企业治理员通过企业的帐号（包括企业号、用户名、密码）登录到应用系统中，成立企业内的用户并分派对应的权限。

   企业用户通过本企业的企业号、用户帐号、密码就能够够登录到自己所有权限范围内的模块了。

用户界面设计  

1. 企业注册

图1  企业注册

2. 软件注册增加界面

图2  软件注册增加界面

 框架设计 

 图3 框架设计

 用例设计

  图4 用例设计

 层次关系图

图5 层次关系图

 数据库设计

图6 数据库设计

SaaS平台按前后顺序要做的事一一列出。

1.提供业务系统注册

2.提供企业注册申请，业务开通

3.提供企业内部用户业务权限分派

4.用户登录访问

5.提供用户填写日记

咱们要知足以上用户要求，保障系统正常运行平台所要做的是：

1.平安保障

2.数据存储

3.数据同步

4.设备接入

5.效劳器不中断

6.分流

7.计费

4. SaaS平台整体框架设计

 多层体系的架构设计

图1 多层体系的架构设计

合作方：

企业、客户、开发商、代理商、运营商、其他（如银行、政府）

系统用户：

平台治理员、企业治理员、企业一般用户、平台运维人员、合作伙伴

接入设备：

个人电脑、PDA、、Kiosk机

层次划分：

企业信息门户层、业务治理层、系统平台效劳层、业务应用层、数据库层、系统平台。

其中系统平安平台跨越业务治理层、系统平台效劳层、业务应用层,是整个系统的平安治理中心

归纳整合：

企业信息门户层：

负责终端设备的接口的概念、接入、及界面定制，企业信息门户的统一治理。

业务治理层：

负责业务应用效劳治理，包括企业、客户、合作伙伴、组织机构

用户角色、权限及计费等的统一治理。

系统平台效劳层：

负责系统资源、数据治理及平台所提供的效劳，是系统的核心。

  业务应用层：

平台所提供的业务应用模块。

  数据库层：

数据的访问链接及操纵。

  系统平安平台：

负责系统的平安保障，包括平安基础设施、业务应用系统平安、

平安治理保障体系等，是系统的核心。

理论依据与参考：

散布式层次结构的思想。

企业IT效劳标准。

IBM解决方案。

 基于构件库的架构设计

图2 基于构件库的架构设计

接入设备：

个人电脑、PDA、电话、离线应用。

服务：

数据互换效劳、人员/权限治理、部件治理效劳、离线拉入效劳、表单引擎、工作流引擎。

构件库：

企业级应用系统（如HR、CRM）、系统平安平台、邮件系统、个人事务、业务报表、流程治理、文档治理、会议治理、任务治理、通知公告

归纳整合：

企业信息门户层：

负责终端设备的接口的概念、接入、及界面定制，企业信息门统一治理。

构件库层：

负责业务应用效劳治理。

数据库层：

数据的访问链接及操纵。

系统平安平台：

负责系统的平安保障，包括平安基础设施、业务应用系统平安、平安治理保障体系等，是系统的核心。

理论依据与参考：

散布式层次结构的思想。

企业IT效劳标准。

5. SaaS平台逻辑架构

图3 平台逻辑架构

 用户层

   企业用户通过终端设备访问远程SaaS效劳平台的业务应用系统。

用户包括企业、客户、开发商、代理商、运营商、其他（如银行、政府）等个人或单位。

用户按角色分为：

平台治理员、企业治理员、企业一般用户、平台运维人员、合作伙伴。

 隔离区

   隔离区的的目标是确保把有害的解决隔离，在可信之外和保证可信网络内部信息不外泄的前提下，完成网间数据的互换。

负载均衡是把改变网络的数据流量集中在中心一端，通过对访问的负载进行均衡（或说分担）方法来减少对中心效劳器的压力。

负载均衡，从结构上分为本地负载均衡和地域负载均衡（全局负载均衡），前一种是指对本地的效劳器集群做负载均衡，后一种是指对别离放置在不同的地理位置、在不同的网络及效劳器群集之间作负载均衡。

每一个主机运行一个所需效劳器程序的独立拷贝，诸如Web、FTP、Telnet或e-mail效劳器程序。

关于某些效劳（如运行在Web效劳器上的那些效劳）而言，程序的一个拷贝运行在群集内所有的主机上，而网络负载均衡那么将工作负载在这些主机间进行分派。

关于其他效劳（例如e-mail），只有一台主机处置工作负载，针对这些效劳，网络负载均衡许诺网络通信量流到一个主机上，并在该主机发生故障时将通信量移至其他主机。

 多级防火墙

   防火墙确实是一个位于运算机和它所连接的网络之间的。

该运算机流入流出的所有网络均要通过此防火墙。

防火墙对流经它的网络通信进行扫描，如此能够过滤掉一些解决，以避免其在目标运算机上被执行。

防火墙还能够关闭不利用的端口。

而且它还能禁止特定端口的流出通信，封锁特洛伊木马。

最后，它能够禁止来自特殊站点的访问，从而避免来自不明入侵者的所有通信。

 核心区

   核心区是SaaS平台的核心组成部份。

是平台与各业务系统的连接纽带。

它能各模块的运转，解析业务系统的独立运行。

同时提供各终端设备的接口上驱动。

 应用系统

符合SaaS平台的标准，按SaaS平台标准开发的提供给用户效劳的业务系统。

SaaS下的平安性设计很重要。

一样常见的平安性设计分为两类：

系统级和程序级。

（1）系统级：

利用HTTPS协议以SSL（SecuritySocketLayer）互换数据，增强通信平安；

通过数字签名避免传输进程窜改；

对用户身份识别的UserToken利用DES算法数据加密；

业务数据按时自动备份。

（2）程序级：

完整的权限配置，包括功能权限和数据权限；

客户端输入校验，避免JS解决、XSS解决、SQL注入等；

辅助平安设计，比如密码控件、图片验证码、电话确认码等。

此刻SaaSMulti-Tenant在数据存储上存在三种要紧的方案

（1）方案一：

独立数据库

这是第一种方案，即一个Tenant一个Database（见图3-14），这种方案的用户数据隔离级别最高，平安性最好，但本钱也高。

优势：

为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，知足不同租户的独特需求；

若是显现故障，恢复数据比较简单。

缺点：

增大了数据库的安装数量，随之带来保护本钱和购买本钱的增加。

这种方案与传统的一个客户、一套数据、一套部署类似，不同只在于软件统一部署在运营商那里。

若是面对的是银行、医院等需要超级高数据隔离级别的租户，能够选择这种模式，提高租用的定价。

若是定价较低，产品走低价线路，这种方案一样对运营商来讲是无法经受的。

（2）方案二：

共享数据库，隔离数据架构

这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个Schema。

优势：

为平安性要求较高的租户提供了必然程度的逻辑数据隔离，并非是完全隔离；

每一个数据库能够支持更多的租户数量。

缺点：

若是显现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；

若是需要跨租户统计数据，存在必然困难。

（3）方案三：

共享数据库，共享数据架构

这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。

这是共享程度最高、隔离级别最低的模式。

优势：

三种方案比较，第三种方案的保护和购买本钱最低，许诺每一个数据库支持的租户数量最多。

缺点：

隔离级别最低，平安性最低，需要在设计开发时加大对平安的开发量；

数据备份和恢复最困难，需要逐表逐条备份和还原。

若是希望以最少的效劳器为最多的租户提供效劳，而且租户同意以捐躯隔离级别换取降低本钱，这种方案最适合。

数据库层性能优化

成立适合的索引

索引应该创建在条件（where）、排序（orderby）、分组（groupby）等操作所涉及的列上；

索引应该有较强的选择性，即应尽可能成立在重复数据少的数据列中；

若是多个条件常常需要组合起来查询，应合理利用联合索引；

一次查询中只能利用一个索引，可利用相应的分析工具分析索引成效；

索引不是越多越好（一个表最好在5个索引之内），过量的索引可能致使CUD（新增、修改、删除）的性能降低，而且占用更多的空间。

数据库层性能优化

成立适合的索引

索引应该创建在条件（where）、排序（orderby）、分组（groupby）等操作所涉及的列上；

索引应该有较强的选择性，即应尽可能成立在重复数据少的数据列中；

若是多个条件常常需要组合起来查询，应合理利用联合索引；

一次查询中只能利用一个索引，可利用相应的分析工具分析索引成效；

索引不是越多越好（一个表最好在5个索引之内），过量的索引可能致使CUD（新增、修改、删除）的性能降低，而且占用更多的空间。

排除大数据表连接

排除表连接的几种解决方案

解决方案

适用场景

示例场景

冗余存储关联字段

业务需求上可以接受冗余导致的不一致，或者冗余数据可以很容易被同步更新

订单列表查询时，希望查看到订单的客户名称，原本订单上只记录了客户ID，通过关联客户表查询客户名称

Cache缓存

变动概率不高，但是对于数据一致性要求较高

用户名（USER_NAME）被很多业务所关联查询，但是也不适用于冗余方案（业务上不允许不一致，并且要保持所有冗余存储的地方同步更新很困难）

直接删除关联字段

不是必须包含的被关联表的字段，可以直接从列表查询中去除

订单列表中的产品型号等非关键字段，其实并不一定要包含在订单列表中

拆分成多次查询

对于单个数据的查询，如果涉及多张关联表，有时分多次查询会比一次复杂的关联查询更为合适

订单表单中需要查询到关联产品的编码、型号等很多字段

应用层性能优化：

Cache

其实很难说Cache确实是应用层性能的优化策略。

因为大部份情形下，Cache所缓存的内容确实是数据库中存储的内容。

采纳Cache策略其实也是对数据库层的一种优化，因为其幸免了关于数据库的频繁访问。

MemCached和JBossCache应该是两类比较典型的Cache。

MemCached

JBossCache

特性

1、基于Client/Server架构

2、只有一份数据Copy，不需要数据同步

基于JGroup多播的分布式Cache

优势

不需要数据同步，避免复杂的多播等技术

Cache读取基于本地Memory，性能更高