根据SaaS应用是否具有可配置性、高性能、可伸缩性的特性，SaaS成熟度模型被分成四级。每一级都比前一级增加以上三种特性的一种。
Level1定制开发:有一个客户项目，就按客户需求定制一个版本，每个客户的软件都有一份独立的代码，不同客户软件之间可以共享和重用的只有少量的可重用组件、库以及开发人员的经验
Level2可配置:客户可以通过简单的配置，让通用型的软件能够满足自己的一些个性经需求。为每个客户独立部署一个运行实例，只不过每个运行实例运行的是同一份代码。
Level3高性能的多租户架构:多租户单实例的应用架构才是通常真正意义上的SAAS应用架构，也就是我们通常所说的Multi-Tenant架构。
Level4可伸缩性的多租户架构：在用户数大量增长情况下，无须更改架构，而仅通过硬件设备的增加，支撑应用规模的增长
1.5 SaaS平台的应用 企业内部管理办公自动化（OA）、客户关系管理（CRM）、供应链管理（SCM）、人力资源管理（HR）、项目管理（PM）、内容管理（CM）等管理系统大量应用在企业内部的管理中。 外部展示服务动态网站、网站商铺、在线定单、产品目录、会员注册、下载中心、物流跟踪等应用系统借助互联网的普及和浏览的方便性使得SaaS平台得到网络式的广泛应用。 工具软件E-MAIL、短信、QQ、MSN、彩信、即时通讯、在线应用开发工具、在线客户化工具、在线自主建站等工具软件也迅速地得到发展。
3. 应用场景分析1.6 企业注册、开通过程 应用场景分析 企业要使用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.8 多层体系的架构设计
图1 多层体系的架构设计
合作方：企业、客户、开发商、代理商、运营商、其他（如银行、政府）
系统用户：平台管理员、企业管理员、企业普通用户、平台运维人员、合作伙伴
接入设备：个人电脑、PDA、手机、Kiosk机
层次划分：企业信息门户层、业务管理层、系统平台服务层、业务应用层、数据库层、系统安全平台。其中系统安全平台跨越业务管理层、系统平台服务层、业务应用层,是整个系统的安全管理中心
归纳整合：企业信息门户层：负责终端设备的接口的定义、接入、及界面定制，企业信息门户的统一管理。
业务管理层：负责业务应用服务管理，包括企业、客户、合作伙伴、组织机构
用户角色、权限及计费等的统一管理。
系统平台服务层：负责系统资源、数据管理及平台所提供的服务，是系统的核心。 业务应用层：平台所提供的业务应用模块。 数据库层：数据的访问链接及控制。 系统安全平台：负责系统的安全保障，包括安全基础设施、业务应用系统安全、
安全管理保障体系等，是系统的核心。理论依据与参考：分布式层次结构的思想。企业IT服务规范。IBM 软件解决方案。
1.9 基于构件库的架构设计
图2 基于构件库的架构设计
接入设备：个人电脑、PDA、手机、离线应用。
服务：数据交换服务、人员/权限管理、部件管理服务、离线拉入服务、表单引擎、工作流引擎。
构件库：企业级应用系统（如HR、CRM）、系统安全平台、邮件系统、个人事务、业务报表、流程管理、文档管理、会议管理、任务管理、通知公告
归纳整合：企业信息门户层：负责终端设备的接口的定义、接入、及界面定制，企业信息门统一管理。
构件库层：负责业务应用服务管理。
数据库层：数据的访问链接及控制。
系统安全平台：负责系统的安全保障，包括安全基础设施、业务应用系统安全、安全管理保障体系等，是系统的核心。
理论依据与参考：分布式层次结构的思想。企业IT服务规范。
5. SaaS平台逻辑架构
图3 平台逻辑架构 用户层 企业用户通过终端设备访问远程SaaS服务平台的业务应用系统。用户包括企业、客户、开发商、代理商、运营商、其他（如银行、政府）等个人或者单位。用户按角色分为：平台管理员、企业管理员、企业普通用户、平台运维人员、合作伙伴。 隔离区 隔离区的的目标是确保把有害的攻击隔离，在可信网络之外和保证可信网络内部信息不外泄的前提下，完成网间数据的安全交换。 负载均衡负载均衡是把改变网络的数据流量集中在中心服务器一端，通过对访问服务器的负载进行均衡（或者说分担）措施来减少对中心服务器的压力。负载均衡，从结构上分为本地负载均衡和地域负载均衡(全局负载均衡)，前一种是指对本地的服务器集群做负载均衡，后一种是指对分别放置在不同的地理位置、在不同的网络及服务器群集之间作负载均衡。每个主机运行一个所需服务器程序的独立拷贝，诸如Web、FTP、Telnet或e-mail服务器程序。对于某些服务（如运行在Web服务器上的那些服务）而言，程序的一个拷贝运行在群集内所有的主机上，而网络负载均衡则将工作负载在这些主机间进行分配。对于其他服务（例如e-mail），只有一台主机处理工作负载，针对这些服务，网络负载均衡允许网络通讯量流到一个主机上，并在该主机发生故障时将通讯量移至其他主机。 多级防火墙 防火墙就是一个位于计算机和它所连接的网络之间的软件。该计算机流入流出的所有网络通信均要经过此防火墙。防火墙对流经它的网络通信进行扫描，这样能够过滤掉一些攻击，以免其在目标计算机上被执行。防火墙还可以关闭不使用的端口。而且它还能禁止特定端口的流出通信，封锁特洛伊木马。最后，它可以禁止来自特殊站点的访问，从而防止来自不明入侵者的所有通信。 核心区 核心区是SaaS平台的核心组成部分。是平台与各业务系统的连接纽带。它能驱动各模块的运转，解析业务系统的独立运行。同时提供各终端设备的接口上驱动。 应用系统符合SaaS平台的规范，按SaaS平台标准开发的提供给用户服务的业务系统。
使用HTTPS协议以SSL（Security Socket Layer）交换数据，增强通信安全；
通过数字签名防止传输过程篡改；
对用户身份识别的UserToken使用DES算法数据加密；
业务数据定时自动备份。
完整的权限配置，包括功能权限和数据权限；
客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；
辅助安全设计，比如密码控件、图片验证码、手机确认码等。
这是第一种方案，即一个Tenant一个Database（见图3-14），这种方案的用户数据隔离级别最高，安全性最好，但成本也高。
优点：
为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；
如果出现故障，恢复数据比较简单。
缺点：
增大了数据库的安装数量，随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。
这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个Schema。
优点：
为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；
每个数据库可以支持更多的租户数量。
缺点：
如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；
如果需要跨租户统计数据，存在一定困难。
这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。
优点：
三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；
数据备份和恢复最困难，需要逐表逐条备份和还原。
如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
● 索引应该创建在条件（where）、排序（order by）、分组（group by）等操作所涉及的列上；
● 索引应该有较强的选择性，即应尽可能建立在重复数据少的数据列中；
● 如果多个条件经常需要组合起来查询，应合理使用联合索引；
● 一次查询中只能使用一个索引，可使用相应的分析工具分析索引效果；
● 索引不是越多越好（一个表最好在5个索引以内），过多的索引可能导致CUD（新增、修改、删除）的性能降低，并且占用更多的空间。
● 索引应该创建在条件（where）、排序（order by）、分组（group by）等操作所涉及的列上；
● 索引应该有较强的选择性，即应尽可能建立在重复数据少的数据列中；
● 如果多个条件经常需要组合起来查询，应合理使用联合索引；
● 一次查询中只能使用一个索引，可使用相应的分析工具分析索引效果；
● 索引不是越多越好（一个表最好在5个索引以内），过多的索引可能导致CUD（新增、修改、删除）的性能降低，并且占用更多的空间。
消除表连接的几种解决方案
其实很难说Cache就是应用层性能的优化策略。因为大部分情况下，Cache所缓存的内容就是数据库中存储的内容。采用Cache策略其实也是对数据库层的一种优化，因为其避免了对于数据库的频繁访问。
MemCached和JBoss Cache应该是两类比较典型的Cache。
本文来源：https://www.2haoxitong.net/k/doc/7c96d00676c66137ee06196b.html
文档为doc格式