dubbo 是一个远程调用服务的分布式框架,可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务,使得远程调用的协议可以使用dobbo协议( dubbo://xxxx )或者其它协议,可以配置zookeeper集群地址,实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候,它也是可以实现服务端和调用端的通信的,这种方式是点对点通信的,所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候,就会暴露许多的问题:增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心,来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式,即客户端和服务端共用一个接口(将接口打成一个jar包,在客户端和服务端引入这个jar包),客户端面向接口写调用,服务端面向接口写实现,中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务,providerxml文件
再来看服务消费者,consumerxml文件
这就是典型的点对点的服务调用。当然我们为了高可用,可以在consumerxml中配置多个服务提供者,并配置响应的负载均衡策略。
配置多个服务调用者在comsumerxml的dubbo:reference标签的url属性中加入多个地址,中间用分号隔开即可;配置负载均衡策略在comsumerxml的dubbo:reference标签中增加loadbalance属性即可,值可以为如下四种类型:
那么目前的架构有什么问题呢?
1当服务提供者增加节点时,需要修改配置文件。
2当其中一个服务提供者宕机时,服务消费者不能及时感知到,还会往宕机的服务发送请求。
这个时候就需要引入注册中心了,Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心,要使用注册中心,只需要将providerxml和consumerxml更改为如下:
如果zookeeper是一个集群,则多个地址之间用逗号分隔即可
把consumerxml中配置的直连的方式去掉
注册信息在zookeeper中如何保存?
启动上面服务后,我们观察zookeeper的根节点多了一个dubbo节点及其他,图示如下
最后一个节点中服务的地址,为什么把最后一个节点标成绿色?因为最后一个节点是临时节点,而其他节点是持久节点,这样,当服务宕机时,这个节点就会自动消失,不再提供服务,服务消费者也不会再请求。如果部署多个DemoService,则providers下面会有好几个节点,一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用,因为不同的框架会在zookeeper上建不同的节点,互不影响。如dubbo会创建一个/dubbo节点,storm会创建一个/storm节点。
zookeeper 介绍:
zookeeper是 Apacahe Hadoop 的子项目,是一个树型的目录服务,支持变更推送,适合作为 Dubbo 服务的注册中心,工业强度较高,可用于生产环境,并推荐使用。
流程说明:
支持以下功能:
补充:
dubbo的协议使用什么序列化框架?
dubbo有多种协议,不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明:Hessian2 是阿里在 Hessian 基础上进行的二次开发,起名为Hessian2)。rmi协议默认为 java 原生序列化,>其实U是一种表示服务器外部尺寸的单位,是unit的缩略语,详细尺寸由作为业界团体的美国电子工业协会(EIA)决定。
之所以要规定服务器的尺寸,是为了使服务器保持适当的尺寸以便放在铁质或铝质机架上。机架上有固定服务器的螺孔,将它与服务器的螺孔对好,用螺丝加以固定。
规定的尺寸是服务器的宽(4826cm=19英寸)与高(4445cm的倍数)。由于宽为19英寸,所以有时也将满足这一规定的机架称为“19英寸机架”。
厚度以4445cm为基本单位。1U就是4445cm,2U则是1U的2倍为889cm。也就是说所谓“1U的PC服务器”,就是外形满足EIA规格、厚度为4445cm的产品。设计为能放置到19英寸机柜的产品一般被称为机架服务器。
将服务器放置到机架上,并不仅仅有利于日常的维护及管理,也可能避免意想不到的故障。首先,放置服务器不占用过多空间。机架服务器整齐地排放在机架中,不会浪费空间。其次,连接线等也能够整齐地收放到机架里。电源线和LAN线等全都能在机柜中布好线,可以减少堆积在地面上的连接线,从而防止脚踢掉电线等事故的发生。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)