基于云计算的SaaS领域服务平台

基于云计算的SaaS领域服务平台建设

总

体

规

划

说

明

书

目 录

1 引言........................................................................................................................................... 4

1.1 编写目的 ................................................................................................................... 4

1.2 项目背景 ................................................................................................................... 4

1.3 参考资料 ................................................................................................................... 5

1.4 术语缩写与解释 ....................................................................................................... 5

总体规划 ................................................................................................................................... 6

2.1 建设目标 ................................................................................................................... 6

2.2 技术路线 ................................................................................................................... 7

2.2.1 一站式服务平台 ............................................................................................... 7

2.2.2 应急服务平台 ................................................................................................... 9

2.2.3 通用后台 ........................................................................................................... 9

2.3 基本流程 ................................................................................................................. 11

2.4 支撑环境 ................................................................................................................. 12

2.4.1 开发环境 ......................................................................................................... 12

2.4.2 系统运行环境 ................................................................................................. 12

2.4.3 数据库环境 ..................................................................................................... 12

2.5 局限性 ..................................................................................................................... 12

2.6 技术可行性 ............................................................................................................. 12

总体设计 ................................................................................................................................. 13

3.1 系统逻辑结构 ......................................................................................................... 13

3.2 技术架构 ................................................................................................................. 14

3.3 应用服务层设计 ..................................................................................................... 16

3.3.1 通用后台 ......................................................................................................... 16

3.3.2 面向领域的服务 ............................................................................................. 17

3.4 SAAS服务层设计 ................................................................................................... 17

3.5 接口设计 ................................................................................................................. 17

3.5.1 用户接口 ......................................................................................................... 17

3.5.2 外部接口 ......................................................................................................... 17

3.5.3 内部接口 ......................................................................................................... 17

3.6 运行设计 ................................................................................................................. 18

3.6.1 运行模块组合 ................................................................................................. 18

3.6.2 运行控制 ......................................................................................................... 18

3.6.3 运行时间 ......................................................................................................... 18

3.7 数据库设计 ............................................................................................................. 18

3.7.1 逻辑结构设计要点 ......................................................................................... 18

3.7.2 物理结构设计要点 ......................................................................................... 18

3.7.3 数据结构与程序的关系 ................................................................................. 18

3.7.4 规范要求 ......................................................................................................... 18

3.8 系统出错处理设计 ................................................................................................. 19

3.8.1 出错信息 ......................................................................................................... 19

3.8.2 补救措施 ......................................................................................................... 19

3.8.3 系统维护设计 ................................................................................................. 20

2

3

4

5

安全性设计 ............................................................................................................................. 20

4.1.1 安全架构 ......................................................................................................... 20

4.1.2 多企业数据隔离设计 ..................................................................................... 22

实施步骤 ................................................................................................................................. 23

1 引言

1.1 编写目的

本文档旨在为基于云计算的SaaS领域服务平台建设项目从项目目标、技术路线、技术要求、实施方法等方面做出规划，便于公司内部市场人员、开发人员和管理人员等在项目理解和实施等方面达成共识。

1.2 项目背景

SaaS是Software-as-a-Service（软件即服务）的简称，是随着互联网技术的发展和应用软件的成熟，而在21世纪开始兴起的一种完全创新的软件应用模式。它是一种通过lnternet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。

在这种模式下，客户不再像传统模式那样花费大量投资用于硬件、软件、人员，而只需要支出一定的租赁服务费用，通过互联网便可以享受到相应的硬件、软件和维护服务，享有软件使用权和不断升级，这是网络应用最具效益的营运模式。

Cloud Computing（云计算）是一种新兴的共享基础架构的方法，通常为一些大型服务器集群，包括计算服务器、存储服务器、宽带资源等等，它可以将巨大的系统池连接在一起以提供各种IT服务。云计算将所有的计算资源集中起来，并由软件实现自动管理，无需人为参与。这使得企业无需为繁琐的细节而烦恼，能够更加专注于自己的业务，有利于创新。

SaaS出租软件服务，云计算出租网络资源

云计算的出现，恰好解决了SaaS发展过程中面临的一些问题，当SaaS提供

