SaaS+架构设计.docx

SaaS+架构设计.docx

《SaaS+架构设计.docx》由会员分享，可在线阅读，更多相关《SaaS+架构设计.docx（12页珍藏版）》请在冰豆网上搜索。

SaaS+架构设计

SaaS+架构设计

SaaS架构设计

SaaS成熟度模型分级

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

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

可配置

高性能

可伸缩性

特点

Level1

定制开发

×

×

×

设备托管

Level2

可配置

√

×

×

设备共享、可配置化

Level3

高性能的多租户架构

（Multi-Tenant）

√

√

×

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

Level4

可伸缩性的多租户架构

√

√

√

RUP“4+1”视图模式（逻辑视图/过程视图/开发视图/物理视图+场景视图）

●场景视图：

用例图，描述用户的业务场景，从用户的角度标识出业务需求，它是架构设计的起点和终点；

●逻辑视图：

就是对象模型。

逻辑视图重点在于功能，功能包括可见的业务功能，也包括不可见的系统功能（如日志、权限、事务等）。

同时更重要的是确立逻辑分层、模块划分和模块之间的依赖关系；

●开发视图：

用于描述开发环境下的静态组织。

从开发环境、技术架构、分层策略和目录结构4个方面阐述；

●过程视图：

聚焦在进程、线程等运行时概念，以及相关的并发、同步、通信等问题。

如果本系统不需要考虑这些方面，本视图可以省略；

●物理视图：

也叫部署视图描述软件如何映射到硬件，反映系统在分布/部署上的设计。

MDA（ModelDrivenArchitecture）模型驱动架构

MDA利用元数据模型，可以方便灵活地实现可配置化。

MDA（ModelDrivenArchitecture）是模型驱动架构，它是由OMG定义的一个软件开发框架。

它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。

和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。

MDA把建模语言用作一种编程语言而不仅仅是设计语言。

MDA的关键之处是模型在软件开发中扮演了非常重要的角色。

SaaS的安全性设计

一般常见的安全性设计分为两类：

系统级和程序级。

系统级：

●使用HTTPS协议以SSL（SecuritySocketLayer）交换数据，增强通信安全；

●通过数字签名防止传输过程篡改；

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

●业务数据定时自动备份；

程序集：

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

●客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；

●辅助安全设计，比如密码控件、图片验证码、手机确认码等；

安全性

　　安全压倒一切。

大多数用户只是问问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区分租户的数据。

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

优点：

三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。

缺点：

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

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

如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。

数据库层性能优化

建立合适的索引

●索引应该创建在条件（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，性能更高

日志记录

日志记录就是要对用户在系统中的操作行为和操作的数据等进行记录，以便对用户在系统中的操作进行查证，以保证用户行为是不可伪造的、不可销毁的、不可否认的。

也就是说，用户在系统中的行为是有据可查的，不能在系统中伪造自己的行为，或者伪造其他用户的行为；同时，用户是不能销毁这些证据的，不能否认自己的行为。

日志记录具体包括两部分：

行为日志记录和数据日志记录。

（1）行为日志记录

行为日志记录就是要对用户在系统中所访问的每一个页面，在各页面中所做的每一个行为都记录下来，记录用户的身份和行为的时刻。

例如，租户A的用户A1在2011年7月13日17:

07:

50访问了XXX系统的重要客户列表页面，做了删除客户信息的操作。

行为日志记录的实现，可以采用面向方法的方案来实现，例如，通过过滤器或拦截器的方式（Spring前置装备），来对所有的页面请求行为及页面里的提交行为多进行拦截，然后将其记录在日志文件里或数据库里。

行为日志记录是辨别用户在系统中行为的一个重要依据，对于系统使用与系统运营分开的SaaS系统就显得尤为重要。

（2）数据日志记录

数据日志记录，就是要对用户在系统中所操作的数据进行记录，记录数据的变更过程及变更的历史。

这在多人操作同一个数据的系统中显得尤为重要。

可以通过流程引擎记录流程日志。

例如，用户A在财务系统中提交了一张财务报销单，报销金额是1000元，在经过了用户B、C、D等一系列人的修改和审批后，用户A看到的报销金额变成了500元，如果没有报销金额的变更日志记录，用户A一定会很疑惑，是谁因为什么原因修改了这个报销金额。

那么，系统就很有必要对报销金额的变更进行日志记录。

（3）日志记录的安全

日志记录是对用户在系统中行为进行查证的依据，是用来跟踪和保障系统安全的，那么，日志记录本身的安全性也是需要重点考虑的。

