springcloud四个注册中心的比较
一、概述
springcloud是一个非常优秀的微服务框架，要管理众多的服务，就需要对这些服务进行治理，也就是我们说的服务治理,服务治理的作用就是在传统的rpc远程调用框架中，管理每个服务与每个服务之间的依赖关系，可以实现服务调用、负载均衡、服务容错、以及服务的注册与发现。
? 如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的服务发现。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的服务注册中心，而存储到载体的动作即是服务注册。
? springcloud支持的注册中心有Eureka、Zookeeper、Consul、Nacos
| 组件名称 | 所属公司 | 组件简介 |
|---|---|---|
| Eureka | Netflix | springcloud最早的注册中心，目前已经进入停更进维了 |
| Zookeeper | Apache | zookeeper是一个分布式协调工具，可以实现注册中心功能 |
| Consul | Hashicorp | Consul 简化了分布式环境中的服务的注册和发现流程，通过 HTTP 或者 DNS 接口发现。支持外部 SaaS 提供者等。 |
| Nacos | Alibaba | Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 |
二、功能异同
这四个组件虽然都实现了注册中心的功能，但是他们的功能和实现方式都有不同的地方，也各有各的优点,单从注册中心方面来比价四个注册中心(如果不了解CAP定理可先阅读下一章节):
2.1 基本实现不同
| 组件名称 | 实现语言 | CAP | 健康检查 |
|---|---|---|---|
| Eureka | Java |
AP | 可配 |
| Zookeeper | Java |
CP | 支持 |
| Consul | Golang |
CP | 支持 |
| Nacos | Java |
AP | 支持 |
eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。
2.2 功能支持度不同
| Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
|---|---|---|---|---|---|
| 一致性协议 | CP+AP | AP | CP | — | CP |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
| 负载均衡策略 | 权重/metadata/Selector | Ribbon | Fabio | RoundRobin | — |
| 雪崩保护 | 有 | 有 | 无 | 无 | 无 |
| 自动注销实例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
| 监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注册中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
三、CAP定理
cap定理
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。参考 阮一峰博客。
Consistency 一致性:所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）Availability 可用性:在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）Partition Tolerance 容错性:以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的
CAP定理关注的粒度是数据，而不是整体的架构。
例如，根据CAP定理将NoSql数据分成了满足CA原则、满足CP原则和满足AP原则的三大类:
CA-单点集群，满足一致性可用性的系统，扩展能力不强CP-满足一致性和容错性系统，性能不高AP-满足可用性、容错性的系统，对一致性要求低一些。
四、参考文档
-
注册中心ZooKeeper、Eureka、Consul 、Nacos对比 https://blog.csdn.net/fly910905/article/details/100023415
-
阮一峰 cap定理 http://www.ruanyifeng.com/blog/2018/07/cap.html
作者：Martain
链接：https://www.jianshu.com/p/9b8a746e0d90
来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。