dubbo+Zookeeper

架构的演变

单一系统 扩展不易：添加某一个功能需要重新打包整个项目开发不易：所有模块儿都需要同一个项目中开发 垂直架构 将所有功能拆分成若干个小程序，部署到不同的服务器上（解决了单一系统的问题） 页面和业务不分离，修改页面就得对整个模块进行部署应用之间需要交互 分布式架构 抽出核心业务，供多方进行调用

但是问题来了不同服务器上如何调用？

dubbo

PRC基本原理： 影响RPC速度的两个核心：序列化和反序列化，socket通信耗时

1.1、概述：

dubbo是一款高性能的RPC框架，提供三大核心能力： 面向接口的远程方法调用智能容错和负载均衡服务自动注册和发现

dubbo原理

dubbo的通信是实现了RPC技术，致力于封装通信的细节，通信的底层是Netty netty：是一个异步事件驱动的网络应用框架，用于快速开发可维护性的高性能协议服务器和客户端，他极大的简化了TCP和UDP套接字服务器等网络编程，利用NIO（非阻塞IO）实现 NIO RPC 封装底层的调用细节：

服务自动注册和发现 zookeeper提供

dubbo底层分为10层，每层的作用如下：

第一层：service层，接口层，给服务提供者和消费者来实现的

第二层：config层，配置层，主要是对dubbo进行各种配置

第三层：proxy层，服务代理层，透明生成客户端的stub和服务端的skeleton

第四层：registry层，服务注册层，负责服务的注册和发现

第五层：cluster层，集群层，封装多个服务提供者的路由和负载均衡，将多个实例组合成一个服务。

第六层：monitor层，监控层，对RPC接口的调用次数和调用时间进行监控

第七层：protocol层，远程调用层，封装RPC调用

第八层：exchange层，信息交换层，封装请求响应模式，同步转异步

第九层：transport层，网络传输层，抽象mina和netty为统一接口

第十层：serialize层，数据序列化层 dubbo的实际操作

启动检查超时处理重试次数 本地存根：当我们在调用数据时，可能因为某些参数不合理而导致程序最终不能正确调用，我们可以在本地缓存一份逻辑，在远程调用之前，先走一次本地逻辑，确定没问题后，再进行远程连接

集群和分布式区别

相同点：

分布式和集群都是需要有很多节点服务器通过网络协同工作完成整体的任务目标

不同点：

分布式是指将业务系统进行拆分，即分布式的每一个节点都是实现不同的功能。而集群的每个节点做的是同一件事情。

每个人都有不同分工，一起协作干一件事，叫“分布式”。

zookeeper宕机和dubbo直连

zookeeper宕机后dubbo还可以用吗？

可以，如果zookeeper集群中的某一台机器坏掉了，那么dubbo会自动访问zookeeper集群中的其他主机，zookeeper集群坏了，dubbo会在第一次加载完数据后，保存到本地一份，可以直接访问本地的数据。dubbo可以直连，绕开zookeeper

集群下的dubbo负载均衡策略

在集群情况下，dubbo提供了多种负载均衡策略，默认值为random随机调用

方案1：random loadbalance：随机的基于权重的负载均衡。默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认就可以。 设置权重后随机的概率将为weight/（100+200+50）

方案2：roundrobin loadbalance：基于轮询的负载均衡。默认就是均匀的将流量打到各个机器上去，如果各个机器性能不一样，容易导致性能差的机器负载过高，此时需要调整权重，让性能差的机器承载的权重小一些，流量少一些。 设置权重后轮询将按照其概率进行依次调用即：1-2-3-1-2-1-2-2-2；why？100/350;200/350;50/350

方案3：leastactive loadbalance：基于消耗时间的判断，就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求；处理最快的服务器请求越来越多，它耗时又会更长，dubbo又会选择其他耗时少的服务器

方案4：constanthash loadbalance：一致性hash算法，相同参数的请求一定分发到一个provider上，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，就走这个一致性hash策略

dubbo+zookeeper机制

流程：