首先，日志记录应该是只读的，最好能加上时间戳，不应该被认为修改或者伪造；其次，日志记录涉及用户的隐私，应该是保密的，要防止被非法使用。

租户的日志只向Tenant管理员开发，并且Tenant管理员也只能查询租户自己的日志。

数据加密算法（会牺牲一定性能）

1、使用AES对称加密算法；

2、每个企业生成一个数据密钥（生成后不能改变，否则先前加密过的数据无法进行解密）；

3、企业key是利用企业管理员的密码明文去加密存储的，这就要求每个企业在建立时，必须先建立一个管理员；

4、该企业下的每个用户使用其自身的登录密码原文对数据密码进行AES加密，并存储到用户表中。

（密钥加密）；

5、用户保存敏感数据时，使用以准备好的密钥对数据进行AES加密；

加/解密过程：

1、企业注册时，为企业生成一个唯一的key，存放于企业表中；

2、用户注册后，用户表中存放一个利用用户密码明文加密过的企业key；

3、用户登录后，通过密码明文，解密出企业key，并存放到相应位置，待加/解密时使用；

4、用户修改密码时，要使用原密码将企业key解密，并用新密码重新加密保存；

基于SaaS云计算网络性能测试指标

衡量云计算的网络性能根据使用的网络设备不同拥有很多指标。

最常见最关键的性能指标包括以下几项：

新建速率（CPS）、并发数（CC）吞吐量（GoodPut）、响应时间（ResponseTime）。

（1）新建速率

新建速率指通过数据中心中间网络每秒可以处理的TCPSession速率，单位为CPS（ConnectionsPerSecond）。

新建速率中的“新建”是指一个TCPSession成功建立并关闭的整个过程，将TCP关闭方式选择使用TCPFIN报文触发的4次握手关闭方式。

此种方式最符合当前普遍的网络协议应用模型。

在部分特殊业务需求的测试场景下，还可以采用TCPRESET方式进行快速会话关闭，以检验网络系统能够支持的极限性能。

新建速率指标将主要体现数据中心网络设备的CPU运算处理能力。

对新建速率测试开始前，应记录网络处理设备的CPU/Memory等关键性能指标，测试过程中和结束后对这些指标进行监控，实时了解整个网络的运行情况。

（2）并发数

并发数指通过数据中心中间网络可以同时并发存在的最大TCPSession数量，单位为CC（CurrentConnections）。

并发数指标体现了整网会话保持与表项存储的能力，与网络处理设备的内存大小有直接关系。

对于并发数指标测试来说，尤其需要关注其上层协议的具体应用，一个Telnet连接保持1小时与一个http连接保持1小时在协议处理流程上是有很大不同的，应尽量根据实际网络中的业务流量设计测试模型。

（3）吞吐量

吞吐量指当前网络可以有效传输的最大http数据量，也被称为有效吞吐GoodPut，区别于传统意义上的测试指标吞吐量ThroughPut，结果单位为BPS（BytePerSecond）。

吞吐量指标除了受新建速率的直接影响外，还会受到网络中各设备的交换架构、接口总线等元件单位间处理能力的限制，也直接体现了整个网络的应用数据吞吐转发能力。

吞吐量测试结果很大程度上依赖于新建速率能力，其间关系类似于传统吞吐量BPS（BitPerSecond）与网络设备包转发能力PPS（PacketsPerSecond）之间的关系。

在测试吞吐量的过程中，首先测得网络的新建速率，然后将新建速率测试结果乘以一定比率系数，作为吞吐量测试中使用的的稳定新建速率参数始终不变，测试时逐步提高HTTP有效载荷大小，通过观察出现HTTP连接出现失败前的有效载荷最大传输速率，得到其吞吐量测试结果。

（4）响应时间

响应时间指从客户端发起http请求，到得到正确数据响应所经历的时间，一般用来衡量中间网络的综合处理能力，单位为毫秒。

响应时间指标测试方法主要有两种：

一种是基于真实服务器的业务响应时间测试，此测试结果包含了中间网络设备与服务器两部分处理延迟时间；另一种是通过测试仪模拟服务器快速响应请求的测试，这种测试方法可以尽量减少服务器端处理延迟的影响，得到近乎纯粹的网络处理延迟时间。

响应时间测试要在一定的新建速率下进行，这样做也是为了尽量贴近实际网络情况。

但此测试中的新建速率需要维持在一个较低的水平线上，最好是根据真实环境平均值设定，这是因为新建速率较高时会导致CPU资源占用较高，影响设备对连接的处理能力。