注册中心
功能:服务发现、服务配置、健康检测
- 检测节点集群状态,把拉的方式改成推的方式
- 集成Ribbon实现负载均衡
- 节点管理
服务注册中心架构演进
https://www.jianshu.com/p/5014bb302c7d
总体架构
- 服务调用: client 直连 server 调用服务
- 服务注册: 服务端将服务的信息注册到 consul 里
- 服务发现: 客户端从 consul 里发现服务信息,主要是服务的地址
- 健康检查: consul 检查服务器的健康状态
ZooKeeper和Eureka比较
CAP定理
https://blog.csdn.net/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