0%

初探Eureka与Zookeeper

服务注册中心,给客户端提供可供调用的服务列表,客户端在进行远程服务调用时,根据服务列表然后选择服务提供方的服务地址进行服务调用。服务注册中心在分布式系统中大量应用,是分布式系统中不可或缺的组件,例如rocketmq的name server,hdfs中的namenode,dubbo中的zk注册中心,spring cloud中的服务注册中心eureka。 在spring cloud中,除了可以使用eureka作为注册中心外,还可以通过配置的方式使用zookeeper作为注册中心。既然这样,我们该如何选择注册中心的实现呢?

CAP定理

又被称作布鲁尔定理(Eric Brewer)它指出对于一个分布式计算系统来说,不可能同时满足以下三点:

  1. 强一致性(Consistency):系统在执行某项操作后数据状态仍然处于一致,例如在分布式系统中,更新操作执行成功后所有的用户都应该读取到最新的值,这样的系统被认为具有强一致性。
  2. 可用性(Availability):每一个操作总是能够在一定的时间内返回结果
  3. 分区容错性(Partition tolerance):单个节点故障不应导致整个系统崩溃,也就是说尽管网络在节点之间丢弃(或延迟)任意数量的消息,但是系统继续操作。

根据CAP原理将数据库分成了满足CA原则、满足CP原则和满足AP原则三大类

  1. CA:单点集群,满足一致性,可用性,通常在可扩展性上不太强大,比如RDB。
  2. CP:满足一致性和分区容错性,通常性能不是特别高,如分布式数据库。
  3. AP:满足可用性和分区容错性,通常可能对一致性要求低一些,如大多数的NoSQL。

BASE(Basically Available,Soft-state,Eventual consistency)

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

  1. 基本可用(Basically Available):系统能够基本运行并一直提供服务。
  2. 软状态(Soft-state):系统不要求一直保持强一致状态。
  3. 最终一致性(Eventual consistency):系统需要在某一时刻后达到一致性要求。

Zookeeper保证CP

  • 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

  • Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
    3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
  • 因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

Zookeeper概述

  • 背景
    • Zookeeper可以让企业的IT架构逐步从集中式向分布式过度,所谓的分布式是指:把一个计算任务分解成若干个计算单元,并且分派到若干不同的计算机中去执行,然后汇总计算结果的过程。
  • Zookeeper介绍
    • Zookeeper是源代码开放的分布式协调服务,由雅虎创建,是Google Chubby开源实现。Zookeeper是一个高性能的分布式数据一致性解决方案,它将那些复杂、容易出错的分布式一致性服务封装起来,构成一个搞笑可靠的原语集,并提供一系列简单易用的接口给用户使用。
  • Zookeeper的典型应用场景
    • 数据发布/订阅 顾名思义就是一方把数据发布出来,另一方通过某种手动可以得到这些数据。
      • 通常数据订阅有两种方式:推模式和拉模式,推模式一般是服务器主动向客户端推送消息,拉模式是客户端主动去服务端获取数据(通常采用的是轮询的方式)。
      • Zookeeper采用两种方式的结合。
        • 发布者将数据发布到Zookeeper集群节点上,订阅者通过一定的方法告诉服务器,我对那个节点的数据感兴趣,那个服务器在这些节点的数据发送变化时,就通知客户端,客户端得到通知后可以去服务器获取数据信息。
        • 分布式协调/通知
          • 心跳检测:在分布式系统中,通常需要机器是否可以用,Zookeeper中我们让所有的机器都注册一个临时节点,所以只需要判断这个节点是否存在就可以了,不需要直接去连接需要检查的机器,降低系统的负载度(节点分为临时和持久)。
  • Zookpeeper重量级使用
    • Hadoop、HBase、Storm、Solr。

