注册中心 eureka、nacos、consul、zookeeper、redis对比
这篇文章资料来自于网络，是对部分知识整理，这里只是记录一下，仅供参考
1、前言
服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
2、CAP理论
CAP理论是分布式架构中重要理论
- 一致性(Consistency) (所有节点在同一时间具有相同的数据)
- 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
- 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
关于
P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，
而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都取，只能取其中2个
原因是
如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。
如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。
再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了
3、服务注册中心解决方案
设计或者选型一个服务注册中心，首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案，大致可归为三类：
- 应用内：直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka
- 应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
- DNS：将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表
注1：对于第一类注册方式，除了Eureka这种一站式解决方案，还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制，这在大公司比较常见，但对于小公司而言显然性价比太低。
注2：由于DNS固有的缓存缺陷，本文不对第三类注册方式作深入探讨。
除了基本的服务注册与发现机制，从开发和运维角度，至少还要考虑如下五个方面：
- 测活：服务注册之后，如何对服务进行测活以保证服务的可用性？
- 负载均衡：当存在多个服务提供者时，如何均衡各个提供者的负载？
- 集成：在服务提供端或者调用端，如何集成注册中心？
- 运行时依赖：引入注册中心之后，对应用的运行时环境有何影响？
- 可用性：如何保证注册中心本身的可用性，特别是消除单点故障？
4、参考链接
eureka、nacos、consul、zookeeper
https://blog.51cto.com/smallfa/5648994
https://zhuanlan.zhihu.com/p/654413569
https://cloud.baidu.com/article/2695862
https://www.cnblogs.com/rgqancy/p/14954064.html
https://segmentfault.com/q/1010000045179472
https://blog.csdn.net/fly910905/article/details/100023415
https://developer.baidu.com/article/details/2818190
eureka详解
https://juejin.cn/post/7322356470253944851
https://zhuanlan.zhihu.com/p/654413569
https://www.cnblogs.com/wenxuehai/p/16168076.html
https://juejin.cn/post/7264043620842635323