商的客户快速增加到一定程度，客户所消耗的巨大资源将迫使SaaS供应商提供更多的硬件资源，但由于成本的问题，SaaS又不想花费大量资金购买硬件或带宽资源的时候，云计算无疑是个不错的选择。

根据通常的概念，云计算处于SaaS的更底层，而SaaS位于云计算和最终客户之间，如果SaaS在最初开发的时候是基于云计算架构的，那么就很容易利用云计算架构来获取海量的资源，并提供给最终用户。这就一劳永逸的解决SaaS发展的瓶颈问题。

通常情况下，SaaS供应商更专注于软件的开发，而对网络资源管理的关注，往往会浪费大量资金购买服务器和带宽等基础设施，但提供的用户负载依然有限，而云计算提供了一种管理网络资源的简单而高效的机制，其分配计算任务、工作负载重新平衡、动态分配资源等等，可以帮助SaaS厂商提供不可想象的巨大资源给海量的用户，SaaS供应商可以不再在服务器和带宽等基础设施上浪费自己的资源，而专注于具体的软件开发和应用，从而达到最终用户、SaaS、云计算三方的共赢。

由此可见，云计算在企业软件市场上具有相当大的潜力，对于SaaS供应商来说也是一大机遇，我们可以选择云计算平台，使用云计算的基础架构，使用极其低廉的价格为海量的用户群提供更为稳定、快速、安全的应用和服务。

本项目拟建设一个基于云计算的领域服务平台。在该平台上，可为中小企业提供包括CRM、应急管理、3D应用等领域的SaaS服务。

1.3 参考资料

1.4 术语缩写与解释

SaaS（Software as a Service，软件即服务）是应用软件的一种销售方式，客户按使用时间或使用量付费。这些应用软件通常是在企业管理软件领域，并通过互联网来使用。SaaS（软件即服务）具备这个特点：“软件部署为托管服务，通过因特网存取。”

SOA（Service-Oriented Architecture，面向服务架构）是一个面向服务的架构模型，它将应用程序的不同功能单元——服务（service），通过服务间定义良

好的接口和契约（contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。

云计算（Cloud Computing）是基于互联网的商业计算模型。利用高速互联网的传输能力，将数据的处理过程从个人计算机或服务器移到互联网上的服务器集群中。这些服务器由一个大型的数据处理中心管理着，数据中心按客户的需要分配计算资源，达到与超级计算机同样的效果。

服务级别协议（SLA）是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。典型的服务级别协议包括下列内容：

 参与各方对所提供服务及协议有效期限的规定；

 服务提供期间的时间规定，包括测试、维护和升级；

 对用户数量、地点以及/或提供的相应硬件的服务的规定；

 对故障报告流程的说明，包括故障升级到更高水平支持的条件。应包括对故障报告期望的应答时间的规定；

 对变更请求流程的说明。可能包括完成例行的变更请求的期望时间；

 对服务级别目标的规定；

 与服务相关的收费规定；

 用户责任的规定(用户培训、确保正确的桌面配置、没有不必要的软件、没有妨碍变更管理流程等)；

 对解决与服务相关的不同意见的流程说明。

2 总体规划

2.1 建设目标

为了满足中小企业日益增长的信息化管理需求，公司借鉴SaaS模式的思想，自主开发基于云计算的领域服务平台，按服务水平协议（SLA），为中小企业提供所需的CRM、应急管理、3D应用等一系列SaaS服务。

2.2 技术路线

云计算的使用模式即服务化。所谓服务化，即服务消费者只需提供服务的请求，并提交服务的输入，而不关心服务的实现方法、技术和流程，而直接得到服务的结果。云计算的服务模式包括：将软件作为服务SaaS (Software as a Service)、将平台作为服务PaaS (Platform as a Service)和将基础设施作为服务IaaS

(Infrastructure as a Service)等各种模式。

领域服务（SaaS）平台服务（PaaS）基础设施服务CRM（IaaS）3D应用应急管理

根据公司现有技术基础和产品线规划，本项目拟在正邦通用后台的基础上包裹不同的业务应用模块，形成一站式服务平台和应急服务平台，针对用户的不同业务需求进行功能配置、提供个性化服务。

2.2.1 一站式服务平台

