注册中心Zookepper
帮我们管理dubbo的
能解决故障
分担请求
角色介绍
服务提供者：暴露服务的服务提供方，服务提供者在启动是，向注册中心注册自己提供的服务
。。。
。。。
对于服务提供方和服务消费方来说，他们还有可能兼备这两种角色，即需要提供服务，也有需求服务。通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定的协议来完成服务对外的统一。Dubbo提供的注册中心有如下几种类型可以供选
- Multiscast注册中心：组播方式
- Redis注册中心：使用Redis作为注册中心
- Simple注册中心：就是一个dubbo服务。作为注册中心。提供查找服务的功能。
- Zookeeper注册中心：使用Zookeeper作为注册中心。
注册中心工作方式
现在主流官方推荐使用Zookeeper注册中心，经过实际考验的注册中心。
Zookeeper： 是Apacahe Hadoop的子项目，是一个树形目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明：
- 服务提供者启动时：/dubbo.com.foo.BarService/providers目录下写入自己的URL地址
- 服务消费者启动时:订阅/dubbo/com/foo.BarService/providers目录下的提供者URL地址。并向/dubbo/com/foo.BarService/consumers目录下写入自己的URL地址。
- 监控中心启动时：订阅/dubbo/com/foo.BarService目录下的所有提供者和消费者URL地址。
支持一下功能： - 当提供者出现异常断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求。
- 当设置<dubbo:registry check=“false” />失败时，记录失败注册和订阅请求，后台会定时重试
- 可通过 <dubbo:registry username=“admin” password=“1234” /> 设置 zookeeper 登录信息
- 可通过 <dubbo:registry group=“dubbo” /> 设置 zookeeper 的根节点，不设置将使用无根树
- 支持 * 号通配符 <dubbo:reference group="" version="" />，可订阅服务的所有分组和所有版本的提供者
下载下Zookeeper的安装包
解压
- 打开conf->zoo.cfg（这个是Zookeeper的配置文件）
- 修改dataDir（用于存储Zookeeper的快照数据，默认给/tmp/ziikerpe。不要使用默认的地址）。咱Zookeeper下面创建data文件夹。把地址复制给配置文件中的dataDir
- clientPort=2181，这是默认端口配置
- tickTime：心跳时间，单位ms。Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔。也就是说每个tickTime时间就会发送一个细条。表明存货状态。
- 添加admin.serverPort=8888,为了使Zookeeper3.5默认使用了8080，保证不冲突进行的修改。
- 来到lib目录
开始使用Zookeeper
安装Zookeeper
- Zookeeper下载
wget http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.11/zookeeper-3.4.11.tar.gz
- 解压
- 在Zookeeper根目录下创建data文件夹，用于存储Zookeeper的快照数据
- 进入conf目录拷贝zoo_samle.cfg为zoo.cfg
cp zoo_sample.cfg zoo.cfg
- 修改zoo.cfg文件
需要修改两处
1）修改一条dataDir：默认快照存储路径
2）添加一条：admin.serverPort=8888
- 可以配置环境变量启动
- 启动，去bin文件夹下
dubbo和Zookeeper一定要通讯：通过客户端的依赖就是一个jar包
客户端
<!--实现对Zookeeper注册中心的支持 -->
<!-- https://mvnrepository.com/artifact/org.apache.curator/curator-framework -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>4.2.0</version>
</dependency>
新项目要加入这个jar包，实现对注册中心的支持
dubbo的配置
- 配置原则：在服务提供者配置访问参数。因为服务提供者更了解服务的各种参数
- 关闭检查：Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，组织spring初始化完成，以便上线时，能及早发现问题。默认check=true，通过check="false"关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必有一方先启动。
例1：关闭某个服务的启动时检查
<dubbo:reference interface="com.foo.BarService" check="flase" />
例2：关闭注册中心启动时检查
<dubbo:registry check="false" />
默认启动服务时检查注册中心存在并运行。注册中心不会启动报错。 - 重试次数：消费者访问提供者，如果访问失败，则切换重试访问其他服务器，但重试会带来更长时间的延迟。反问时间边长，用户的体验较差。多次重新访问服务器有可能会成功。可通过retries="2"来设置重试次数（不含第一次）
<dubbo:service retires="2" />
或
<dubbo:reference retries="2" />
- 超时时间：由于网络服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）时间耗尽，必须设置超时时间。
timeout：调用远程服务超时时间（ms）
4.1 dubbo消费端
<dubbo:reference interface="com.foo.BarService" timeout="2000" />
4.2 dubbo服务端
<dubbo:server interface="com.foo.BarService" timeout="2000" />
- 版本号：每个接口都应定义版本号，为后续不兼容升级提供可能。当一个接口有不同实现，项目早起使用的一个实现类，之后创建接口的新的实现类。区分不同的接口实现使用version。特别是项目需要把早期接口的实现全部换为新的实现类，也需要version。
可以用版本号从早起的接口实现过度到新的接口实现，版本号不同的服务相互之间不引用。
可以按照以下步骤进行版本迁移（可以做到整个业务不会停）：
- 在请求低压力（就用户请求少的）时间段，先升级一半提供者为新版本。
- 再将所有消费者升级为新版本。
- 然后将剩下的一半提供者升级为新版本。
监控中心
dubbo的使用，其实只需要有注册中心，消费者，提供者。这三个就可以使用了，但并不能看到有哪些消费者和提供者，为了更好的调试，发现问题，解决问题。因此引入dubbo-admin。通过dubbo-admin可以对消费者和提供者进行管理。可以在dubbo应用部署做动态调整、服务的管理。
dubbo-admin：图形化的服务管理页面；安装时需要指定注册中心地址，即可从注册中心获取到所有提供者/消费者进行陪孩子管理
dubbo-monitor-simple：简单的监控中心。
我们来说dubbo-admin
发布配置中心
- 下载监控中心，http://github.com/apache/incubator-dubbo-ops
这里是源代码需要手工编译才能使用 - 运行管理后台dubbo-admin
到dubbo-admin-0.0.1-SNAPSHOT.jar所在目录。执行下面命令
java -jar dubbo-admin-0.0.1-SANAPSHOT.jar
如有修改配置
默认端口7001
默认注册中心Zookeeper
