水滴石穿,点滴记忆,记忆点滴。
第一次接触Eureka还是在2017年,那时候SpringBoot的版本还很早,很多依赖需要自己去匹配版本,SpringBoot的全家桶还不是很完整,也学着例子自己包装过Springboot的启动器,这东西日渐成熟,转身回顾,发现对Eureka还是一直半解,罢了罢了。
自我理解的Eureka
- 一个客户端发现型的中心;
- 与Zookeeper、Consul不同的是,他高可用高于强一致性;
- 实战中,搞两个Eureka做中心服务,内存可以稍微极限压缩一下,200MB就好,在往下压内存不足就是GC频率加快,这里的GC说的是Full GC。结果就是很吃CPU,随时可崩。
- Eureka内部缓存架构
内部分多层缓存,这样的架构设计主要是为了避免读写冲突。
- Eureka服务端收到来自Client服务实例的注册,会将注册实例列表缓存,也就是保存到上图的(register)和读写缓存(readWriteCacheMap)里面,这里Eureka服务会在内部进行定时,每隔30秒从读写缓存中将数据更新到只读缓存中(readOnlyCacheMap)。
- 其他的Client获取服务实例列表时,Eureka服务是从这个readOnlyCacheMap中去读数据的。
上面还提到了Guava,这个是google的一个开源工具库,目前测评有很多,性能比apache common包强。
注册
- 无论是Eureka服务亦或者是其他消费端服务端,这里配置Eureka的地址是可以用逗号进行分割的,通常会有三个Eureka服务器,也就是逗号分割两次,配置三个地址;
- 如果配置了三个Eureka服务地址,是否会存在重复注册?答案是不会,第一个注册成功后,后面的两个地址是不进行注册的;
- 注册时间默认30秒,三个周期的反馈时间;
保护模式
简单说就是当一个Eureka服务超过90秒没有收到一个客户端的心跳,这个客户端将被注销掉。如果网络出问题了,客户端与eureka服务无法正常通信了,这个时候eureka服务不会执行注销,原因他觉得服务本身应该还OK,只是全部失联了,他会进入保护模式,这时候,他不会将自身数据同步给其他eureka服务,另外如果有客户端连接并尝试获取信息,他也会把注册信息返回,简单说:我这不行,但是你可以去别的地方试试,在简化一点就是,你拿存折去银行,银行网点说我跟总行或者其他行失联了,我这去不了钱,我告诉你其他网点,你自己去碰运气吧。
这点就很有意思了,如果换成CP的Zookeeper,那就是你拿卡去提款机取钱,取款机连不上网了,这时候卡都不还你,让你在那等着,连上了在给你操作。
补充一句,上面讲的保护模式还有一个条件,并不是说90秒没有收到客户端的心跳,就进入保护模式,而是自身注册的客户端在15min内超过85%没有正常心跳才会进入。