Spring Cloud Netflix Eureka对eureka原生项目做了一点儿轻量级的封装。
Eureka
2020-03-28
2020-03-25
- eureka 客户端会在启动时,从eureka server抓取全量注册表到本地
2020-03-18
- 什么是eureka集群?
一组互相复制数据,完全对等的eureka节点。通过配置文件指定,也可以热刷新(扩容缩容)
2020-03-09
- 自我保护机制是什么?
在eureka server中,他假定正常情况下肯定有大于85%的服务实例能够保持正常的心跳,最近1分钟内少于85%的服务实例心跳成功,eureka开发团队认为,此时大概率是eureka server自己的网络故障了,此时再进行过期实例剔除都会是误伤,于是就不再对故障实例剔除。这就叫进入了自我保护机制。
2020-03-03
- 故障感知和摘除指的是什么?
正常下线,会通过eureka client的shutdown方法进行,走下线流程。
当因为一些原因,没有通过正常下线的方式,服务实例却下线了,这种异常情况,成为故障。
感知,eureka server会通过定时检查多久没心跳了,感知到这种故障服务实例,并自动从注册表中把这个服务实例摘除。
2020-02-25
- 当调用eureka client的shutdown方法时,会走服务下线流程。(这个shutdown方法会在Spring Cloud Netflix中spring上下文关闭时调用)
- 触发下线监听器
- 停止调度任务(心跳、拉取注册表)
- 调用eureka server的 DELETA /v2/apps/APP_NAME/服务实例ID 接口
- 释放一系列jersey client的网络资源
- 注销监控
- 心跳监控
- 注册表监控
2020-02-18
- 当eureka client启动时,会有一个定时任务每隔30秒向eureka server发送心跳
- 心跳会将服务实例信息带上
- 请求的eureka server的 PUT /v2/apps/APP_NAME/服务实例ID
- 根据响应做如下处理
- 如果返回状态码为404
说明eureka server没有这个服务实例,此时会走服务注册流程 - 如果返回状态码200,说明心跳成功了,会更新本地的最近一次成功心跳时间戳
- 如果返回状态码为404
2020-02-16
eureka client启动后,每隔30秒会有一个定时任务抓取增量注册表
- 请求的eureka server的 GET v2/apps/delta 接口
- 会根据返回的服务实例的类型,比如新增、修改、删除来分别处理
- 新增、修改 直接添加到本地注册表(添加操作实际上是幂等的,会先删除,再添加)
- 删除 直接从本地注册表删除
2020-02-08
注册表多级缓存(就是那个ResponseCache)的原理如下:
- 第一级缓存 readOnlyCacheMap,所有的读请求都会先走这一层
- 第二级缓存是一个基于Guava Cache的 readWriteCacheMap 当第一层获取不到数据时,会走这一层
- 数据加载 将自己的本地注册表数据以key为ALL_APPS填充到第二级缓存中去
2020-02-03
- Eureka Client首次抓取是在启动时进行的
- 通过eurekaTransport.queryClient这个jersey客户端,请求eureka server的 GET /v2/apps/APP_NAME 接口
- 拿到响应的Applications后会将顺序打乱,然后存到本地
eureka server的ApplicationsResource.getContainers方法会收到请求
从响应缓存中把key为ALL_APPS的数据数据返回给客户端