## 心跳机制
如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有**主动**和**被动**两种方式。
### 被动检测
**被动检测**是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。
上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，15秒之后注册就会将实例2移除掉。
### 主动检测
**主动检测**是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。
## Dubbo注册中心
### 核心功能
针对使用者，主要关注注册中心的以下五个核心接口，通过以下五个核心接口，可以实现服务的动态发布、动态发现以及优雅下线等操作：
- **注册服务**：将服务提供者的URL暴露至注册中心
- **注销服务**：从注册中心将服务提供者的地址进行摘除
- **订阅服务**：将从注册中心订阅需要消费的URL至本地,当注册中心的服务清单发展变化时,自动通知订阅者
- **退订服务**：取消向注册中心订阅的服务监听者
- **查找服务**：向注册中心查找指定的服务清单列表
### 生产特性
Zookeeper会有一些未知的问题出现，所以需要生产特性来应对各种可能出现的问题，从而提升产品的质量。该类功能针对使用者一般情况是没办法直接感受到，但其发挥的作用就是保障产品的高质量服务：
- **自动重连**：与Zookeeper或Redis的连接断开后，支持自动重新连接
- **自动切换**：与Zookeeper或Redis的连接失败后，支持自动切换
- **自动清理**：Zookeeper或Redis中的数据过期后，支持自动清理（超时自动摘除）
- **自动恢复**：与Zookeeper或Redis自动重连成功后，支持自动恢复（即再次发起注册、订阅或监听动作）
- **自动重试**：失败自动重试（注册、注销、订阅、退订、监听和取消监听失败，无限重试至成功为止）
- **自动缓存**：Client订阅的服务清单会自动离线缓存至JVM本地的文件（变更通知时更新）
## 业界方案
下面结合各个维度对比一下各组件：
| **方案** | **优点** | **缺点** | **访问协议** | **一致性算法** |
| :------------ | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------- | :------------- |
| **Zookeeper** | 1.功能强大，不仅仅只是服务发现；2.提供watcher机制可以实时获取服务提供者的状态；3.广泛使用，dubbo等微服务框架已支持 | 1.没有健康检查；2.需要在服务中引入sdk，集成复杂度高；3.不支持多数据中心 | TCP | Paxos（CP） |
| **Consul** | 1.开箱即用，方便集成；2.带健康检查；3.支持多数据中心；4.提供web管理界面 | 不能实时获取服务变换通知 | HTTP/DNS | Raft（CP） |
| **Nacos** | 1.开箱即用，适用于dubbo，spring cloud等；2.AP模型，数据最终一致性；3.注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理；4.纯国产，各种有中文文档，久经双十一考验 | 刚刚开源不久，社区热度不够，依然存在bug | HTTP/DNS | CP+AP |
| **Eureka** | | | HTTP | AP |
### Zookeeper
