2014浅谈云技术架构.docxVIP

浅谈CRM云技术架构公有云的出现无疑为众多的企业用户在应用选择方面打了一剂强心剂，大型企业可以通过公有云服务来省去自身的数据中心升级改造工作，而中小企业可以打消自身信息化成本的壁垒。作为公有云的代表，SaaS服务被众多的企业级用户所关注，但是，人们对于SaaS的疑问和顾虑制约了SaaS的发展。用户之所以产生顾虑，是因为目前SaaS并没有一个自身的标准，由于SaaS是一种在线的应用系统服务的提供，所以不同的应用会产生不同的标准。所以从某种意义上说，SaaS也很难产生一个通用的标准。没有标准并不等同于SaaS不能被用户接受。我们可以从某些常见的应用中以点带面，看一看SaaS服务应该具有什么样的标准。我们今天以企业用户常用的CRM系统，来看一看标准的SaaS CRM应该是一个什么样子。实际上，很多用户对于CRM并不陌生，早在2000年的时候，有一些企业就已经开始尝试CRM系统。在很多人眼中，CRM就是一套C/S或者B/S的应用系统。而当CRM进入了SaaS，他在架构上会是一个什么样子呢？我们以中科软科技股份有限公司新推出的361CRM为例，来看一下SaaS CRM的架构。361CRM 系统采用分布式架构。采用企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分主要为四层，根据调用关系依次为应用层、缓冲层、服务层以及存储层，如下图所示：应用层? 从浏览器发送过来的请求，直接由应用层来进行直接响应；? 平台是多租赁用户的在线多应用来实现的，由于每个用户的具体业务需求不同，因此每个租赁用户的应用是相互隔离的，但应用层的结构却都是相同，从上到下主要分为业务展现层、业务逻辑层、业务模型层、实体访问层；? 业务展现层主要为用户数据的不同视图表现，为用户呈现各种易于浏览、便于理解的各种数据表现方式，如表单、表格、报表、图表等；业务逻辑层主要是业务逻辑的具体实现层，对于用户动作、触发事件以及工作流程等由业务逻辑层来实现业务的处理以及响应，通过业务逻辑层对下层业务模型的访问来实现具体的逻辑处理；业务模型层主要是业务对象的具体定义与封装，是对于现实中业务在平台中的最直接的映射；实体访问层是对于业务逻辑层对于业务模型操作的封装，业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。缓冲层缓冲层主要对于静态资源以及动态数据的缓存。静态资源主要是指应用层中展现层中所要使用到的静态资源文件，以及由用户在业务操作中产生的文件等，如图片、上传的文件等；而动态数据是指用户在使用平台的过程中所产生的业务数据，在实现业务中，这部分数据大部分都是读操作比较多，而写操作比较少，因此可以针对这部分数据根据特定的缓存失效策略机制来进行相应的缓存；缓冲层的缓存针对应用层是透明的，而且针对多应用也是透明的，因此缓冲层具有更大的弹性与灵活性。服务层服务主要是指平台的核心服务，核心服务分为业务共通服务以及平台共通服务，平台共通服务是指与业务无关且是平台最基础的服务，如任务调度、消息队列、邮件服务、图片处理、工作流引擎等；而业务共通服务指基于平台共通服务，而对于所有业务具有共通性的服务，如日志审核、操作回滚、数据安全、全文检索、权限角色等；服务层是对于平台运营、维护最核心的服务实现，是平台正常运行的基础。存储层存储主要分为两部分：分布式文件存储以及分布式的数据存储；由于是多应用的平台，因此随着平台的运营，会产生海量的业务数据以及资源文件，因此伴随着海量的数据而来的问题就是存储、检索、分析以及统计等问题；针对上述问题，361CRM平台采用了分布式的存储系统，基于Map-Reduce来进行相应的检索、分析以及统计，实现了对于海量数据的统一操作。这种结构能做到真正的分布式网络计算，有效降低网络流量，减轻客户端负担，还能安全、方便地与互联网接口。另外公司员工或客户分布或行走于全国各地，通常都有移动办公需求。REST 架构REST是基于HTTP的，因此天生就有在互联网上穿透防火墙的能力，REST可以简单地认为它是轻量级的Web Service，但是它具有自己的一些显著特点：所有的资源通过统一的接口访问(HTTP/HTTPS GET、POST、PUT、ELETE)，而且接口比较统一，便于与第三方的集成；因为是基于HTTP/HTTPS的，因此可以将资源（响应）分为可缓存的和不可缓存的，以及采用浏览器的标准压缩方式，有效地提升网络效能。也可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等；因为是基于HTTP/HTTPS的资源请求，因此本次连接和下一次到服务器的连接之间没有状态。由于361CRM平台采用了REST架构，因此也就决定了361CRM平台天然就具备以下几方面的优势：由于REST本身无状态的特性，361CRM平台天然就