1、注册中心概念和定义
对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现。服务注册中心本质上是为了解耦服务提供者和服务消费者，能够提供额外服务来管理微服务提供者的注册与发现的组件。
2、注册中心主要有三种角色
- 服务提供者 (RPC Server) : 在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
- 服务消费者 (RPC client) : 在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。
- 服务注册中心(Registry) : 用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。
3、分布式架构中重要理论CAP定理
- C代表 一致性(Consistency)：所有节点在同一时间具有相同的数据。
- A代表可用性(Availability) ：保证每个请求不管成功或者失败都有响应(某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求) 。
- P代表分区容错性(Partition tolerance)：系统中任意信息的丢失或失败不会影响系统的继续运作(在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用)。
CAP不可能都满足，原因如下:
- 如果C是第一需求的话，那么会影响A的性能。因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，可用性就会降低。
- 如果A是第一需求，那么只要有一个服务在，就能正常接受请求。但是对于返回结果便不能保证，原因是，在分布式部署的时候，数据一致的过程不可能像切线路那么快。
- 如果同时满足一致性和可用性，那么分区容错就很难保证了。 但是CAP理论提出就是针对分布式数据库环境的，所以P这个属性是必须具备的。P就是在分布式环境中，由于网络的问题可能导致某个节点和其它节点失去联系，这时候就形成了P(partition)。
4、常见的注册中心对比（组件特性并非一成不变，如果发现功能特性有变更，欢迎评论指正）
|
Nacos |
Eureka |
Consul |
Zookeeper |
|
|
CAP定理 |
AP/CP |
AP |
CP |
CP |
|
访问协议 |
HTTP/DNS |
HTTP |
HTTP/DNS |
TCP |
|
健康检查 |
TCP/HTTP/MYSQL/Client Beat |
Client Beat |
TCP/HTTP/gRPC/Cmd |
Keep Alive |
|
负载均衡 |
权重/metadata/Selector |
Ribbon |
Fabio |
— |
|
雪崩保护 |
有 |
有 |
无 |
无 |
|
安全 |
acl |
— |
acl /https |
acl |
|
自身监控 |
— |
metrics |
metrics |
— |
|
多数据中心 |
支持 |
— |
支持 |
— |
|
kv存储服务 |
支持 |
— |
支持 |
支持 |
|
一致性 |
Raft |
— |
Raft |
Paxos |
|
自动注销实例 |
支持 |
支持 |
支持 |
支持 |
|
监听支持 |
支持 |
支持 |
支持 |
支持 |
|
跨注册中心同步 |
支持 |
不支持 |
支持 |
不支持 |
|
SpringCloud集成 |
支持 |
支持 |
支持 |
支持 |
|
Dubbo集成 |
支持 |
不支持 |
支持 |
支持 |
|
K8S集成 |
支持 |
不支持 |
支持 |
不支持 |
5、常见注册中心的优劣（组件特性并非一成不变，如果发现功能特性有变更，欢迎评论指正）
|
注册中心 |
优点 |
缺点 |
选型建议 |
|
Zookeeper |
1、数据存在内存中，采用nio和多线程模型 2、性能较其他CP服务器较高
|
1、不能保证服务可用性，作为注册中心，可用性的要求要高于一致性。 2、从 CP 模型上来讲，zookeeper 并不适合注册中心高可用的需要。 3、从性能上来讲，zookeeper 也无法满足注册中心大规模且频繁注册写的场景。 |
1、分布式数据存储 2、RPC服务框架 3、 |
|
Eureka |
1、注册中心、提供者、调用者边界清晰 2、通过去中心化的集群支持保证了注册中心的整体可用性 |
属于应用内的注册方式，对应用的侵入性太强，且只支持Java应用。
|
1、用Spring Cloud原生全家桶 2、用本地文件和Git作为配置管理的,将配置与服务分开管理 3、考虑短期的稳定性
|
|
Consul |
1、最小化对已有应用的侵入性 2、降低运维的复杂度(Consul Agent既可以运行在服务器模式，又可以运行在客户端模式)
|
在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
|
1、运行状态发现2、动态负载均衡 3、与Kubernetes集成和扩展 4、安全的多云服务网络
|
|
Nacos |
1、可以根据服务注册选择临时和永久来决定走AP模式还是CP模式 2、同时支持注册中心和配置中心
|
1、学习成本较高，需要掌握一定的分布式系统和网络知识。 2、部署和维护成本较高，需要投入一定的人力和物力。 3、对于小型项目来说，使用 Nacos 可能会过于复杂，不太适合初学者使用。
|
1、在线对服务进行上下线和流量管理 2、不采用MQ实现配置中心动态刷新 3、不新增配置中心生产集群 4、考虑引入Spring Cloud Alibaba生态 |