生产者启动后将自己的ip地址、功能和端口号暴露给zookeeper进行注册；zookeeper保存这些内容； 当dubbo启动时会订阅服务地址，并且当生产者的地址发生变化zookeeper会在第一时间推送给dubb；当消费者需要请求某个服务时，dubbo判断它的请求地址匹配给他一个服务器ip地址和端口，实现远程调用。当有多个消费者时默认采用随机调用实现负载均衡；并且当某一个生产者挂掉了之后(连接失败）dubbo会随机重新分配一个地址进行重试

dubbo集群容错

当一个服务调用另一个服务失败时采取的处理方案；

failover cluster模式：（故障迁移）失败时自动切换，自动重试其他服务器，retries设置重试次数（dubbo默认方案）failfast cluster模式：一次调用失败就立即失败failsafe cluste模式：出现异常直接忽略failback cluster模式：失败后后台自动记录请求，然后定时重发，比较适合消息队列forKing cluster：并行调用多个provider只要有一个成功就立即返回，forks设置最大并行数，很消耗资源

dubbo的服务降级

当服务器的压力剧增时，根据各模块的的流量，对一些业务和页面进行降级（不处理或者做一些简单的处理）；从而释放服务器的资源保证核心逻辑的正确高效执行。 两种手段：

返回值为null，直接不发起远程调用调用失败直接返回null，不抛出异常，用来容忍服务不稳定对调用方的影响。

Zookepper

文件系统加上通知机制

概述

一个基于观察者模式设计的分布式服务服务管理框架，他负责存储和管理大家都关心的数据，然后接受观察者的主从，一旦这些数据的状态发生改变，Zookeeper就负责和已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式

作用

统一命名服务（dubbo）配置维护集群管理分布式消息同步和协调机制负载均衡对dubbo的支持 Zookeeper提供了一套很好的分布式集群管理的机制，就是它基于层次型目录树的数据结构，并对树种的节点进行有效的管理，从而设计出多种多样的分布式管理模式，作为分布式调度和沟通的桥梁

配置参数

tickTime：通信的心跳数，zookeeper服务器心跳时间，单位是毫秒 zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间都会发送一个心跳，时间为毫秒，它用于心跳机制，并且设置最小的session是超时 initLimit：LF初始通信时限 集群中的follower跟随者服务器（F）与leader（L） 之间初始连接时能容忍的最多时间，用它来限定集群中Zookeeper服务器连接到Leader的时限：也就是说投票选举leader，让follower在启动过程中，从leader中同步数据时，限定F在initLImit时间内完成这个工作 syncLimit：LF同步通信时限 集群中Leader与Follower之间通信的最大相应时间单位，加入响应时间超过syncLimit*tickTime，Leader认为Follower死掉，从服务器列表中删除Follower dataDir：数据文件目录+数据持久化路径ClientPort：端口号

Zookeeper入门

文件系统 zookeeper维护了一个类似文件系统的数据结构，类似于windows的注册表，有名称、树节点、有键值对的关系 初始znode节点 zookeeper数据结构类似于Unix文件系统，整体上为一棵树，每个节点ZNode都可以通过其路径唯一标识 Znode znode的结构模型 zookeeper的stat结构体 znode维护了一个stat结构，这个stat包含数据变化的版本号，访问控制列表变化，还有时间戳，版本号和时间戳一起。可让zookeeper验证缓存和协调更新，每个znode数据发生了变化，版本号就增加 例如：无论何时客户端检索数据，它也一起检索数据的版本号，并且当客户端执行更新或删除时，客户端必须提供它正在改变的znode版本号，如果它提供的版本号和真实版本号不一致，更新。 czxid：引起这个znode创建的zxid，创建节点的事务zxid，为了保证顺序性zkid：必须单调递增，因此zookeeper使用一个64位的数来表示，高32位是leader的epoch，从1开始，每次选出新的leader，epoch加1，低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置，这样保证zkid的全局递增性ctime：znode被创建的毫秒数（1970年开始）mzxid：znode最后更新的zxidmtime：znode最后被修改的时间pzxid：znode最后更新的子节点zxid zookeeper内部维护了一套类似于Unix的树形结构，由znode构成的集合，每个znode由多个树描述

znode存在的类型

PERSISTENT：持久化目录节点PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点EPHEMERAL：临时节点目录EPHEMERAL_SEQUENTIAL：临时顺序编号目录节点 Zookeeper的一个节点对应一个应用，节点存储的数据就是应用需要的配置信息

watch

数据观察和节点观察

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、删除、子节点增加、zookeeper会通知客户端）

zookeeper支持watch的概念，客户端可以在每个znode节点上设置一个观察，如果被观察服务端的znode节点有变更，那么watch就被触发，这个watch所属的客户端将收到一个通知包被告知那个节点发生了变化，把相应的时间通知给设置watcher的client端

在getData() getChildren()和exist()都有设置watch的选项。