Dubbo是管理中间层的工具,在业务层到数据仓库间有很是多服务的接入和服务提供者须要调度,dubbo提供一个框架解决这个问题。Dubbo基于RPC(Remote Procedure Call 远程过程调用)协议,服务提供方和服务消费方之间的调用关系:nginx
节点角色说明web
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明算法
0.服务容器负责启动,加载,运行服务提供者。数据库
1.服务提供者在启动时,向注册中心注册本身提供的服务。缓存
2.服务消费者在启动时,向注册中心订阅本身所需的服务。服务器
3.注册中心返回服务提供者地址列表给消费者,若是有变动,注册中心将基于长链接推送变动数据给消费者。并发
4.服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,若是调用失败,再选另外一台调用。负载均衡
5.服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。框架
这个框架要完成调度必需要有一个分布式的注册中心,存储全部服务的元数据,用到zookeeper。分布式
zookeeper用来注册服务和负载均衡。
哪个服务由哪个机器来提供必须让调用者知道,简单来讲就是ip地址和服务器名称的对应关系。 固然也能够将这种对应关系经过硬编码在调用方业务代码中实现,可是若是提供服务的机器挂掉调用方没法知晓,若是不更改代码会继续请求挂掉的机器提供服务。zookeeper能够经过心跳机制检测挂掉的服务器并将挂掉的服务器的ip和服务器对应的关系从列表中删除。
至于支持高并发,就是横向扩展,在不更改代码的状况经过添加机器来提升运算能力。
Dubbo将注册中心进行抽象,使得它能够外接不一样的存储媒介给注册中心提供服务。
引入zookeeper做为存储媒介,也就把zookeeper的特性引了进来。
首先是负载均衡:单注册中心的承载能力是有限的,在流量达到必定程度的时候须要分流,负载均衡就是为了分流而存在的,一个zookeeper集群配合相应的web应用就很容易达到负载均衡;
资源同步:单单有负载均衡还不够,节点之间的数据和资源是须要同步,zookeeper集群就自然具有有这样的功能;
命名服务:将树状结构用于维护全局的服务地址列表,服务提供者在启动的时候,向zookeeper上的指定节点目录下写入本身的URL地址,这个操做就完成了服务的发布
Mast:ZooKeeper能会保证客户端没法建立一个已经存在的ZNode。也就是说,若是同时有多个客户端请求建立同一个临时节点,那么最终必定只有一个客户端请求可以建立成功。利用这个特性,就能很容易地在分布式环境中进行Master选举了。
分布式锁:分布式锁是控制分布式系统之间同步访问共享资源的一种方式。当前得到锁的客户端机器发生宕机或重启,那么该临时节点就会被删除,释放锁。正常执行完业务逻辑后,客户端就会主动将本身建立的临时节点删除,释放锁。
优势:
透明化的远程方法调用
像调用本地方法同样调用远程方法;只需简单配置,没有任何API侵入。
软负载均衡及容错机制
可在内网替代nginx lvs等硬件负载均衡器。
服务注册中心自动注册 & 配置管理
不须要写死服务提供者地址,注册中心基于接口名自动查询提供者ip。
使用相似zookeeper等分布式协调服务做为服务注册中心,能够将绝大部分项目配置移入zookeeper集群。
服务接口监控与治理
Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能,针对不一样应用的不一样接口,能够进行 多版本,多协议,多注册中心管理。
缺点:只支持JAVA语言
启动dubbo时,消费者会从zookeeper中拉去注册的生产者的地址接口等数据,缓存在本地.每次调用时,按照本地存储的地址进行调用.可是在注册中心所有挂掉后增长新的提供者,则不能被消费者发现
健壮性:
监控中心宕掉不影响使用,只是丢失部分采样数据
数据库宕掉后,注册中心仍能经过缓存提供服务列表查询,但不能注册新服务
注册中心对等集群,任意一台宕掉后,将自动切换到另外一台
注册中心所有宕掉后,服务提供者和服务消费者仍能经过本地缓存通信
服务提供者无状态,任意一台宕掉后,不影响使用
服务提供者所有宕掉后,服务消费者应用将没法使用,并没有限次重连等待服务提供者恢复
做者:普度众生的面瘫青年(原文做者)连接:https://www.jianshu.com/p/527e2944034c