• 当调用eureka client的shutdown方法时，会走服务下线流程。（这个shutdown方法会在Spring Cloud Netflix中spring上下文关闭时调用）
  • 触发下线监听器
  • 停止调度任务（心跳、拉取注册表）
  • 调用eureka server的 DELETA /v2/apps/APP_NAME/服务实例ID 接口
  • 释放一系列jersey client的网络资源
  • 注销监控
    • 心跳监控
    • 注册表监控

当eureka client启动时，会有一个定时任务每隔30秒向eureka server发送心跳 心跳会将服务实例信息带上 请求的eureka server的 PUT /v2/apps/APP_NAME/服务实例ID 根据响应做如下处理 如果返回状态码为404说明eureka server没有这个服务实例，此时会走服务注册流程 如果返回状态码20...

• eureka client启动后，每隔30秒会有一个定时任务抓取增量注册表

  • 请求的eureka server的 GET v2/apps/delta 接口
  • 会根据返回的服务实例的类型，比如新增、修改、删除来分别处理
    • 新增、修改 直接添加到本地注册表（添加操作实际上是幂等的，会先删除，再添加）
    • 删除 直接从本地注册表删除

注册表多级缓存（就是那个ResponseCache）的原理如下：

• 第一级缓存 readOnlyCacheMap，所有的读请求都会先走这一层
• 第二级缓存是一个基于Guava Cache的 readWriteCacheMap 当第一层获取不到数据时，会走这一层
  • 数据加载 将自己的本地注册表数据以key为ALL_APPS填充到第二级缓存中去

Eureka Client首次抓取是在启动时进行的 通过eurekaTransport.queryClient这个jersey客户端,请求eureka server的 GET /v2/apps/APP_NAME 接口 拿到响应的Applications后会将顺序打乱，然后存到本地 eureka server的ApplicationsResource.ge...

Eureka Client启动流程

Eureka Server模块分析

1、Eureka Server原来是一个简单的Servlet应用

源码阅读环境搭建

• ide：IntelliJ IDEA
• 包管理：gradle
• eureka版本：1.9.13
• 源码下载：https://github.com/Netflix/eureka/archive/refs/tags/v1.9.13.zip

Eureka解决了什么问题

这个问题本质是问服务注册中心的价值。很多年前，那个时候微服务还没有兴起，大家用Nginx+Tomcat就搞定了，加机器加Tomcat时候，直接在线改Nginx配置就搞定，这叫手动服务注册。但是在现今的微服务架构中，服务可能动不动就几十个，上百个，算上冗余就几百个，而且微服务的发布很频繁，不断有新的服务加入进来；在应对大流量场景时，还需要扩容缩容。这如果还依靠Nginx那种原始的手工配置方式，是不可行的，成本太高了。所以，就出现了服务注册发现，即服务实例自己会在启动后注册到服务注册中心，这叫服务注册，然后每个服务实例又从服务注册中心拉取服务注册表，动态的感知到服务的上下线，这叫服务发现。所以，服务注册中心这种技术是在微服务架构中自然而然就过渡过来的，并不突兀。eureka作为Netflix全家桶中的服务注册中心实现，其意义也就不言自明了。

为什么写？

时下Spring Cloud Netflix全家桶已经成为了事实上的微服务实践落地的不二选择，笔者在公司也负责、参与一系列的微服务改造项目，该系列文章涵盖了笔者从刚接触该技术栈的入门到实战，再到源码分析的整个过程，是对自己经历的一次梳理，希望对您也有所帮助。