Dubbo阿里Alibaba开源的分布式服务框架

Dubbo是什么？
Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。


其核心部分包含:
远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo能做什么？
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo总架构：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
从上图可以看出，Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的）。

服务定义
服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务。


服务注册
对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。
通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。Dubbo提供的注册中心有如下几种类型可供选择：
Multicast注册中心
Zookeeper注册中心
Redis注册中心
Simple注册中心

Dubbo服务调用
下面从Dubbo官网直接拿来，看一下基于RPC层，服务提供方和服务消费方之间的调用关系，如图所示：


上图中，蓝色的表示与业务有交互，绿色的表示只对Dubbo内部交互。上述图所描述的调用流程如下：
1.服务提供方发布服务到服务注册中心；
2.服务消费方从服务注册中心订阅服务；
3.服务消费方调用已经注册的可用服务

Zookeeper注册中心安装

建议使用dubbo-2.3.3以上版本的zookeeper注册中心客户端。
Zookeeper是Apache Hadoop的子项目，强度相对较好，建议生产环境使用该注册中心。
Dubbo未对Zookeeper服务器端做任何侵入修改，只需安装原生的Zookeeper服务器即可，
所有注册中心逻辑适配都在调用Zookeeper客户端时完成。


第一步安装配置Zookeeper
准备安装包网址
下载Zookeeper-3.4.6.tar.gz  地址http://www.apache.org/dist/zookeeper/
zookeeper-3.4.6.tar  zookeeper安装包




安装步骤：
创建文件夹 mkdir /usr/local/zookeeper
解压： tar zxvf zookeeper-3.4.6.tar.gz -C /usr/local/zookeeper/
授权：chmod 777 /usr/local/zookeeper/
如图1：



配置
然后在对应的zookeeper-3.4.6/conf 下有一个文件zoo_sample.cfg的这个文件里面配置了监听客户端连接的端口等一些信息，Zookeeper 在启动时会找zoo.cfg这个文件作为默认配置文件,所以我们复制一个名称为zoo.cfg的文件，
如图2所示：





我们查看一下这个文件的里面的一些配置信息，如图3所示：

zoo.cfg配 置文件说明：
 clientPort：监听客户端连接的端口。
 tickTime：基本事件单元，以毫秒为单位。它用来控制心跳和超时，默认情况下最小的会话超时时间为两倍的 tickTime。
 我们可以对配置文件的端口等或者进行高级配置和集群配置例如：maxClientCnxns：限制连接到 ZooKeeper 的客户端的数量等。

启动Zookeeper 的服务，如图4所示：


到此Zookeeper的安装和配置完成。




 第二步：配置dubbo-admin的管理页面，方便我们管理页面
配置dubbo-admin的管理页面之前先安装tomcat请参考http://blog.csdn.net/xingkong22star/article/details/44806887
    (1)下载dubbo-admin-2.5.3.war包，在Linux的tomcat部署，先把dubbo-admin-2.5.3放在tomcat的webapps/ROOT下，然后进行解压解压完成后删除war包：
        cd webapps/ROOT/
jar -xvf dubbo-admin-2.5.3.war
rm dubbo-admin-2.5.3.war 
rm：是否删除普通文件 "dubbo-admin-2.5.3.war"？y

图5所示：

    (2)然后到webapps/ROOT/WEB-INF下，有一个dubbo.properties文件，里面指向Zookeeper ，使用的是Zookeeper 的注册中心，如图6所示：


    (3)然后启动tomcat服务，用户名和密码：root,并访问服务，显示登陆页面，说明dubbo-admin部署成功，
[root@localhost /]#  /usr/local/zookeeper/zookeeper-3.4.6/bin/zkServer.sh start
JMX enabled by default
Using config: /usr/local/zookeeper/zookeeper-3.4.6/bin/../conf/zoo.cfg
Starting zookeeper ... already running as process 2407.
[root@localhost /]# /usr/local/tomcat/apache-tomcat-7.0.62/bin/startup.sh start
Using CATALINA_BASE:   /usr/local/tomcat/apache-tomcat-7.0.62
Using CATALINA_HOME:   /usr/local/tomcat/apache-tomcat-7.0.62
Using CATALINA_TMPDIR: /usr/local/tomcat/apache-tomcat-7.0.62/temp
Using JRE_HOME:        /usr/local/jdk/jdk1.7.0_79/jre
Using CLASSPATH:       /usr/local/tomcat/apache-tomcat-7.0.62/bin/bootstrap.jar:/usr/local/tomcat/apache-tomcat-7.0.62/bin/tomcat-juli.jar
Tomcat started.
进入浏览器输入127.0.0.1:8080后会出现如图7所示： 


登陆完成如图8所示： 



如果出现如下错误如图9：

原因是因为解压dubbo后忘记删除war包了






注册中心抽象
Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
Dubbo抽象后，用户可以进行扩展，我们通过分析ZooKeeper这个实现来了解注册中心的低层。
进过抽象之后，用户 只需要实现对应的Registry和RegistryFactory就可以了，ZooKeeper就是实现了ZookeeperRegistry，和ZookeeperRegistryFactory。
ZookeeperRegistryFactory的实现很简单，就是返回一个ZookeeperRegistry实例，所以主要的东西是在ZookeeperRegistry中实现的，在ZookeeperRegistry用户需要实现注册URL，
注销URL，URL订阅，URL注销订阅和URL查询，在这里面设计到Zookeeper服务端的调用，都被封装到ZookeeperClient中，ZookeeperClient服务进行Server连接，断链；资源的CRUD。


ZooKeeper的价值
由于引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。
首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；
资源同步，单单有负载均衡还不够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；
命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。
其他特性还有Mast选举，分布式锁等。