java提高之dubbo

架构的发展

单一的系统

RPC的两个核心点：序列化和反序列化，以及socket通信消耗时间

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

dubbo原理：

dubbo的通信是封装了netty，netty底层封装了socket，多路IO复用

RPC 封装底层的调用细节

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

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

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

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

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

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

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

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

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

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

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

第十层：serialize层，数据序列化层

dubbo的实际操作

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

集群和分布式区别

相同点：

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

不同点：

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

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

1. zookeeper宕机和dubbo直连

高可用的定义：通过设计，减少系统不能提供服务的时间

zookeeper宕机后，dubbo还能用吗？

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

2. 集群下的dubbo负载均衡策略

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

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

方案2：roundrobin loadbalance：基于轮询的负载均衡。默认就是均匀的将流量打到各个机器上去，如果各个机器性能不一样，容易导致性能差的机器负载过高，此时需要调整权重，让性能差的机器承载的权重小一些，流量少一些。

方案3：leastactive loadbalance：基于消耗时间的判断，就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求

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

dubbo和zookeeper机制

zookeeper专门处理分布式，统一管理注册服务

通知，底层为文件系统加通知 变更时推送服务地址列表

容错机制：随机调用一个服务地址，如果失败重试另一地址

流程：生产者生产出来内容后，往zookeeper中注册。消费者去找zookeeper订阅，zookeeper具有通知的特征，生产者发生变化的时候，zookeeper会把变化推送给消费者，同时，dubbo自身也具备容错机制，调用服务器的时候，如果出错，会重试另一地址。长连接就是说一直处于连接状态。短连接是定时过一会连接一次。

dubbo集群容错

当一个服务调用另一个服务，如果失败时的处理方案

failover cluster模式：（故障迁移）默认值，失败时自动切换，自动重试其他机器，retries设置重试次数

failfast cluster模式：一次调用失败就立即失败

failsafe cluster模式：出现异常，直接忽略

failback cluster模式：失败了后台会自动记录请求，然后定时重发，比较适合消息队列

forking cluster：并行调用多个provider，只要一个成功就立即返回，forks设置最大并行数，消耗资源

dubbo的服务降级

当服务器压力剧增时，根据实际业务情况和流量，对一些服务和页面有策略的不处理或做一种简单的方式处理，从而释放服务器资源以保证核心逻辑正确高效执行（牺牲其他模块的性能，保证关键业务的性能）。

两种手段：

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

zookeeper

1. zookeeper是什么

zookeeper提供了一套很好的分布式集群管理的机制，就是它基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而设计出多种多样的分布式管理模式，作为分布式调度和沟通的桥梁。

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

2. 作用

1. 统一命名服务（dubbo）

2. 配置维护

3. 集群管理

4. 分布式消息同步和协调机制

5. 负载均衡

6. 对dubbo的支持

zookeeper的配置

• tickTime：通信的心跳数，zookeeper服务器心跳时间，单位是毫秒

zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一次心跳，时间为毫秒

它用于心跳机制

• 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的注册表，有名称、有树节点，有key/value对的关系

初始znode节点

zookeeper数据结构和Unix文件系统类似，整体上可以看做一棵树，每个节点称为一个ZNode，很显然，zookeeper集群自身维护了一套数据结构

整个存储结构是一个树形结构，每个ZNode默认能够存储1MB的数据，每个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最后更新的zxid
• mtime：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的选项。