一站式服务平台是针对中小企业日常办公协同管理、客户资源管理等需求开发的一套基于SaaS模式的服务软件。如图所示。

CallCenterCRM物流系统一站式服务通用平台产品系统媒体效能付给付给$付给$$

协同办公专业培训图 一站式服务平台

订单系统

CRM：包括客户资料、联系人、活动记录、产品、商机、订单、收款单、竞争对手、销售宣传资料、市场、服务、报表、多角度BI商业智能分析等管理及基础设置，对企业的销售环节进行全面的过程管理。通过CRM管理，业务部可以通过对销售环节的管控，全面掌握与客户的销售过程，对未来的销售收入进行预估，从而不断调整销售过程中的相关策略，直至赢得客户，形成订单；同时通过跟进转换，了解客户的应收帐款的情况，进而对客户进行全面的评估。

CallCenter：

订单系统

物流系统

媒体效能

协同办公

专业在线培训

2.2.2 应急服务平台

应急服务平台是针对中小企业应急业务、重大活动应急指挥等业务需求开发的一套基于SaaS模式的应急服务软件。

接处警应急指挥预案管理应急服务平台应急资源通用平台

危险源监管

应急评估救援力量应急演练专业培训

图 应急服务平台

接处警

应急指挥

预案管理

应急资源

2.2.3 通用后台

正邦通用后台是使用Spring框架开发的统一底层代码，即将公用的类和方法抽出来，并提供基础的接口，其他的类只需要实现该接口做具体的实现就可以。通过接口来定义了一套规范，增加了代码的复用性，底层将和数据库有关的操作封装成一个通用类，对数据的增、删、改、查都由该基类来完成，开发人员只需

要关心具体的业务逻辑，而不用关心具体的SQL语句。

通用后台功能需求如下：

1) 统一的数据库操作类，在该类主要是再一次封装Spring2.5自带的SimpleJdbcTemplate（注2），直接完成对对象的添加、修改、删除、查询等操作。

2) 完成统一的数据导出工具（Excel、PDF）

3) 完成统一的报表图表生成工具（OpenFlashChart）

4) 完成统一的后台管理（用户、部门、角色、权限、栏目等）

5) 完成系统换肤功能（能支持多种皮肤转换采用CSS+Cookie）

6) 完成功能代码生成器（针对数据表生成：POJO对象、接口、接口实现类、Action（Controller）、服务接口、服务接口实现类）

7) 完成统一的客户端验证脚本，需要在原来Validator框架上做一个升级，因为form:form元素是不支持自定属性。（具体的还需要做进一步的验证）

8) 统一的序列生成器，能脱离数据库的限制

9) 能支持各种数据库之前的切换(SqlServer、Oracle、DB2)

10) 统一的XML文件或Table配置，主要是配置每个页面的查询语句、不同数据库的对表操作的DML(注3)、需要导出的字段以及各字段的客户端验证方式（注4）。

11) 统一的XML数据操作类及统一在XML页面中配置各个层次的SQL及相关配置信息

12) 统一的资源文件处理操作类

13) 完成附加字段的维护信息，可以针对于某一种业务来添加附加信息

14) 完成简易聊天室

15) 完成简易的邮件管理系统

16) 完成简易短信管理系统

17) 完成简易查询条件生成器，用户可以自定义查询条件

18) 完成统一的附件上传、下载、管理系统

19) 完成主页内容自定义模块

20) 完成系统验证（系统有效期、有效账号）

21) 完成统一的地址管理（省、市、县）、区号、邮编。

22) 完成统一的输入联想功能，能通过输入特定的简码符号能显示相应符合的内容

注1：接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。

注2：SimpleJdbcTemplate Spring自己封装好的轻量级数据库访问类

注3：DML(Data Manipulation Language)数据操纵语言命令使用户能够查询数据库以及操作已有数据库中的数据。如insert,delete,update,select等都是DML。

注4：客户端验证方式是指在前端对系统各个输入项值的格式进行验证，比如非空、日期、邮件、手机号等等）

2.3 基本流程

一站式服务平台为企业提供服务的流程主要包括：软件注册，企业注册申请，企业开通，用户权限分配及开通，安全保障，数据存储，流量控制，并发处理，设备接入，计费，分流，灾难性恢复等。

