版权声明:本文为博主原创文章,未经博主允许不得转载。
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选举,分布式锁等。
-
顶
- 0
-
踩
- 0
- 上一篇Java抽象类与接口
- 下一篇分布式事务
我的同类文章
- •NIO+异步-jetty实现2015-10-08阅读295
- •java分布式通信系统(J2EE分布式服务器架构)2015-09-01阅读195
- •The Apache Tomcat Native library which allows optimal performance in produc2015-06-17阅读216
- •Tomcat启动的时候报 validateJarFile(xxxx) jar not loaded2015-06-09阅读288
- •JSF注册ManagedBean的流程2015-06-04阅读244
- •ORM框架Hibernate多对多关联映射的HQL中的in条件查询问题2015-09-08阅读264
- •Jetty一个开源的servlet容器2015-08-06阅读373
- •IOException while loading persisted sessions2015-06-10阅读260
- •JSF扩展插件之prettyFaces2015-06-04阅读724
- •JSF框架2015-06-04阅读188
暂无评论