浅谈CRM云技术架构.docx
《浅谈CRM云技术架构.docx》由会员分享，可在线阅读，更多相关《浅谈CRM云技术架构.docx（8页珍藏版）》请在冰豆网上搜索。
浅谈CRM云技术架构
浅谈CRM云技术架构
公有云的显现无疑为众多的企业用户在应用选择方面打了一剂强心剂，大型企业能够通过公有云效劳来省去自身的数据中心升级改造工作，而中小企业能够打消自身信息化本钱的壁垒。
作为公有云的代表，SaaS效劳被众多的企业级用户所关注，可是，人们关于SaaS的疑问和顾虑制约了SaaS的进展。
用户之因此产生顾虑，是因为目前SaaS并无一个自身的标准，由于SaaS是一种在线的应用系统效劳的提供，因此不同的应用会产生不同的标准。
因此从某种意义上说，SaaS也很难产生一个通用的标准。
没有标准并非等同于SaaS不能被用户同意。
咱们能够从某些常见的应用中以点带面，看一看SaaS效劳应该具有什么样的标准。
咱们今天以企业用户经常使用的CRM系统，来看一看标准的SaaSCRM应该是一个什么样子。
事实上，很多用户关于CRM并非陌生，早在2000年的时候，有一些企业就已经开始尝试CRM系统。
在很多人眼中，CRM确实是一套C/S或B/S的应用系统。
而当CRM进入了SaaS，他在架构上会是一个什么样子呢？
咱们以中科软科技股分新推出的361CRM为例，来看一下SaaSCRM的架构。
361CRM系统采纳散布式架构。
采纳企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分要紧为四层，依照挪用关系依次为应用层、缓冲层、效劳层和存储层，如以下图所示：
应用层
从阅读器发送过来的请求，直接由应用层来进行直接响应；
平台是多租赁用户的在线多应用来实现的，由于每一个用户的具体业务需求不同，因此每一个租赁用户的应用是彼此隔离的，但应用层的结构却都是相同，从上到下要紧分为业务展现层、业务逻辑层、业务模型层、实体访问层；
业务展现层要紧为用户数据的不同视图表现，为用户呈现各类易于阅读、便于明白得的各类数据表现方式，如表单、表格、报表、图表等；
业务逻辑层主若是业务逻辑的具体实现层，关于用户动作、触发事件和工作流程等由业务逻辑层来实现业务的处置和响应，通过业务逻辑层对基层业务模型的访问来实现具体的逻辑处置；
业务模型层主若是业务对象的具体概念与封装，是关于现实中业务在平台中的最直接的映射；
实体访问层是关于业务逻辑层关于业务模型操作的封装，业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。
缓冲层
缓冲层要紧关于静态资源和动态数据的缓存。
静态资源主若是指应用层中展现层中所要利用到的静态资源文件，和由用户在业务操作中产生的文件等，如图片、上传的文件等；
而动态数据是指用户在利用平台的进程中所产生的业务数据，在实现业务中，这部份数据大部份都是读操作比较多，而写操作比较少，因此能够针对这部份数据依照特定的缓存失效策略机制来进行相应的缓存；
缓冲层的缓存针对应用层是透明的，而且针对多应用也是透明的，因此缓冲层具有更大的弹性与灵活性。
效劳层
效劳主若是指平台的核心效劳，核心效劳分为业务共通效劳和平台共通效劳，平台共通效劳是指与业务无关且是平台最基础的效劳，如任务调度、消息队列、邮件效劳、图片处
理、工作流引擎等；而业务共通效劳指基于平台共通效劳，而关于所有业务具有共通性的效劳，如日记审核、操作回滚、数据平安、全文检索、权限角色等；
效劳层是关于平台运营、保护最核心的效劳实现，是平台正常运行的基础。
存储层
存储要紧分为两部份：
散布式文件存储和散布式的数据存储；
由于是多应用的平台，因此随着平台的运营，会产生海量的业务数据和资源文件，因此伴随着海量的数据而来的问题确实是存储、检索、分析和统计等问题；
针对上述问题，361CRM平台采纳了散布式的存储系统，基于Map-Reduce来进行相应的检索、分析和统计，实现了关于海量数据的统一操作。
这种结构能做到真正的散布式网络计算，有效降低网络流量，减轻客户端负担，还能平安、方便地与互联网接口。
另外公司员工或客户散布或行走于全国各地，通常都有移动办公需求。
REST架构
REST是基于HTTP的，因此天生就有在互联网上穿透防火墙的能力，REST能够简单地以为它是轻量级的WebService，可是它具有自己的一些显著特点：
所有的资源通过统一的接口访问（HTTP/HTTPSGET、POST、PUT、ELETE），而且接口比较统一，便于与第三方的集成；
因为是基于HTTP/HTTPS的，因此能够将资源（响应）分为可缓存的和不可缓存的，和采纳阅读器的标准紧缩方式，有效地提升网络效能。
也能够在客户和资源之间插入不同的中间组件来提升性能和平安等，如，代理效劳，缓存效劳，网关效劳等；
因为是基于HTTP/HTTPS的资源请求，因此本次连接和下一次到效劳器的连接之间没有状态。
由于361CRM平台采纳了REST架构，因此也就决定了361CRM平台天然就具有以下几方面的优势：
由于REST本身无状态的特性，361CRM平台天然确实是散布式的，决定了后台通过依照业务量而弹性地增加效劳器就能够够实现平台计算能力的线性增加；
所有的请求都是统一通过RESTAPI进行相应的资源与效劳的请求，如此就能够够保证系统提供的效劳都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性，同时也能够依照业务进行相应统一且透明的内存缓存
客户端阅读器能够轻松通过Ajax实现REST资源的异步伐用途理，同时也能够有效地减少应用效劳器地压力
通过提供开放的RESTAPI，能够轻松实现与第三方的集成
平台效劳
平台效劳层的挪用是通过RESTAPI进行的，由于REST的特点，通过在URI中添加资源途径和版本信息，很方便地能够实现平台的滑腻升级和数据兼容性问题。
平台效劳层实现的都是共通的效劳，效劳之间是独立的，而且是插件式的方式来实现的，平台选用了面向散布式计算的Erlang语言来实现的，因此保证了这些插件式的效劳能够热拔插地部署，实现真正地不宕机地部署与更新。
平台效劳层的插件式架构，决定了平台的无穷扩展能力，能够依照不断转变地用户需求而进行平台的不断地在线迭代与更新，与用户的需求形成一个良性的循环。
配置定制平台通过效劳器（Apache）的自概念开发，实现了企业用户应用的透明隔离，因此平台具有面向不同企业用户依照不同需求进行个性化定制的能力。
不同的企业用户，一样要紧有几方面的自概念需求：
业务对象、工作流程、报表、布局等，而361CRM平台的平台框架就决定着能够专门好地知足用户的自概念需求，要紧分为以下几个方面：
由于用户利用的是文档数据库，有着松散的数据结构，因此用户依照需求，而能够随意自概念自己的业务对象；
361CRM平台后台的平台效劳层，有相应的实时的工作流引擎，提供给用户壮大的自定义工作流程功能；
361CRM平台有业内是丰硕的报表模板，用户只需要依照自己的需要来选择即可，针对一些自概念的动态数据，还提供模板的再概念功能，能够专门好地知足用户的报表需求；
由于平台是应用隔离的，因此针对着页面的布局，能够很容易地实现个性化地定制；
361CRM平台的配置功能的壮大，并非以损失平台应用的易用性为基础，361CRM平台在操作上采纳引导式操作，和提供方便易用的在线帮忙，大大地降低了系统利用的复杂度，使系统加倍地人性化、简易化。
实时即时
361CRM平台的平台效劳层与通常的应用效劳不同，它是实时运行的效劳，平台效劳层有相应的任务调度机制，邮件效劳、消息队列和实时的工作流引擎等，这些效劳都是实时运行的，因此当企业用户的业务对象或业务流程发生转变时，通过这些平台效劳就能够够把即时的状态消息（通过邮件、短信或其它的IM工具）推送给用户，让用户真正了解到业务的即时与实时的状态信息。
而通常的应用效劳是静态的，只有当用户登录时，才会进行相应的业务状态的检查，如此就严峻阻碍了业务处置的速度，关于即时性业务，就会带来专门大的损失。
多级负载
平台是一个多租赁用户的在线SaaS系统，因此会给平台带来大量的高并发的请求，361CRM平台是一个多层次的结构，而且采纳了REST架构，REST天生确实是散布式，因此通过物理部署就能够够实现高并发带的负载均衡。
四层负载在链路层解决来自互联网的并发请求压力，利用LVS+Heartbeat的主从双备的架构，保证可不能显现单点故障；
Web应用的大部份压力都来自于资源的请求，如图片，静态文件，样式表等文件的请求，效劳器压力的70%都来自于这些资源的请求，因此关于这些静态资源的请求，通过静态资源缓冲层就能够够专门好解决这些请求关于后台造成的压力；
通过实测，通过一段时刻稳固运行以后，静态资源缓冲层能够命中前台请求的80%以上，有效地减缓了应用效劳器的压力；
七层负载层主若是做业务、和资源的请求分流，把负载均衡到多台文件效劳器和应用效劳器上；
文件效劳器与应用效劳器是散布式的，通过Map-Reduce进行任务的拆分与结果的归并，充分利用多台效劳器的并行计算能力，提升整体平台的运行性能；
文件缓存采纳多级缓存策略，解决命中率高的文件的频繁请求。
而数据缓存那么通过业务标签和时效性策略进行数据的缓存，而且进行缓存的增量更新，有效地解决了关于后台的
数据读写压力；
散布式的存储系统有效地解决了海量数据的存储、检索、分析和统计等问题。
可见，当传统的CRM系统转换为SaaS效劳后，其架构方面仍是发生了很多的变更的，也只有如此的变更，才使得CRM能够在SaaS平台上更好的为客户所效劳。
附：
什么是REST架构
REST软件架构是现今世界上最成功的互联网的超媒体散布式系统。
它让人们真正明白得咱们的网络协议HTTP本来面貌。
它正在成为网络效劳的主流技术，同时也正在改变互联网的网络软件开发的全新思维方式。
AJAX技术和Rails框架把REST软件架构思想真正地在实际中专门好表现出来。
今天微软也已经应用REST而且提出把咱们现有的网络变成为一个语义网，这种网络将会使得搜索加倍智能化。
REST与HTTP协议
REST软件架构是由RoyThomasFielding博士在2000年第一次提出的。
他为咱们刻画了开发基于互联网的网络软件的蓝图。
REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体散布式系统的行动指南。
利用任何的技术都能够实现这种理念。
而实现这一软件架构最闻名的确实是HTTP协议。
通常咱们把REST也写作为REST/HTTP，在实际中往往把REST明白得为基于HTTP的REST软件架构，或更进一步把REST和HTTP看做为等同的概念。
今天，HTTP是互联网上应用最普遍的运算机协议。
HTTP不是一个简单的运载数据的协议，而是一个具有丰硕内涵的网络软件的协议。
它不单单能够关于互联网资源进行唯必然位，而且还能告知咱们关于该资源进行如何运作。
这也是REST软件架构当中最重要的两个理念。
而REST软件架构理念是真正明白得HTTP协议而形成的。
有了REST软件架构理念显现，才使得软件业幸免了对HTTP协议的片面明白得。
只有正确的理论指导，才能幸免在软件开发的实际工作进程中少走弯路。
REST与URI（资源定位）
REST软件架构之因此是一个超媒体系统，是因为它能够把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word仍是视频文件，也不管你的文件是txt文件格式、xml文件格式仍是其它文本文件格式。
它利用支持HTTP的TCP/IP协议来确信互联网上的资源。
REST与CRUD原那么
REST软件架构遵循了CRUD原那么，该原那么告知咱们关于资源（包括网络资源）只需要四种行为：
创建（Create）、获取（Read）、更新（Update）和销毁（DELETE）就能够够完成对其操作和处置了。
其实世界万物都是遵循这一规律：
生、变、见、灭。
因此运算机世界也不例外。
那个原那么是源自于咱们关于数据库表的数据操作：
insert（生）、select（见）、update（变）和delete（灭），因此有时候CRUD也写作为RUDI，其中的I确实是insert。
这四个操作是一种原子操作，即一种无法再分的操作，通过它们能够构造复杂的操作进程，正如数学上四那么运算是数字的最大体的运算一样。
REST与网络效劳
尽管在Java语言世界中网络效劳目前是以SOAP技术为主，可是REST将是是网络效劳的另一选择，而且是真正意义上的网络效劳。
基于REST思想的网络效劳不久的以后也会成为是网络效劳的主流技术。
REST不单单把HTTP作为自己的数据运输协议，而且也作为直接进行数据处置的工具。
而当前的网络效劳技术都需要利用其它手腕来完成数据处置工作，它们完全独立于HTTP协议来进行的，如此增加了大量的复杂软件架构设计工作。
REST的思想充分利用了现有的HTTP技术的网络能力。
在德国电视台上曾经显现过一个如此的五十万欧元智力题：
如何实现网络效劳才能充分利用现有的HTTP协议？
该问题给出了四个答案：
去问微软；；WS-Transfer；全然没有。
那个问题告知咱们HTTP并非是一个简单的数据传来传去的协议，而是一个伶俐的会表现自己的协议，这或许是REST=RepresentationalStateTransfer的真正含义。
事实上目前很多大公司已经采纳了REST技术作为网络效劳，如Google、Amazon等。
在Java语言中重要的两个以SOAP技术开始的网络效劳框架XFire和Axis也把REST作为自己的另一种选择。
它们的新的项目别离是ApacheCXF和Axis2。
Java语言也制定关于REST网络效劳标准：
JAX-RS:
JavaAPIforRESTfulWebServices（JSR311）。
相信还会显现更多与REST相关的兴奋人心的信息。
REST与AJAX技术
尽管AJAX技术的显现才不到两年时刻，可是AJAX技术遵循了REST的一些重要原那么。
AJAX技术充分利用了HTTP来获取网络资源而且实现了HTTP没有的关于异步数据进行传输的功能。
AJAX技术还使得软件更好地实现散布性功能，在一个企业内只要一个人下载了AJAX引擎，其它企业内部的人员，就能够够共享该资源了。
AJAX技术遵守REST准那么的应用程序中简单和可伸缩的架构，凡是采纳AJAX技术的页面简练而又丰硕，一个页面表现了丰硕多彩的形态。
AJAX技术还利用了一种不同于XML格式的JSON文件格式，那个意义在哪里呢？
在REST软件架构下咱们不能关于XML文件进行序列化处置，如此程序员必需要利用自己的XML绑定框架。
而以序列化的JavaScript对象为基础的JSON已经取得了普遍认可，它被以为能以远比XML更好的方式来序列化和传输简单数据结构，而且它更简练。
这对REST是一个极大奉献和补充。
当前的网络应用软件还违抗了REST的“无状态效劳器”约束。
REST效劳器只明白自己的状态。
REST不关切客户端的状态，客户端的状态自己来治理，这是AJAX技术的应用之地。
通过AJAX技术，能够发挥有状态网络客户机的优势。
而REST的效劳器关切的是从所有网络客户端发送到效劳器操作的顺序。
如此使得互联网如此一个庞大的网络取得有序的治理。
REST与Rails框架
RubyonRails框架（简称Rails或Rails框架）是一个基于Ruby语言的愈来愈流行的网络应用软件开发框架。
它提供了关于REST最好的支持，也是现今应用REST最成功的一个软件开发框架。
Rails框架（从版本起）成了第一个引入REST作为核心思想的主流网络软件开发框架。
在Rails框架的充分利用了REST软件架构以后，人们加倍坚信REST的重要性和必要性。
Rails利用REST软件架构思想对网络效劳也提供了一流的支持。
从最直观的角度看待REST，它是网络效劳最理想的手腕，可是Rails框架把REST带到了网络应用软件开发框架。
这是一次飞跃，让REST的思想从网络效劳的应用提升到了网络应用软件开发。
利用REST思想的simply_restful插件已经成了Rails框架的核心内容。
REST平安性
咱们把现有基于SOAP的网络效劳和基于REST/HTTP网络效劳作个比喻，前者是一种传统的寄信方式，而后者是现代网络的电子邮件方式。
若是是寄信和电子邮件都有病毒存在的话，传统的寄信被送到对方就很危险，而电子邮件是开发的，电子邮件供给商比如Google为咱们检查了电子邮件是不是有病毒。
那个地址并非是说明SOAP网络效劳消息包括义病毒，而是说明HTTP是无法处置SOAP信息包究竟好不行，需要额外的软件工具解决这一问题，包括防火墙也用不上和管不了。
REST/HTTP网络效劳的信息包能够被防火墙明白得和操纵。
你能够依照操作和链接进行过滤信息包，如你能够规定从外部来的只能读取（GET操作）自己效劳器的资源。
如此关于系统治理员而言使得软件治理更为简单。
REST的平安性还能够利用传输平安协议SSL/TLS、大体和摘要式认证（BasicundDigestAuthentication）。
除这些REST自身的平安性功能外，还能够利用像基于信息的WebServicesSecurity（JSR155）作为REST不错的补充。
升级会员 