以企业注册和开通为例，基本流程如下：

企业要使用平台服务，然而SaaS平台所提供的服务软件不只一个，因此应该知道他是需要使用哪个软件。

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

不同企业有不同要求，如企业1要求数据要独立存放，我们就应该为企业1开辟独立的数据库。企业2要求他的数据放在自己的数据服务器上，这时我们的数据服务器地址要指向企业2的数据服务器地址，所以SaaS平台的所有应用系统的数据连接都是动态的由平台来管理的。

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

经过审核合法，我们开通其申请，这时平台管理员分配给相应企业帐号及业务模块、就近原则分配应用服务器、数据库并建立企业管理员帐号及权限。

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

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

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

2.4 支撑环境

2.4.1 开发环境

1、MyEclipse6.0或以上版本

2、Jdk1.5或以上版本（建议使用JDK1.6）

3、Tomcat5.0或以上版本

4、Oracle10g或以上版本

2.4.2 系统运行环境

1、Tomcat5.0以上版本

2、IAS

3、WEBLOGIC

2.4.3 数据库环境

➢ Oracle10g或以上版本

2.5 局限性

说明所建议系统尚存在的局限性以及这些问题未能消除的原因。

2.6 技术可行性

本节应说明技术条件方面的可行性，如：

1) 在当前的限制条件下，该系统的功能目标能否达到；

2) 利用现有的技术，该系统的功能能否实现；

3) 对开发人员的数量和质量的要求并说明这些要求能否满足；

4) 在规定的期限内，本系统的开发能否完成。

3 总体设计

3.1 系统逻辑结构

1) 企业信息门户层：根据各个服务接入显示各企业相关门户信息。

2) 业务管理层： 负责业务应用服务管理，包括企业、部门、用户、用户角色、权限及字典等数据的管理。（企业可以管理自己的，平台管理员可以按企业来管理）

3) 系统平台服务层：负责系统资源、数据管理及平台所提供的服务，是系统的核心。

4) 业务应用层：平台所提供的业务应用模块。

5) 数据库层：数据存储及控制

6) 系统安全平台：负责系统的安全认证及身份认证。

7) Web Service服务：提供各个业务应用层的Web Service服务

3.2 技术架构

系统技术架构设计遵循业界领先的“云计算”理念，通过系统各种丰富组件的组合和复用，快速搭建出各种应用系统，为企业提供量身定做的解决方案。

短信手机电话传真机邮件WEB接入多渠道整合应用服务应用集成标准规范订单系统产品系统媒体系统物流系统客服系统SAAS服务平台SSO服务账套管理通用后台基础应用组件管理（部门、人员、角色、权限等）安全策略事件监控呼叫中心接口短信接口传真接口ERP接口数据监控数据备份电子商务接口邮件接口GIS接口CRM接口SAAS服务运营支撑平台工作流引擎报表引擎GIS引擎计费引擎界面流引擎中间件引擎数据挖掘引擎搜索引擎消息推送引擎基础框架数据存储引擎权限控制云计算开放平台服务架构高可用、高扩展、高可靠、高安全、高性能数据服务业务库订单数据呼叫数据媒体数据媒体数据销售数据集市集市客户数据集市供应商数据集市知识库客户数据产品数据数据仓库数据整合平台

 数据整合平台

通过SoA技术及ETL技术，高效整合来自CRM、ERP、电子商务、财务等系统的业务数据，保证系统的数据的一致性、完整性。系统以“客户忠诚度管理”、“多渠道整合营销”、“体验营销”为核心建模思想，为企业提供完整的数据视图。

 数据服务层

通过数据整合平台整合、转化的业务数据，以统一的数据视图导入客户库、

数据业务库、运营商业务库、ERP库等业务库，为各业务系统提供基础数据。

业务库的各种核心业务数据，通过ETL、数据挖掘、协同过滤等手段，导入数据仓库，为智能推荐、数据库营销、客户分群、市场营销活动等提供核心的数据。

各客户间SaaS服务业务数据及数据仓库数据通过虚拟化、分区等技术来完成在物理层面及逻辑层面的隔离，有效保证各客户数据的安全性。

 基础框架层

