1、Dubbo

1.1、什么是Dubbo

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源Java RPC框架 。
官网地址：https://dubbo.apache.org/zh-cn
Dubbo框架结构设计—–SOA思想
Dubbo框架通信方式—RPC思想

1.2、Dubbo的核心能力

1）、面向接口的远程方法调用
2）、智能容错和负载均衡
3）、服务自动注册和发现

1.3、Dubbo的核心架构

provider：暴露服务的提供方
consumer：调用远程服务的消费放
registry：服务注册中心和发现中心
container：服务运行的容器
monitor：统计服务和调用次数，调用时间监控中心
1.当服务提供者启动时,会链接注册中心,将服务提供者的信息(服务名称/IP/PORT)写入注册中心.

​ 2.当注册中心接收提供者数据之后,将数据写入维护的服务列表中.

​ 3.当消费者启动时,首先会链接注册中心获取服务列表.

​ 4.获取服务列表之后,保存到本地.

​ 5.当消费者需要调用服务时,查询本地的服务列表数据,之后根据负载均衡策略,挑选其中正常的链接地址进行访问.(RPC)

​ 6.当服务提供者宕机时,注册中心会有心跳检测机制.如果断定服务宕机.则会动态的维护注册列表之后广播通知所有的服务消费者动态更新服务列表数据. 这样就能够保证消费者访问提供者都是有效的!!!

1.4、特性

• 面向接口代理的高性能RPC调用
  提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
• 面向接口代理的高性能RPC调用
  提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
• 面向接口代理的高性能RPC调用
  提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
• 智能负载均衡
  内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
• 服务自动注册与发现
  支持多种注册中心服务，服务实例上下线实时感知。
• 高度可扩展能力
  遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
• 运行期流量调度
  内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
• 可视化的服务治理与运维
  提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

1.5、负载均衡

Dubbo框架实现负载均衡有4种方法：轮询，随机、iphash、最少使用。

其中默认的方法为随机算法，更换方法如下：

1.6、关于Dubbo的几个小问题

1.6.1、当后台服务的提供者有一个宕机时，是否影响消费者的访问

答：不影响。因为有一个提供者宕机的话，注册中心会ping提供者，ping不通时会将这个提供者标识为down，然后提箱消费者进行地址列表更新，从而访问其他的提供者。

1.6.2、如果zookeeper集群宕机，是否有影响

答：短时间不影响。因为提供者启动时，会将自己的路径加端口都注册到zookeeper，而消费者访问时，会先连接zookeeper，下载提供者的注册信息到本地，所以，短时间内不会影响访问者。

1.6.3、如果zookeeper集群宕机，此时有一个提供者宕机，是否有影响

答：消费者不受影响.因为消费者本地有注册列表信息,如果消费者访问的服务器是宕机的,则将本地的服务列表标识为down,之后会自动的链接其他的服务器.

2、zookeeper

2.1、简介

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集，提供Java和C的接口。
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_homesrcrecipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。
下载地址

2.2、安装

暂时不写 完了写了粘链接过来

2.3、集群选举

zookeeper集群的选举是按照最大值优先的算法执行的

2.4、集群节点问题

问：为什么集群搭建时服务器数量都是奇数
因为集群宕机的条件是：
剩余服务器数量>布置服务器的数量的一半
比如：布置台数为3台，可以宕机1台，2>1.5
布置台数为5台，可以宕机2台,3>2.5
布置台数为7台，可以宕机3台，4>3.5
那么如果布置4台，依旧是可以宕机1台，宕机2台的话2>2是不成立的；同样，布置6台8台可以宕机数量为2台和3台。
由此可以看出，布置3台与4台的效果一样，都是宕机一台，再多的话集群崩溃，因而，布置奇数的服务器可以节省开支。