分布式服务框架(dubbo)

前些日子,他妈的实在闲的慌,于是跑去质问老总,还让不让人干了。

老总有些错愕,投来惊异带着些赞许的目光,随后扔给我一本书 收获不止Oracle,很新,我至今舍不得翻开(不过后面还是不得不花了一个星期把他KO了。),同时让我自己去研究dubbo这个我第一次听说的所谓的分布式服务框架,不喜欢也不讨厌,所以就看了起来,就当积累吧。。。

首先,按照我的理解,介绍下dubbo,其实也没什么太深的家世,阿狸的一个开放框架,解决访问量大造成系统崩溃或者性能下降的问题。

dubbo的结构成员,注册中心registry,服务提供者provider,消费者consumer,监听monitor

provider:暴露服务提供方提供的服务。

consumer:调用远程服务的消费者。

registry:提供服务注册和服务发现的注册中心,他妈的就一个拉皮条的。

monitor:监听中心,负责搜集一些调用时间和次数信息。

申明下,dubbo框架和spring框架是可以无缝结合的,所以我们下面可以随心所欲的再spring下的配置文件中配置各种需要的信息。

这里说说健壮性,因为看了材料对健壮性还是看懂 了的,其他的都他妈的太深奥,有兴趣的自己去看。

何为健壮性,说白了就是不容易一次性死掉。以上的四个成员组合起来为我们提供服务,除非所有的服务提供者都宕掉,否则还是能继续为消费者提供服务。

下面说下怎么使用:

首先是配置,其实一直都是在配置上。

关于服务器端的配置,提供者需要在注册中心注册所提供的服务,并且暴露提供服务的接口。

-consult.xml中配置

服务提供者的应用名:

< dubbo:application name = "comvee-consult"   />

暴露服务中的注册地址:

< dubbo:registry address = "zookeeper://127.0.0.1:2181" />

暴露服务的端口号:

< dubbo:protocol name = "dubbo" port = "8075" />

暴露服务的接口:

<dubbo:service interface=”com.comvee.question.service.QuestionServiceI” 
ref=”questionService” actives=”100″ timeout=”20000″ retries=”0″/>

<dubbo:service interface=”com.comvee.member.service.MemberServiceI” 
ref=”memberService” actives=”100″ timeout=”20000″ retries=”0″/>

以上是服务端的dubbo文件配置,客户端也需要配置相应的信息来获取需要的服务。

<dubbo:application name=”consult-consumer”/> 
<dubbo:registry address=”zookeeper://127.0.0.1:2181″></dubbo:registry> 
<dubbo:monitor protocol=”registry”/>

<dubbo:reference id=”questionService” timeout=”20000″ retries=”0″ 
interface=”com.comvee.question.service.QuestionServiceI”/> 
<dubbo:reference id=”memberService” timeout=”20000″ retries=”0″ 
interface=”com.comvee.member.service.MemberServiceI” /> 
<context:component-scan base-package=”com.comvee.base,com.comvee.question.controller,com.comvee.member.controller,com.comvee.common” />

看到了没配置就他妈的这么简单明了,不用再说了吧,需要强调的是配置信息分别在服务端和客户端的.xml文件中配置,也可以在spring的XML文件中直接配置信息,只要你不觉得乱。

当然如果测试的话我们还需要一个注册中心,zookeeper,每个服务器上都必须先启动这个zookeeper后注册中心才开始工作。

测试的话可以再本地测试,像上面的例子,<dubbo:registry address=”zookeeper://127.0.0.1:2181″></dubbo:registry> 注册中心的地址就是本地的地址,实际上不能这么随便配置的。

扩展下,服务端和客户端可以无限制的增加,否则分布式没有任何意义了,只有在不断地加压下才能展现dubbo的真正魅力,这点自己体会。

总结下dubbo的工作原理:可以想象一下,我们去相亲。首先是男方(类似消费者)向婚介中心提出一个请求,说我要相亲,相亲的条件报上,暴露需要的请求,有的话给我安排一个。婚介中心就像一个注册中心,他们接到这个请求后立马记录下来。同时如果有女方向婚介所提出,我要被相亲,也提出相应的条件,相当于提供方暴露一个服务给注册中心,婚介中心也做相应的记录。好,现在开始工作了,当婚介中心工作的时候,也就是启动了zookeeper,他们会自动发现,有哪些女方(服务提供者),有哪些男方(服务消费者),然后通过条件匹配他们相亲。服务就是这样完成了。至于监听的部分暂时可以不用去管他。

OK,dubbo我的理解暂时就到这里了,有兴趣的可以一起讨论,其实我也没真正试过这个框架有多牛逼,只是做了几个小小的测试,以后用不用的到都是扯淡,暂时先积累着。。。

关键词:dubbo分布式

http://www.tuicool.com/articles/FRbMVj

相关推荐