基础框架层为云计算服务提供基础的技术支撑。

云计算开放平台服务架构采用分布式架构设计，保证整个系统的高可用、高扩展、高可靠、高安全、高性能。同时云计算平台是一个开放式的服务平台，对外开放了平台的各种服务，聚合了众多的独立软件开发商、应用提供商、内容提供商、服务提供商等产业链的各种商家，有效保证了平台的生命力。

界面引擎、中间件引擎、规则引擎、工作流引擎、智能推荐引擎、ETL引擎等核心引擎来完成对各种技术实现的支撑，通过系统的组件化设计，保证了系统的可扩展性、可配置性、可管理性。

 应用服务层

应用服务层是核心服务所在，通过系统各种丰富组件的组合和复用，可以快速搭建出各种系统。同时通过开发平台架构，可以有效整合包括ERP、CRM、电子商务等合作伙伴的各种行业应用，为企业提供量身定做的解决方案。

 应用集成层

应用集成层在开放平台架构的基础上，整合了运营商、CP/SP、CRM、ERP、其他合作伙伴应用的接口，有力支撑运营商业务、增值业务等业务的拓展。

 SaaS服务平台层

SaaS服务平台层作为运营支撑平台，提供了SaaS服务平台的相关管理功能，有效保证SaaS服务平台的安全性、可靠性、可用性。

 多渠道整合

提供了对电话、手机客户端、IM、触摸屏、手机、传真、短信、Web、邮件等多种客户接入渠道的整合支持，拓展了与客户互动的方式，满足企业从地面到空中等多种通路的覆盖。

3.3 应用服务层设计

3.3.1 通用后台

通用后台的层次结构如图所示。

➢ WEB层（Jsp）

WEB层主要是用于做系统功能的展现。

➢ 控制层（Action）

用户控制业务逻辑

➢ 服务层（Service）

用户完成业务逻辑，并对数据库操作层进行再次封装

➢ 数据操作层（DAO）和SQL转换器

完成对数据库的操作，包括添加、修改、删除、查询等底层代码，其中SQL转换器的功能主要是用于将各数据库的SQL操作语句转换成标准SQL语句。

➢ 数据存储层

数据库：ORACLE、SQLSERVER、MYSQL等

3.3.2 面向领域的服务

3.3.2.1 CRM

3.3.2.2 应急服务

3.3.2.3 3D

3.4 SAAS服务层设计

3.5 接口设计

3.5.1 用户接口

说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。

3.5.2 外部接口

说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

3.5.3 内部接口

说明本系统之内的各个系统元素之间的接口的安排。

3.6 运行设计

3.6.1 运行模块组合

说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。

3.6.2 运行控制

说明每一种外界的运行控制的方式方法和操作步骤。

3.6.3 运行时间

说明每种运行模块组合将占用各种资源的时间。

3.7 数据库设计

3.7.1 逻辑结构设计要点

给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。

3.7.2 物理结构设计要点

给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。

3.7.3 数据结构与程序的关系

说明各个数据结构与访问这些数据结构的形式:

3.7.4 规范要求

➢ 数据表的命名主要是以T_业务名称，系统表统一命名规则为：t_sys_名称。如：订单表T_ORDER_INFO、系统用户表：T_SYS_USER

➢ 所有的主键序列名为ID VARCHAR2(50)

➢ 关于数据字段的说明需要写清楚

➢ 所有数据字典值字段需要统一数据类型和长度（VARCHAR2（10））

➢ 关于所有的状态值需要用’0’表示有效，’-1’表示无效

➢ 关于表的序列建立语句：create sequence seq_表名 start with 1。

➢ 关于日期字段的使用，创建时间需要设定默认值（sysdate），其它的日期时间如果后期需要做为查询条件但同时有可能会为空值则需要统一的设定默认时间为：to_date(‘2001-7-30‘,’yyyy-mm-dd’)，这样有利于后期的索引使用。

➢ 关于统一用SQL语句建的库时需要对数据表和索引进行收缩（如果不进行收缩会导致索引失效）。

➢ 关于数据表索引建立的必须条件是该数据字段必须在业务查询里面是必要的查询条件。索引的名称规则：ind_表名_字段

