SaaS架构设计.doc
《SaaS架构设计.doc》由会员分享，可在线阅读，更多相关《SaaS架构设计.doc（8页珍藏版）》请在冰豆网上搜索。
梦想成就未来java学习笔记作者：
李辉
SaaS架构设计
SaaS架构设计 1
SaaS成熟度模型分级 1
RUP“4+1”视图模式（逻辑视图/过程视图/开发视图/物理视图+场景视图） 2
MDA（ModelDrivenArchitecture）模型驱动架构 2
SaaS的安全性设计 2
安全性 3
SaaS下的安全性设计很重要。
一般常见的安全性设计分为两类：
系统级和程序级。
3
（1） 系统级：
3
（2） 程序级：
3
现在SaaSMulti-Tenant在数据存储上存在三种主要的方案 3
（1） 方案一：
独立数据库 4
（2） 方案二：
共享数据库，隔离数据架构 4
（3） 方案三：
共享数据库，共享数据架构 4
数据库层性能优化 5
建立合适的索引 5
消除大数据表连接 5
应用层性能优化：
Cache 5
日志记录 6
（1） 行为日志记录 6
（2） 数据日志记录 6
（3） 日志记录的安全 6
数据加密算法（会牺牲一定性能） 6
基于SaaS云计算网络性能测试指标 7
（1） 新建速率 7
（2） 并发数 7
（3） 吞吐量 7
（4） 响应时间 8
SaaS成熟度模型分级
根据SaaS应用是否具有可配置性、高性能、可伸缩性的特性，SaaS成熟度模型被分成四级。
每一级都比前一级增加以上三种特性的一种。
可配置
高性能
可伸缩性
特点
Level1
定制开发
×
×
×
设备托管
Level2
可配置
√
×
×
设备共享、可配置化
Level3
高性能的多租户架构
（Multi-Tenant）
√
√
×
多租户、数据隔离、高性能
Level4
可伸缩性的多租户架构
√
√
√
RUP“4+1”视图模式（逻辑视图/过程视图/开发视图/物理视图+场景视图）
l场景视图：
用例图，描述用户的业务场景，从用户的角度标识出业务需求，它是架构设计的起点和终点；
l逻辑视图：
就是对象模型。
逻辑视图重点在于功能，功能包括可见的业务功能，也包括不可见的系统功能（如日志、权限、事务等）。
同时更重要的是确立逻辑分层、模块划分和模块之间的依赖关系；
l开发视图：
用于描述开发环境下的静态组织。
从开发环境、技术架构、分层策略和目录结构4个方面阐述；
l过程视图：
聚焦在进程、线程等运行时概念，以及相关的并发、同步、通信等问题。
如果本系统不需要考虑这些方面，本视图可以省略；
l物理视图：
也叫部署视图描述软件如何映射到硬件，反映系统在分布/部署上的设计。
MDA（ModelDrivenArchitecture）模型驱动架构
MDA利用元数据模型，可以方便灵活地实现可配置化。
MDA（ModelDrivenArchitecture）是模型驱动架构，它是由OMG定义的一个软件开发框架。
它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。
和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。
MDA把建模语言用作一种编程语言而不仅仅是设计语言。
MDA的关键之处是模型在软件开发中扮演了非常重要的角色。
SaaS的安全性设计
一般常见的安全性设计分为两类：
系统级和程序级。
系统级：
l使用HTTPS协议以SSL（SecuritySocketLayer）交换数据，增强通信安全；
l通过数字签名防止传输过程篡改；
l对用户身份识别的UserToken使用DES算法数据加密；
l业务数据定时自动备份；
程序集：
l完整的权限配置，包括功能权限和数据权限；
l客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；
l辅助安全设计，比如密码控件、图片验证码、手机确认码等；
安全性
安全压倒一切。
大多数用户只是问问SaaS厂商是不是采用了安全套接层（SSL）技术，而安全性涵盖的不仅仅只有这个方面。
要向潜在的SaaS厂商询问下列问题：
●放置服务器的数据中心有没有24×7全天候的物理安全措施？
●数据中心有没有得到保护（保安是不是24小时在周围至少巡视一次）？
●谁有权访问这些服务器（只有内部员工可以访问，还是承包商也可以访问？
）
●有没有日志记录谁何时进入、何时离开？
如果有日志，那么隔多长时间审计这些日志？
●应用程序有没有使用基于行业标准的128位加密技术？
●如果多个客户使用的应用程序放在同一台服务器上，那么它们有没有采用逻辑或物理分隔，从而确保你的数据不被未授权的人所看到？
●SaaS厂商中可以访问你企业数据的工作人员有没有经过犯罪背景调查？
知道被定罪的重罪犯是不能访问你企业那些敏感的个人数据，这很重要。
●厂商有没有正规的业务连续性方案（BCP）？
对方愿不愿意与你共享该方案、它能消除你的担忧吗？
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区分租户的数据。
这是共享程度最高、隔离级别最低的模式。
优点：
三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；
数据备份和恢复最困难，需要逐表逐条备份和还原。
如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
数据库层性能优化
建立合适的索引
l索引应该创建在条件（where）、排序（orderby）、分组（groupby）等操作所涉及的列上；
l索引应该有较强的选择性，即应尽可能建立在重复数据少的数据列中；
l如果多个条件经常需要组合起来查询，应合理使用联合索引；
l一次查询中只能使用一个索引，可使用相应的分析工具分析索引效果；
l索引不是越多越好（一个表最好在5个索引以内），过多的索引可能导致CUD（新增、修改、删除）的性能降低，并且占用更多的空间。
消除大数据表连接
消除表连接的几种解决方案
解决方案
适用场景
示例场景
冗余存储关联字段
业务需求上可以接受冗余导致的不一致，或者冗余数据可以很容易被同步更新
订单列表查询时，希望查看到订单的客户名称，原本订单上只记录了客户ID，通过关联客户表查询客户名称
Cache缓存
变动概率不高，但是对于数据一致性要求较高
用户名（USER_NAME）被很多业务所关联查询，但是也不适用于冗余方案（业务上不允许不一致，并且要保持所有冗余存储的地方同步更新很困难）
直接删除关联字段
不是必须包含的被关联表的字段，可以直接从列表查询中去除
订单列表中的产品型号等非关键字段，其实并不一定要包含在订单列表中
拆分成多次查询
对于单个数据的查询，如果涉及多张关联表，有时分多次查询会比一次复杂的关联查询更为合适
订单表单中需要查询到关联产品的编码、型号等很多字段
应用层性能优化：
Cache
其实很难说Cache就是应用层性能的优化策略。
因为大部分情况下，Cache所缓存的内容就是数据库中存储的内容。
采用Cache策略其实也是对数据库层的一种优化，因为其避免了对于数据库的频繁访问。
MemCached和JBossCache应该是两类比较典型的Cache。
MemCached
JBossCache
特性
1、基于Client/Server架构
2、只有一份数据Copy，不需要数据同步
基于JGroup多播的分布式Cache
优势
不需要数据同步，避免复杂的多播等技术
Cache读取基于本地Memory，性能更高
日志记录
日志记录就是要对用户在系统中的操作行为和操作的数据等进行记录，以便对用户在系统中的操作进行查证，以保证用户行为是不可伪造的、不可销毁的、不可否认的。
也就是说，用户在系统中的行为是有据可查的，不能在系统中伪造自己的行为，或者伪造其他用户的行为；同时，用户是不能销毁这些证据的，不能否认自己的行为。
日志记录具体包括两部分：
行为日志记录和数据日志记录。
（1）行为日志记录
行为日志记录就是要对用户在系统中所访问的每一个页面，在各页面中所做的每一个行为都记录下来，记录用户的身份和行为的时刻。
例如，租户A的用户A1在2011年7月13日17:
07:
50访问了XXX系统的重要客户列表页面，做了删除客户信息的操作。
行为日志记录的实现，可以采用面向方法的方案来实现，例如，通过过滤器或拦截器的方式（Spring前置装备），来对所有的页面请求行为及页面里的提交行为多进行拦截，然后将其记录在日志文件里或数据库里。
行为日志记录是辨别用户在系统中行为的一个重要依据，对于系统使用与系统运营分开的SaaS系统就显得尤为重要。
（2）数据日志记录
数据日志记录，就是要对用户在系统中所操作的数据进行记录，记录数据的变更过程及变更的历史。
这在多人操作同一个数据的系统中显得尤为重要。
可以通过流程引擎记录流程日志。
例如，用户A在财务系统中提交了一张财务报销单，报销金额是1000元，在经过了用户B、C、D等一系列人的修改和审批后，用户A看到的报销金额变成了500元，如果没有报销金额的变更日志记录，用户A一定会很疑惑，是谁因为什么原因修改了这个报销金额。
那么，系统就很有必要对报销金额的变更进行日志记录。
（3）日志记录的安全
日志记录是对用户在系统中行为进行查证的依据，是用来跟踪和保
升级会员 