DonY15 > Zookeeper与Dubbo基础原理

Zookeeper与Dubbo基础原理

2018-07-08

Zookeeper与Dubbo基础原理

[TOC]

1.Zookeeper(RPC框架)

高效的分布式分布式应用协调服务,提供注册和负载均衡等–>服务中心

Zookeeper也是集群管理工具,用来管理各种需要的集群,如solorCloud

  • zookeeper让调用者知道调用的哪台服务器地址,也是集群的管理者
  • Zookeeper具有心跳检测机制,当服务器挂掉时可以让调用者知道,从而切换请求服务器
  • Zookeeper具有高并发的横向扩展,在不改变代码的情况下对设备进行扩展

1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理

命名服务:在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现。

配置管理:程序分散部署在多台机器上难以管理,可以将每台设备的信息存储在Zookeeper的目录节点中,然后相关程序对该目录进行监控,如果配置信息发生变化,则Zookeeper会发布新的配置

集群管理:(1)设备的加入(2)选举master(可以改变设备编号,编号第一位自动master(一种思路))

分布式锁:zookeeper是一致性的文件系统,锁服务可以分为两类，(1)保持独占，(2)控制时序。

列队管理:

  1. 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
  2. 队列按照 FIFO 方式进行入队和出队操作。和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
1-1.特性
  1. 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
  2. 可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
  3. 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
  4. 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
  5. 原子性：更新只能成功或者失败，没有中间状态。
  6. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
1-2.Zookeeper工作原理

​ Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态

​ 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

(部分整理)

原文:https://blog.csdn.net/xqb_756148978/article/details/52259381

2.Dubbo(SOA基础框架)

管理中间层的框架,与注册中心搭配使用,如Zookeeper(最常用),使之具有Zookeeper负载均衡/资源同步等的特性

​ 单一应用架构(ORM)

–>垂直应用架构(MVC) 传统架构,难以应对高并发/高可用问题

–>分布式服务架构(RPC) 功能拆分,多台服务器做不同的功能,相当于节点,一个节点下可以有多态服务器做集群

–>流动计算架构(SOA) 节点和节点通过SOA通信,将冗余的业务逻辑单独提取出来,分为表现层和业务层 缓存 数据库层…

2-1.核心部分
  1. 远程通讯
  2. 集群容错
  3. 自动发现
2-2.作用
  1. 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入
  2. 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点.
  3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo采用全spring配置方式,透明化接入,应用,没有API入侵

2-3.架构

Provider: 暴露服务的服务提供方。

​ Consumer: 调用远程服务的服务消费方。

​ Registry: 服务注册与发现的注册中心。

​ Monitor: 统计服务的调用次调和调用时间的监控中心.

​ Container: 服务运行器。

2-4.调用关系说明：
  1. 服务容器负责启动，加载，运行服务提供者。
  2. 服务提供者在启动时，向注册中心注册自己提供的服务。
  3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
  4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
2-5.注意Dubbo内部版本冲突

dubbo的jar包中存在spring 2.+版本以及netty过时版本,需要屏蔽使用,防止冲突

1
2
3
4
5
6
7
8
9
10
<exclusions>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.jboss.netty</groupId>
                <artifactId>netty</artifactId>
            </exclusion>
        </exclusions>
2.6注意Dubbo发布过程
  1. 初始化Spring容器
  2. 占用暴露服务的端口进行发布,此时本机的端口不可以冲突

收藏Dubbo架构详解http://shiyanjun.cn/archives/325.html