➢ 关于数据表和索引的存储表空间：数据表的存储为：zbht_data_序号，索引存储表空间为：zbht_index_序号。

➢ 关于函数的命名规则fn_函数名，存储过程的命名规则：pro_存储过程名。

➢ 关于函数和存储过程注释要求如下：

/**

创建人：

创建时间：

业务描述：

参数描述：

待办事：

*/

➢ 关于视图的命名规则：vw_视图名，关于物化视图命名规则为：mw_视图名。

➢ 关于数据库用户名统一名称为客户名简称+年份（如CEL国际：cel_2009），密码统一为：bj_zbht。

3.8 系统出错处理设计

3.8.1 出错信息

用一览表的方式说朗每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。

3.8.2 补救措施

说明故障出现后可能采取的变通措施，包括：

1) 后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就

是对于磁盘媒体的一种后备技术；

2) 降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；

3) 恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。

3.8.3 系统维护设计

说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系，可采用如下的矩阵图的形式；

4 安全性设计

4.1.1 安全架构

在SaaS模式下，安全设计是整个程序设计成败的关键，并且相比于传统的企业级开发，难度要大。因为如果安全上存在隐患，用户是不敢把如客户信息等关键数据放到SaaS供应商这儿来，并且这样一个对安全要求很高的系统是开放在互联网上，面临的安全上的威胁比局域网内的要大很多。总结起来，威胁主要来自以下3个方面：

(1)数据传输链路上的安全威胁。用户的浏览器通过互联网连接到远程服务器，数据上的交换极其容易被他人截获，甚至是在SaaS供应商内部，DMZ(demilitarized zone)与保护区域内的数据交换也存在被他人截获的隐患。

(2)业务逻辑上用户认证与授权的安全威胁。SaaS为多个的企业提供软件服务，因此存在不同企业间数据窃取的隐患，甚至在一个企业内部，也存在越权操作的安全隐患。

(3)数据储存上的安全威胁。成百上千的企业把关键数据存放在SaaS供应商这儿，极有可能造成数据丢失和数据被窃取的严重后果。

针对以上的安全隐患，本系统在数据传输，认证与授权和数据储存3个层面做安全上的设计。总架构如图2所示。

图2 安全设计架构

(1)数据传输安全设计。本系统采用SSL(secure socket layer)保护数据传输上安全。具体设计方案是在服务端生成密钥库和数字证书，当客户端通过HTTPS协议向服务端发送请求时，服务端向客户端发送数字证书和公钥，客户端通过已安装的公共CA证书验证服务器的可信度。客户端通过服务端发来的公钥把自己的私钥加密传输给服务端，服务端用自己的私钥解密得到客户端的私钥，在建立连接以后的数据传输中用这个对称的私钥进行加密保护。这样设计的目的在于在保证可信度和安全的前提下，尽量减轻安全因素对系统性能上的影响。在服务端内部，也是通过SSL来保护DMZ与非DMZ之间数据传输的安全性。

(2)认证与授权安全设计。对系统资源和业务流程的安全保障主要是通过对用户认证与授权来完成。为了提高系统整合程度和用户认证效率，本系统采用LDAP(lightweight directory access protocol)来统一管理用户认证信息。认证服务器是系统的前端拦截器，通过访问LDAP服务器，对客户端的访问进行认证，并把用户的认证信息和用户的实际请求向后方服务器传递。安全策略服务器会根据用户认证信息和对资源的请求向授权服务器提取相应的授权信息，对整个集群环境下Web层和应用服务层里的资源加以安全监管。

(3)数据存储安全设计。企业用户的数据在本系统中主要存储在数据库中，数据存储安全设计主要体现在以下3个方面：①数据库服务器与应用服务器相分离。通过加装防火墙等形式对数据库实施更进一步安全保障。②数据库服务器实现集群。在保证高可访问性和负载的同时，也保证了在数据遭到破坏的情况下，可通过备份信息来得以恢复。③在数据持久化层，实现对关键数据的加密存储。有些数据属于关键数据。比如客户名称，电话号码等，这些信息不能已明文的形式存放在数据库里，而应在存进数据库之前实施加密，提取数据时实施解密，这

