注册中心：简单说就是记录部署服务机器地址的一个服务
在分布式系统里，就有一个类似的概念，不过它的名字可不是叫什么地图，而是叫注 册中心。但原理和地图其实差不多，就是将部
署服务的机器地址记录到注册中心，服务消费 者在有需求的时候，只需要查询注册中心，输入提供的服务名，就可以得到地址，从
而发起 调用。
注册中心原理：
在微服务架构下，主要有三种角色，服务提供者（RPC Server），服务消费者（RPC client）和服务注册中心（Registry）,三者的交互关系如下
RPC Server 提供服务，在启动时，根据服务发布文件server.xml中的配置的信息，向Registry 注册自身服务，并向Registry定期发送心跳汇报存货状态。
RPC Client 调用服务（服务消费者），在启动时，根据服务引用文件client.xml 中的配置信息，向Registry 订阅服务，把Registry 返回的服务节点列表缓存在本地内存中，并与RPC Server 建立连接。
当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地 内存中缓存的服务节点列表。 RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起 调用
编辑
注册中心实现方式
注册中心的实现主要涉及几个问题：注册中心需要提供哪些接口，该如何部署；如何存储服 务信息；如何监控服务提供者节点的存活；如果服务提供者节点有变化如何通知服务消费 者，以及如何控制注册中心的访问权限。
1. 注册中心 API
根据注册中心原理的描述，注册中心必须提供以下最基本的 API，例如：
服务注册接口：服务提供者通过调用服务注册接口来完成服务注册。
服务反注册接口：服务提供者通过调用服务反注册接口来完成服务注销。
心跳汇报接口：服务提供者通过调用心跳汇报接口完成节点存活状态上报。
服务订阅接口：服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者 节点列表。
服务变更查询接口：服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列 表。
除此之外，为了便于管理，注册中心还必须提供一些后台管理的 API，例如：
服务查询接口：查询注册中心当前注册了哪些服务信息。
服务修改接口：修改注册中心中某一服务的信息。
2. 集群部署
注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可
用性，并通过分布式一致性协议来确保集群中不同节点 之间的数据保持一致
分布式一致性协议
一致性协议描述了特定一致性模型的实际实现。一致性模型就像是接口，而一致性协议就像是接口的具体实现。一致性模型提供了分布式系统中数据复制时保持一致性的约束，为了实现一致性模型的约束，需要通过一致性协议来保证
单主协议（不允许数据分歧）：整个分布式系统就像一个单体系统，所有写操作都由主节点处理并且同步给其他副本。例如主备同步、2PC、Paxos 都属于这类协议。
多主协议（允许数据分歧）：所有写操作可以由不同节点发起，并且同步给其他副本。例如 Gossip、POW。
可以发现，它们的核心区别在于是否允许多个节点发起写操作，单主协议只允许由主节点发起写操作，因此它可以保证操作有序性，一致性更强。而多主协议允许多个节点发起写操作，因此它不能保证操作的有序性，只能做到弱一致性。
单主协议：
单主协议的共同点在于都会用一个主节点来负责写操作，这样能够保证全局写的顺序一致性，它有另一个名字叫定序器，非常的形象。
主备复制
主备复制可以说是最常用的数据复制方法，也是最基础的方法，很多其他协议都是基于它的变种。 主备复制要求所有的写操作都在主节点上进行，然后将操作的日志发送给其他副本。可以发现由于主备复制是有延迟的，所以它实现的是最终一致性。
主备复制的实现方式：主节点处理完写操作之后立即返回结果给客户端，写操作的日志异步同步给其他副本。这样的好处是性能高，客户端不需要等待数据同步，缺点是如果主节点同步数据给副本之前数据缺失了，那么这些数据就永久丢失了。MySQL 的主备同步就是典型的异步复制。
两阶段提交
两阶段提交（2PC）是关系型数据库常用的保持分布式事务一致性的协议，它也属于同步复制协议，即数据都同步完成之后才返回客户端结果。可以发现 2PC 保证所有节点数据一致之后才返回给客户端，实现了顺序一致性。
2PC 把数据复制分为两步：
表决阶段：主节点将数据发送给所有副本，每个副本都要响应提交或者回滚，如果副本投票提交，那么它会将数据放到暂存区域，等待最终提交。
提交阶段：主节点收到其他副本的响应，如果副本都认为可以提交，那么就发送确认提交给所有副本让它们提交更新，数据就会从暂存区域移到永久区域。只要有一个副本返回回滚就整体回滚。可以发现 2PC 是典型的 CA 系统，为了保证一致性和可用性，2PC 一旦出现网络分区或者节点不可用就会被拒绝写操作，把系统变成只读的。由于 2PC 容易出现节点宕机导致一直阻塞的情况，所以在数据复制的场景中不常用，一般多用于分布式事务中（注：实际应用过程中会有很多优化）。
有点忙，现在接着学习吧---嘿嘿
3，目录存储
还是以 ZooKeeper 为例，注册中心存储服务信息一般采用层次化的目录结构： 每个目录在 ZooKeeper 中叫作 znode，并且其有一个唯一的路径标识。 znode 可以包含数据和子 znode。 znode 中的数据可以有多个版本，比如某一个 znode 下存有多个数据版本，那么查询这 个路径下的数据需带上版本信息。
编辑
4. 服务健康状态检测
注册中心除了要支持最基本的服务注册和服务订阅功能以外，还必须具备对服务提供者节点 的健康状态检测功能，这样才能保证注册中心里保存的服务节点都是可用的。
还是以 ZooKeeper 为例，它是基于 ZooKeeper 客户端和服务端的长连接和会话超时控制 机制，来实现服务健康状态检测的。
在 ZooKeeper 中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的 Session ID。服务端和客户端维持的是一个长连接，在 SESSION_TIMEOUT 周期内，服务 端会检测与客户端的链路是否正常，具体方式是通过客户端定时向服务端发送心跳消息 （ping 消息），服务器重置下次 SESSION_TIMEOUT 时间。如果超过 SESSION_TIMEOUT 后服务端都没有收到客户端的心跳消息，则服务端认为这个 Session就已经结束了，ZooKeeper 就会认为这个服务节点已经不可用，将会从注册中心中删除其 信息。
ZooKeeper
它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。zookeeper=文件系统+监听通知机制。
1、 文件系统
Zookeeper维护一个类似文件系统的数据结构
每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：
- PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在 - PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 - EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除 - EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
2、 监听通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
5. 服务状态变更通知
当注册中心探测到服务提供者节点有新加入或者删除的信息，会立刻通知其消费者（订阅者）作出相应的改变，订阅者则会刷新本地缓存的服务节点信息 ，从而确保请求的可用性。
Zookeeper 为例，基于Zookeeper Watcher 机制，实现服务状态变更通知给服务消费者，服务消费者在调用ZooKeeper的GetDate
