Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求,并且本质上是个服务调用的东东,说白了就是个远程服务调用的分布式框架。
其核心部分包含
优点:
缺点:
节点角色说明
Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载。 如果不想使用Spring配置,而希望通过API的方式进行调用(不推荐)
dubbo的负载均衡策略,主体向外暴露出来的是一个接口,名字叫loadBlance,位于com.alibaba.dubbo.rpc.cluster包下,很明显根据包名就可以看出它是用来管理集群的。 接口就一个方法:select方法的作用就是众多的调用者的List选出一个调用者,invoker可以理解为客户端的调用者,dubbo专门封装了一个类来表示,URL就是调用者发起的URL请求链接,从这个URL中可以获取很多请求的具体信息,invocation表示的就是调用的具体过程,dubbo用这个类模拟调用具体细节过程: 抽象类 AbstractLoadBalance分为四个方法:一致性Hash均衡算法、随机调用法、轮询法、最少活动调用法
对于服务提供方,它需要发布服务,而且由于应用系统的复杂性,服务的数量、类型也不断膨胀; 对于服务消费方,它最关心如何获取到它所需要的服务,而面对复杂的应用系统,需要管理大量的服务调用。 而且,对于服务提供方和服务消费方来说,他们还有可能兼具这两种角色,即既需要提供服务,有需要消费服务。 通过将服务统一管理起来,可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。
Zookeeper作为Dubbo服务的注册中心,Dubbo原先基于数据库的注册中心,没采用Zookeeper,Zookeeper一个分布式的服务框架,是树型的目录服务的数据存储,能做到集群管理数据 ,这里能很好的作为Dubbo服务的注册中心,Dubbo能与Zookeeper做到集群部署,当提供者出现断电等异常停机时,Zookeeper注册中心能自动删除提供者信息,当提供者重启时,能自动恢复注册数据,以及订阅请求。
简单来说打个比方:dubbo就是动物园的动物,zookeeper是动物园。如果游客想看动物的话那么就去动物园看。比如你要看老虎,那么动物园有你才能看到。换句话说我们把很多不同的dubbo(动物)放到zookeeper(动物园中)提供给我们游客进行观赏。这个过程中三个关键:场所、供给者、消费者。
再说一个分布式的项目,server(消费)层与 service(供给)层被拆分了开来, 部署在不同的tomcat中, 我在server层需要调用 service层的接口,但是两个运行在不同tomcat下的服务无法直接互调接口,那么就可以通过zookeeper和dubbo实现。就好比把动物放到动物园,我们要看了直接去动物园就行。而不能直接去动物生活的地方去看,会有性命安全之忧(比如你去看老虎)。 我们通过dubbo 建立service这个服务,并且到zookeeper上面注册,填写对应的zookeeper服务所在的IP及端口号
不管是在集群启动时选举Leader还是集群运行中重新选举Leader。集群中每个Follower角色服务都是以上面的条件作为基础推选出合适的Leader,一旦出现某个节点被过半推选,那么该节点晋升为Leader。 ZooKeeper认为投票结果超过了集群总数的一半,便可以安全的处理后续事务。