注册中心学习

注册中心

功能：服务发现、服务配置、健康检测

• 检测节点集群状态，把拉的方式改成推的方式
• 集成Ribbon实现负载均衡
• 节点管理

服务注册中心架构演进

https://www.jianshu.com/p/5014bb302c7d

总体架构

• 服务调用: client 直连 server 调用服务
• 服务注册: 服务端将服务的信息注册到 consul 里
• 服务发现: 客户端从 consul 里发现服务信息，主要是服务的地址
• 健康检查: consul 检查服务器的健康状态

ZooKeeper和Eureka比较

CAP定理

https://blog.youkuaiyun.com/zhangyufeijiangxi/article/details/78286364

• P(分区容忍性)（Partition tolerance）
  不是分区容错性 ，在实际应用中指的是集群架构和数据支持动态横向扩展。
• 一致性（Consistency）
  读操作总是能读取到之前完成的写操作结果，满足这个条件的系统称为强一致系统，这里的“之前”一般对同一个客户端而言；
• 可用性（Available）
  读写操作在单台机器发生故障的情况下仍然能够正常执行，而不需要等待发生故障的机器重启或者其上的服务迁移到其他机器
  这三个特性在任何分布式系统中不能同时满足，最多同时满足两个

Zookeeper是基于CP来设计的，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。
Eureka时遵守的就是AP原则

在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。但是对于服务发现场景来说，情况就不太一样了：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

ZooKeeper基于CP，不保证高可用（选举期间整个zk集群都是不可用），如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。

所以理论上Eureka是更适合作注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题
https://www.cnblogs.com/jieqing/p/8394001.html