• 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.getContainers方法会收到请求

• 从响应缓存中把key为ALL_APPS的数据数据返回给客户端

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

起因

经常看各类 javadoc 发现有一类 doc 并没有被做成标准的 doc 格式，直接复制出来想翻译一下，需要做一些预处理，比如删除注释、合并断行，前者各种编辑器的列模式搞定，后者就坑爹了，之前是手工一行一行的删除换行符，然后加空格的，非常坑爹。对于这类重复性操作，使用 vim 的宏录制就再好不过了。