分布式服务框架（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