Zookeeper的基本概览

  • 集群角色
    • Leader、Follower、Observer
      • Leader服务器是整个Zookeeper集群工作机制的核心
      • Follower服务器是Zookeeper集群状态的跟随者
      • Oserver服务器充当一个观察者的角色
      • Leader、Follower设计模式,Observer观察者模式
  • 会话
    • 会话是指客户端Zookeeper服务器的连接,Zookeeper中的会话叫Session,客户端与服务器建立TCP的长连接来维持一个Session,客户端在启动的时候首先会与服务器建立一个TCP连接,通过这个连接客户端能够通过心跳检测与服务器保持有效的会话,也能向Zookeeper服务器发送请求并获得响应。
  • 数据节点
    • Zookeeper中的节点有两类
      • 集群中的一台机器称为一个节点
      • 数据模型中的数据单元Znode,分别为持久节点和临时节点。(其实数据节点就是一个tree节点就是Znode)
  • 版本
    • Zookeeper中的版本
      • version
        • 当前数据节点数据内容版本
      • cversion
        • 当前数据节点子节点的版本号
      • aversion
        • 当前数据节点ACL变更版本号
  • watcher(事件监听器)
    • Zookeeper允许用户在指定节点上注册一些Watcher,当数据节点发生变化的时候,Zookeeper服务器会把这个变化通知发送给感兴趣的客户端。
  • ACL权限控制
    • ACL是Access Contril Lists 的缩写,Zookeeper采用ACL策略来进行权限控制,有以下权限:
      • CREATE:创建子节点
      • READ:获取子节点
      • WRITE:更新子节点数据权限
      • DELETE:删除子节点权限
      • ADMIN:设置节点ACL权限

Zoopeeper环境搭建(集群、单机、伪集群)

  • 单机模式(设备环境有限暂时单机)
    • 准备工作
      • 下载Zookeeper(此处自行处理)
      • 解压 tar xzvf xxx.gz 解压
      • 重命名文件夹 Zookeeper 命令mv xxx xxx 后面的参数是新名字(可以不做)
      • 进入文件夹中/conf/
      • 复制配置文件zoo_sample.cfg(样例文件) 并重命名 zoo.cfg
    • 编辑zoo.cfg内容(仅供参考,具体环境自行修改)
    • tickTime = 2000
      • tickTime:基本事件单元,以毫秒为单位。这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个 tickTime 时间就会发送一个心跳。
    • initLimit= 5
      • initLimit:这个配置项用来配置Zookeeper接受客户端初始化连接时最长能忍受多少个心跳时间间隔数,当已超过5个心跳的时间(也就是tickTime)长度后Zookeeper服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度是5 * 2000=4s。
    • dataDir = D:\zookeeper\data
      • 顾名思义就是 Zookeeper 保存数据快照的目录,默认情况下,Zookeeper 将写数据的日志文件也保存在这个目录里)。
    • dataLogDir= D:\zookeeper\log
      • 顾名思义就是 Zookeeper 保存日志的目录。
    • synclimit = 5
      • 这个配置项表示Leader与Follower之间发送消息,请求和应答时间长长度,最长不能超过多少个tickTime的时间长度,总的时间长度是2 * 2000 = 4s。
    • clientPort = 2181
      • 这个端口就是客户端连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口,接受客户端的访问请求。
    • Server(待续)
      • 格式:server.id=host:port:port(两个port保证可以正常使用就行)
        • id:通常为整数,并且不能重复使用整数。
        • host:服务器的IP地址。
        • port: Follower端口
        • port: Leader选举投票。
      • ZooKeeper建议使用hostname,而非ip。这需要对主机的/etc/hostname和/etc/hosts做host绑定(不用的OS不同修改方式)。
      • 创建一个myid文件(放在 dataDir文件下面)
      • 写入一行数据(请查阅zoo.cfg文件)
        • 写入id位置的数据即可。表示当前系统环境Zookeeper是哪一个Server(通讯用的)。
    • 启动服务与停止服务
    • 进入bin/文件
    • 执行zkServer.cmd 或则 zkServer.sh
    • CMD直接双击运行 ,SH则 sudo sh ./zkServer.sh start 启动 stop 关闭
    • 验证 使用telnet来测试(自行安装)
      • telnet ip port 敲命令 stat 若返回数据表示当前服务器不能对外提供服务表明集群下其他服务器未启动(在Zookeeper中只要有半数的服务器正常工作就可以向外提供服务)。
    • 在此简单说明下何为伪集群就是在一台服务器上的多个Zookeeper的集群叫伪集群(伪集群 两个port不能与其他zookeeper的port一样)。
    • 单机模式就删除其他服务器运行的时候就是单机模式。