注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

无线时代辐射无穷

抓紧生宝宝,小心辐射

 
 
 

日志

 
 

基于Spring-DM实现分布式服务框架(DSF)(一)  

2011-02-18 23:41:13|  分类: osgi |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

http://www.bianceng.cn/Programming/project/201003/15594.htm

经过上篇分析分布式服务框架的blog后,正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写),因为已经决定基于Spring-DM来实现,为什么呢,而且为什么一定要是Spring-DM,而不直接说Spring呢?

今天是Spring-DM 1.0 release的大好日子,,不容易呀,做了这么久,具体怎么样还没来得及细看,不过之前有用过1.0 m2,已经觉得很不错了,相信1.0 release更不会失望。

在我眼里看来,Spring是个很大的东西,其实DSF需要的基础的东西并不多,但又希望保持微核性和扩展性,插件化、具备良好扩展支持的框架无疑是最佳的选择,OSGi无疑是个好的选择,但基于OSGi要自己去实现的东西实在是太多了,Spring-DM则是能满足我以上两点需求的最佳选择,既有了插件化的框架,又有了很多可用而且是很强大的东西,尤其是Spring在本地调用和远程调用的透明化提供了优秀的设计支持和指导,例如Spring提供的HessianServiceExporter、JNDIObjectFactoryBean等等,而且Spring和OSGi结合后,就可以根据需求来选择自己所需的Spring的那些增强功能了,不用每次都抱着整个巨大的Spring,当然,目前Spring还没完全剥离好,等Spring-DM 1.1后会好很多。

在之前的分析分布式服务框架的blog中,已经说到其实实现DSF简明扼要的说就是:高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力,其实这里面最重要的呢,又是强大的集成能力,为什么呢,因为呢,前两个关键点都是有挺多的可选方案的,需要根据系统运行的情况来做出不同的选择,这个时候就要求DSF具备很好的集成能力,使得可以很方便的进行不同实现方案的切换,这点Spring已经向世人证明了很多次了,鉴于这些原因Spring-DM荣幸的入选成为DSF的选择。 

来看看基于之前的那篇分析分布式服务框架的blog以及选择了Spring-DM后,DSF变成什么样了:


是不是觉得和之前的DSF的图有很多的不同的地方,至于为什么会变成这样,可以去看看分析分布式服务框架的blog,不在此细说,在此会详细的介绍下目前DSF第一个版本V 0.7,也就是上图中的每个部分:

先全局的说下,仍然是分为服务应用端和服务中心,但是从图中可以看出,服务查找和调用的机制和以前的有所不同,在DSF中服务仅把其元信息直接在服务中心进行注册,此元信息会由服务中心写入分布式的缓存DB:MemcacheDB中,当服务应用端进行服务调用时,它将直接访问MemcacheDB来查找到目标服务的访问机制,然后直接和目标服务应用端进行通讯,而不经过服务中心路由,这里要稍微说下为什么采用MemcacheDB,其实就是解决DSF中所说的高效的存储、查找机制,当然,里面其实还有个细节,就是cluster的考虑,可以想想,如果目标服务的元信息是直接缓存在服务应用端的话,那么当目标服务元信息发生改变时,那通知起来是件非常麻烦的事,所以干脆找个支持cluster持久和高效缓存的东西,还好有了MemcacheDB,当然,其实你也可以根据你所面对的应用的实际需求来定,例如,你的目标服务压根就不可能存在元信息变化的现象,那完全可以直接把目标服务的元信息缓存到服务应用端(甚至这步可以在部署期直接完成),这些等DSF做到后期版本后,可以考虑机制调整的支持,但在V 0.7中将会采用图示的方案。

经过机制的改变后,服务中心就变得非常简单了,而且压力是非常的小,它将来更多的需要承担服务的管理和监控的职责,逐步的会压力增大,这里就不去过多的讲它了,还是来看看服务应用端,其实也就是V 0.7需要干的活了:

1、服务查找

这个服务查找就是负责和MemcacheDB通讯的了,根据服务模型进行服务的过滤查找,只是要考虑以后切换为其他查找方式(如基于分布式文件系统、服务查找后本地缓存等)的支持,由于是基于Spring-DM的,不会有什么问题。

2、发布服务

参考Spring的ServiceExporter来实现,在V 0.7中,暂时只提供jndi的方式,jndi server采用jboss jnp,而以Hessian、Webservice的方式发布,都是Spring直接就支持的,:),只是当服务应用端不是采用Spring实现时,需要做个集成策略的实现。

3、调用服务

参考Spring的ObjectFactoryBean实现,由于V 0.7只有JNDI、Hessian方式,Spring已经分别提供了JNDIObjectFactoryBean和HessianProxyFactoryBean,所以这块暂时不用去考虑了。

在后续版本中这块需要在缓存等方面多加考虑。

4、和服务应用端的集成

在V 0.7中暂时假设服务应用端也是基于Spring的,所以就暂时不考虑集成的问题了。

OK,到此为止,剩下的两个工作就是:

1、服务元信息模型

服务元信息模型完全参考OSGi Service。

在V 0.7中将只支持xml方式描述服务元信息模型的注册,这里需要完成的就是将xml解析为元信息模型。

2、服务管理端

V 0.7仅提供服务列表的查看、服务注册、元信息修改以及卸载。

V 0.7需要做的就是把DSF的架子搭好,保证好基于DSF的Scable的可行性,当然,其实service本身也是要考虑Scable的(如service操作的资源等)才行,在后续0.7-->1.0的过程中将会从细节加以改进,如支持更多的通讯协议、支持更多种服务应用端的集成、提高性能等。

  评论这张
 
阅读(919)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017