前言
目前分布式主流环境下，注册中心也是分布式下重要的一环。
为什么需要注册中心
分布式，在单机下所能够处理的流量有限 ，所以使用多个机器来均摊流量。那么多个机器相互调用的情况下，每次服务的上线下线，都需要重启其他的服务，这样的开销实在是很大。
因此我们引入一个中间层，注册中心。当有了注册中心后，将所有的服务解耦，当一个服务下线或上线时，我们不需要重启其他服务，只需要向注册中心注册自己即可。
服务注册与发现原理
服务注册与发现的原理简单的说，就是将服务放到第三方管理。当有服务提供者上线，则会将自己的ip:port以及权重等等信息，放到注册中心当中。
而当服务消费者需要调用服务时，会通过注册中心，来找到服务地址，并且服务消费者会缓存这些信息。当服务发生变更时，注册中心如果得不到服务提供者的心跳，那么则会将该服务下线。并且将该服务变更通知到订阅者处。
CAP理论
通过上面的描述，相信你大致了解了服务注册与发现的原理，不过你有没有想过一个问题，注册中心的单点故障该如何处理。
那么此时就是一个经典的注册中心集群的选型问题。这里我们先了解一下CAP理论
C：Consistency 一致性
具体而言，每次读操作，要么读到最新，要么读失败，这要求整个分布式系统像是一个不可拆分的整体，写操作作用于集群就相当与作用于单机一样，具有广义的 "原子性"
A：Availablity 可用性
可用性强调：站在使用者的角度，强调使用服务的体验，客户端的请求能够得到响应，不发生错误，也不用出现过长的等待时间。
P：Partition Tolerance 分区容错性
强调的是，在网络环境不可靠的背景下，整个系统仍然是正常运作的，不至于出现系统崩溃或者秩序混乱的局面。
CAP理论强调的是一个系统中，C、A、P 三项最多只能满足其中两项，即每个系统依据其架构设计，会具有CP、AP或者CA的倾向。对于单机项目而言，不存在P，因此可满足CA。对于分布式系统而言，P就必须满足，否则就违背了"分布式"语义。
- CP：强调系统数据的正确性，但由于建立保证不同节点间保证严格数据一致性的机制，可能会牺牲系统的可用性。
- AP：强调系统的可用性，那就必须在数据一致性上作出妥协退让。
分布式系统中，C和A之间的矛盾正是由于网络环境的不稳定。
常见的注册中心介绍
这里介绍常见的几款注册中心。我个人认为学习注册中心最重要的两点，注册模式和一致性选择。这里我想介绍三款比较熟悉注册中心：Zookeeper、Nacos、Eureka
Zookeeper
Zookeeper注册中心，在很多地方都有它的身影，例如在大数据处理中Zookeeper与Kafka，Dubbo服务注册发现中等等。我们先来看一下Zookeeper的数据结构
数据存储
数据的存储类似树一样。
一致性选择
Zookeeper实现了自己的协议，ZAB协议。该协议实现的是CP，也就是强一致性 服务。如果在选主 的过程中，以及在半数节点都挂掉时，那么注册发现服务不能使用。
Eureka
Eureka注册中心则是SpringCloud微服务治理生态中的。我估计大家第一个接触的注册中心是这个。但Eureka 2.0的开源服务已经宣告已经停止了。
注册模式
Eureka采用的是Server 与 Client模式进行设计的。Server充当了注册中心的角色，为Client提供了服务注册与发现的功能。各个服务之间会通过注册中心的注册信息来实现调用
Eureka Client通过在服务提供者的代码中使用注解，在服务启动时，扫描到这些注解的服务将会向客户端进行注册暴露。此外，该服务还会周期性的发送心跳，检测服务是否更新。
如果在一段时间内连续多次心跳不能发现该服务存活，那么 Eureka Server 就会将这个服务节点从服务注册表中移除。
一致性选择
Eureka支持的是AP模式，只要节点还有一个存在，那么服务依旧可以使用。不过，会存在短暂的数据不一致的情况。
Nacos
Nacos 是阿里巴巴推出来的一个开源项目，提供了服务注册和发现功能，使用 Nacos 可以方便地集成 Spring Cloud 框架。如果正在使用 Eureka 或者 Consul，可以通过少量的代码就能迁移到 Nacos 上。 Nacos还可以当做分布式配置中心。
注册模式
Nacos 的应用和 Eureka 类似，独立于系统架构，需要部署 Nacos Server。除了服务注册和发现之外，Nacos 还提供了配置管理、元数据管理和流量管理等功能，并且提供了一个可视化的控制台管理界面。
一致性选择
Spring Cloud Nacos 在 1.0.0 版本正式支持 AP 和 CP 两种一致性协议，可以动态切换。
- 如果注册Nacos的client节点注册时
ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现； - 注册Nacos的client节点注册时
ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。
关于上述两种协议，这里不再深究，感兴趣大家可以去查一查学习一下。
总结
本文主要总结了常见的三个注册中心组件Zookeeper、Eureka、Nacos以及它们的一致性选择问题。
- 在分布式环境下，注册中心是很有必要的。
- 注册中心的简单原理是将节点信息放到一个中间层去，这样可以做到服务的快速变更。
- CAP理论告诉我们，需要在CA、AP之间做取舍，这也是需要看业务。
对于服务注册和发现的场景来看，个人认为，可用性比数据一致性更加重要。
针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不相同，会出现部分提供者地址不存在等，不会导致严重的服务不可用。
对于服务消费者来说，能消费才是最重要的，拿到可能不正确的服务实例信息后尝试消费，也要比因为无法获取实例信息而拒绝服务好。