zookeeper 什么是微服务注册中心？

注册中心概述

注册中心是 Dubbo 服务治理的核心组件，Dubbo 依赖注册中心的协调实现服务（地址）发现，自动化的服务发现是微服务实现动态扩缩容、负载均衡、流量治理的基础。Dubbo 的服务发现机制经历了 Dubbo2 时代的接口级服务发现、Dubbo3 时代的应用级服务发现，具体可参见 服务发现机制 解析了解具体演进过程。

注册中心主要就是用来服务的管理，它的核心就是有服务的注册表，通过心跳的机制去动态维护。注册中心是基于生产者和消费者的一个模型。

服务提供者会在一启动的时候，向这个注册中心去进行注册，把自身的一些信息写到注册中心里面。服务消费者就可以通过注册中心去找到想要消费的服务。

最后服务消费者找到了一些信息，就会来服务提供者这边找到相应的服务提供者去请求它所提供的服务。

基本使用

开发应用时可以指定 Dubbo 注册中心（registry）组件，配置很简单，只需指定注册中心的集群地址即可：

dubbo
 registry
  address: {protocol}://{cluster-address}

以dubbo+zk为例子，服务提供者启动的时候就会向zk里面写入dubbo，一个provider这个目录去写入自己url的地址。

服务消费者启动的时候，通过订阅zk所创建的目录去获取提供者的url的地址，同时会在注册中心consumer的目录下面去写入自己url的一个地址。

这就是服务提供者和消费者在启动的时候会去做的一件事。

dubbo里面有个监控中心，监控中心在启动的时候去注册中心订阅整个生产者，消费者这样一个目录。通过订阅这个目录，就可以查到所有的提供者和消费者的url。

注册信息在zookeeper中如何保存？

启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下：

最后一个节点中192.168.1.104是内网地址，你可以任务和上面配置的localhost一个效果，大家可以想一下我为什么把最后一个节点标成绿色的。没错，最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。

其实一个zookeeper集群能被多个应用公用，如Storm集群和Dubbo配置的就是一个zookeeper集群，为什么呢？因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点，如图:

这就是dubbo和zk做的事情。也就相当于你朋友，服务消费者，要去找你，服务提供者。那要知道你的地址在哪，这个时候你就要将你的地址向当地的居委会进行一个注册，之后你的朋友，服务消费者，可以通过居委会，注册中心，去找到你居住的一个信息，从而去找到你这个人。

这就是服务提供者，消费者，注册中心的联系。

注册中心除了保存这些信息，还得去看提供者是否还活着。通过心跳的机制，通过发送心跳包确认自己还活着。如果超过了10s没有向注册中心发送心跳包，那么就认为服务提供者挂掉了，那么还会去通知服务消费者这个服务不可用，那么就会删除提供者的信息。

这样就可以帮助我们管理好我们的应用。

现在整体架构是如下图（假设服务消费者为订单服务，服务提供者为用户服务）：

这样会有什么问题呢？

1. 当服务提供者增加节点时，需要修改配置文件
2. 当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求

这个时候就得引入注册中心了。

如果发生了变动，因为流量进来了，单纯这几个服务提供者很难扛得住了，那么得去新启动一些服务提供者。如果没有注册中心，那么消费者全部得修改这个配置文件，那么这段时间对外是终止服务的。

Dubbo目前支持4种注册中心,（multicast zookeeper redis simple） 推荐使用Zookeeper注册中心，本文就讲一下用zookeeper实现服务注册和发现（敲黑板，又一种zookeeper的用处），大致流程如下：

现在我们来看Dubbo官网对Dubbo的介绍图，有没有和我们上面画的很相似。

最后最常见的就是zk + dubbo作为注册中心。