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)的自定义开发,实现了企业用户应用的透明隔离,因此平台具有面向不同企业用户根据不同需求进行个性化定制的能力。不同的企业用户,一般主要有几方面的自定义需求:业务对象、工作流程、报表、布局等,而CRM平台的平台框架就决定着能够很好地满足用户的自定义需求,主要分为以下几个方面:
由于用户使用的是文档数据库,有着松散的数据结构,因此用户根据需求,而可以随意自定义自己的业务对象;CRM平台后台的平台服务层,有相应的实时的工作流引擎,提供给用户强大的自定义工作流程功能;CRM平台有业内是丰富的报表模板,用户只需要根据自己的需要来选择即可,针对一些自定义的动态数据,还提供模板的再定义功能,能够很好地满足用户的报表需求;由于平台是应用隔离的,因此针对着页面的布局,可以很容易地实现个性化地定制;CRM平台的配置功能的强大,并不以损失平台应用的易用性为基础,CRM平台在操作上采用引导式操作,以及提供方便易用的在线帮助,大大地降低了系统使用的复杂度,使系统更加地人性化、简易化。
实时即时
361CRM平台的平台服务层与通常的应用服务不同,它是实时运行的服务,平台服务层有相应的任务调度机制,邮件服务、消息队列以及实时的工作流引擎等,这些服务都是实时运行的,因此当企业用户的业务对象或者业务流程发生变化时,通过这些平台服务就可以把即时的状态消息(通过邮件、短信或者其它的IM工具)推送给用户,让用户真正了解到业务的即时与实时的状态信息。
而通常的应用服务是静态的,只有当用户登录时,才会进行相应的业务状态的检查,这样就严重影响了业务处理的速度,对于即时性业务,就会带来很大的损失。
多级负载
平台是一个多租赁用户的在线SaaS系统,因此会给平台带来大量的高并发的请求,361CRM平台是一个多层次的结构,而且采用了REST架构,REST天生就是分布式,因此通过物理部署就可以实现高并发带的负载均衡。
四层负载在链路层解决来自互联网的并发请求压力,使用LVS+Heartbeat的主从双备的架构,保证不会出现单点故障;Web应用的大部分压力都来自于资源的请求,如图片,静态文件,样式表等文件的请求,服务器压力的70%都来自于这些资源的请求,因此对于这些静态资源的请求,通过静态资源缓冲层就能够很好解决这些请求对于后台造成的压力;经过实测,经过一段时间稳定运行之后,静态资源缓冲层能够命中前台请求的80%以上,有效地缓解了应用服务器的压力;七层负载层主要是做业务、以及资源的请求分流,把负载均衡到多台文件服务器以及应用服务器上;文件服务器与应用服务器是分布式的,通过Map-Reduce进行任务的拆分与结果的合并,充分利用多台服务器的并行计算能力,提升整体平台的运行性能;文件缓存采用多级缓存策略,解决命中率高的文件的频繁请求。而数据缓存则通过业务标签以及时效性策略进行数据的缓存,并且进行缓存的增量更新,有效地解决了对于后台的数据读写压力;分布式的存储系统有效地解决了海量数据的存储、检索、分析以及统计等问题。
可见,当传统的CRM系统转换为SaaS服务后,其架构方面还是发生了不少的变动的,也只有这样的变动,才使得CRM能够在SaaS平台上更好的为客户所服务。
责编:Rosaww
微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友