样做的好处是，当有他人通过非法手段得到数据库的情况下，通过加密的方式使关键数据得以保护。本系统采用JCE(Java cryptographic extensions)来对关键数据实施加密和解密。

4.1.2 多企业数据隔离设计

多企业数据架构是多个企业数据共存，并共享同一应用系统的数据架构，这是SaaS软件开发与传统软件开发最大的不同点之一。在传统的CRM系统开发中，是对单个企业进行定制开发，所有数据专属于单个企业。而在SaaS模式下，所有应用模块和服务是为多个企业所用，每个企业都有属于自己的一套数据，那么在同一应用环境下，如何管理多套互相隔离的企业数据，如何保证数据安全和高可用性，是多企业数据架构要解决的核心问题。一般的设计方案分为完全隔离型，完全共享型和数据库共享Schema隔离型。

(1)完全隔离型，是指每个企业独享各自数据库，无论在逻辑还是物理上都把不同企业的数据隔离开来，并在应用程序里根据企业的标识动态加载数据库。这种方案的优点在于设计难度低，结构简单，数据易于管理。而缺点是在性能上容易造成系统扩展的瓶颈。

(2)完全共享型，是指所有企业数据共享于同一数据库，通过在每个表里添增企业标识来区分不同企业的数据。此方案的优点在于数据库的利用率很高，硬件成本较低。而缺点在于数据隔离性很低，多个企业数据混在同一表中，会有很大的安全隐患，也不容易对某个企业数据进行备份和恢复。另外，容易造成单表的数据量过大，性能上会有很大影响。

(3)数据库共享Schema隔离型，是指所有企业数据共享于同一数据库，但不同企业的数据通过不同的Schema相区分。此方案的优缺点折中于前两种方案，主要问题在于会造成单个数据库里的表过多，需要对数据库进行分区，实现难度较大。

综合以上3种方案的优缺点，本系统中采用的是较为综合的方案。具体上是集成使用共享型和隔离型方案，根据企业用户某些属性(如：企业等级，数据规模等)选择相应数据库类型，并在业务逻辑层和数据库之间增加持久化中间件来屏蔽这一过程。结构如图3所示。

图3 多企业数据隔离设计方案

通过对中间件的设计，一方面可以让业务逻辑层用统一的方式对待来自数据库的数据；另一方面可以使企业数据隔离方案更为灵活，比如可以对安全要求较低数据量不大的企业使用共享数据库方案，而对安全要求较高投入较大的企业使用独享数据库方案。中间件的主要设计思路是对每一次数据库连接进行动态加载，根据企业用户的标识动态生成相应的数据库连接，并且通过ORM(object

relational mapping)模式在持久化层里屏蔽数据存取细节。

5 实施步骤

项目总体目标是建立一套基于SaaS模式的客户关系管理平台，近期目标是实现基于多单位帐套管理的客户关系管理平台，在此基础上对外发布一些服务，以期实现基于SaaS模式的客户关系管理平台。项目可分三个阶段实现，如图所示：

基于SaaS模式的客户关系管理平台通用管理平台V2.0（多帐套）通用管理平台V1.0（单帐套）

1) 第一阶段目标：完成一套通用管理平台V1.0（单帐套），包括：部门、用户、角色、权限，以及系统功能和参数配置管理。搭建一套基于Spring 2.5的系统框架，此框架可用于公司将来的其它单帐套项目。

2) 第二阶段目标：完成通用管理平台V2.0（多帐套），在V1.0的基础上添加多帐套管理功能；将一些通用功能整合进来，包括：日程、消息、短信、邮件等管理功能。尽量采用一些开源的比较成型的功能代码，进行一些封装与改造，整合进我们的平台。此平台可用于公司将来的其它多帐套项目。

技术准备：为增加平台的灵活性，引进开源的工作流管理功能（例如：JBPM），为下一阶段的业务流程实现做准备。

3) 第三阶段目标：完成一套基于多单位帐套管理的客户关系管理平台，其中包括：产品管理、客户管理、联系人管理、销售管理、沟通管理、订单、工单跟踪管理等（有待进一步讨论）。

技术特点：业务流程可视化定制；客户、产品、订单等信息字段用户可定制；不同角色的门户可定制。