springCloud-netflix-eureka 源码解析和相关优化_springcloud netflix源码下载

版本：

'springCloudVersion', "Hoxton.SR4"
'org.springframework.boot' version '2.3.0.RELEASE'

源码解析：

@EnableEurekaServer--做了什么事

点进源码内容如下：

这里面我们只需要关注@Import(EurekaServerMarkerConfiguration.class)

发现class EurekaServerMarkerConfiguration 几乎什么都没有做只是实例化一个Marker的bean

Marker是什么，我们暂时可以理解成一个eureka-server的标记：

因为springboot的启动时默认扫描启动类同目录下，所以在eureka-server中指定了spring.factories文件,用来记录项目包外需要注册的bean类名,或者说注册项目包外的bean

 spring.factories文件内容：

 继续看 EurekaServerAutoConfiguration 中的内容

 EurekaServerAutoConfiguration配置类中我们暂时只需要关注两个地方：

.@ConditionalOnBean  和 变量EUREKA_PACKAGES

@ConditionalOnBean(EurekaServerMarkerConfiguration.Marker.class)含义:spring容器中存在指定class的示例对象时，对应的配置才生效，也就是我们之前在@EnableEurekaServer中看到的Marker内部类，容器中存在Marker实例eureka server的配置才会生效（只有满足该条件springboot才会进一步加载eureka server相关的配置）

不了解@ConditionalOnBean和个性加载的可以看下面的图片作为简单的了解

变量EUREKA_PACKAGES：指定了springboot需要扫描的Eureka服务器所需资源的包列表

所以从以上内容看我们在使用时只需要两步就可以成功的启动一个eureka server服务

1.引入 org.springframework.cloud:spring-cloud-starter-netflix-eureka-server 依赖

2.在启动类上添加注解：@EnableEurekaServer

-----------------------------启动原理 结束-----------------------------------------------未完待续--后续会添加优化和更深层次源码解析

eureka server的启动入口：

 生命周期开始启动入口start方法：

 原理解析：EurekaServerInitializerConfiguration 重写的start()方法是Spring提供的一个扩展接口--Lifecycle接口中的start方法

Spring提供的一个扩展接口--Lifecycle接口
 
 public interface Lifecycle {
  
          /**
          */生命周期开始
          void start();
  
          /**
           * 生命周期结束
          */
         void stop();
 
         /**
          * 判断当前bean是否是开始状态
          */
         boolean isRunning();
 
     }
 
start()：表示开启该对象的生命周期
 
stop()：表示结束该对象的生命周期
 
isRunning()：判断当前对象的生命周期是否时开始状态
 
从接口的方法上很好理解，主要是开始和结束当前对象的生命周期，以及判断当前对象生命周期的状态。

了解这些后我们就可以通过断点的方式一步一步的了解eureka server 在启动时都干了什么事

优化内容：

不同数据量服务的自我保护

相关配置：

 //true:开启eureka的自我保护机制  false：关闭
eureka.server.enable-self-preservation: true 
// 续约阈值，和自我保护相关
eureka.server.renewal-percent-threshold: 0.85
//server剔除过期服务的时间间隔
eureka.server.eviction-interval-timer-in-ms: 1000

你先说结论然后在看源码解析

结论：

通常同一服务数量少的情况下---不开启：服务数量少时，当触发了自我保护机制时，没有正常续约的服务如果出现不可用，容错较低，容易造成将已经下线或不可用服务暴露到服务列表中

通常同一服务数量多的情况下---开启 ：容错相对高：当出现网络抖动等情况不易触发保护机制

Eureka自我保护机制是什么？
0、某一时刻某一个微服务不能用了(如:dept8001xxx),而Eureka不会自动清除
 
依然对微服务的信息进行保存
 
1、在默认的情况系，EurekaServer在一定的时间内没有接受到微服务的实例心跳，EurekaServer将会注销该实例(默认为90秒)
 
2、但是在网络发生故障的时候,微服务于EurekaServer之间是无法通信的，这种情况就非常危险了，因为微服务本身实例是健康的，此刻本不应该注销这个微服务。那么Eureka自我保护模式就解决了这个问题了
 
3、当EurekaServer节点在短时间内丢失过客户端时(包含发生的网络故障)，那么节点就会进行自我保护
 
4、一但进入自我保护模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据不会注销任何的微服务
 
5、当网络故障恢复后，该EurekaServer节点会自动的退出自我保护机制
 
6、在自我保护模式中，EurekaServer会保护服务注册表中的信息，不在注销任何服务实例，当重新收到心跳数恢复阀值以上时，该EurekaServer节点就会自动的退出自我保护模式，这种社设计宁可保留错误的服务注册信息，也不盲目的注销删除任何可能健康的服务实例
 
7、自我保护机制就是一种对网络异常的安全保护实施，他会报错所有的微服务(健康或者不健康的微服务都会保存)
 
，而不会盲目的删除任何微服务，可以让Eureka集群更加的健壮/稳定
 
8、在EurekaServer端可取消自我保护机制不建议使用

eureka 自我保护机制源码解析：

源码具体调用流程如下思维导图：

思维导图高清图片连接：

https://download.csdn.net/download/qq_36448587/77995509https://download.csdn.net/download/qq_36448587/77995509

-----------------------未完待续-----------后续更新更多生产优化内容---- 

 eureka的快速下线配置：

//server剔除过期服务的时间间隔
eureka.server.eviction-interval-timer-in-ms: 1000

时间间隔设置小一点可以实现快速下线的配置

快速下线源码解析：

 如上源码中代码所示，实际上我们配置的“eureka.server.eviction-interval-timer-in-ms”这个配置是配置了剔除任务的触发时间

任务调度api如下：

Schedules the specified task for repeated fixed-delay execution, beginning after the specified delay. Subsequent executions take place at approximately regular intervals separated by the specified period.
In fixed-delay execution, each execution is scheduled relative to the actual execution time of the previous execution. If an execution is delayed for any reason (such as garbage collection or other background activity), subsequent executions will be delayed as well. In the long run, the frequency of execution will generally be slightly lower than the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate).
Fixed-delay execution is appropriate for recurring activities that require "smoothness." In other words, it is appropriate for activities where it is more important to keep the frequency accurate in the short run than in the long run. This includes most animation tasks, such as blinking a cursor at regular intervals. It also includes tasks wherein regular activity is performed in response to human input, such as automatically repeating a character as long as a key is held down.
Params:
task – task to be scheduled.
delay – delay in milliseconds before task is to be executed.
period – time in milliseconds between successive task executions.
Throws:
IllegalArgumentException – if delay < 0, or delay + System.currentTimeMillis() < 0, or period <= 0
IllegalStateException – if task was already scheduled or cancelled, timer was cancelled, or timer thread terminated.
NullPointerException – if task is null
 
/*
*调度指定的任务重复执行固定延迟，从指定的延迟之后开始。随后的执行大约以规则的间隔进行，间隔为指定的周期。
*/
 
public void schedule(TimerTask task, long delay, long period) {
        if (delay < 0)
            throw new IllegalArgumentException("Negative delay.");
        if (period <= 0)
            throw new IllegalArgumentException("Non-positive period.");
        sched(task, System.currentTimeMillis()+delay, -period);
    }

---------------eureka 三级缓存-------------------

eureka 三级缓存原理和相关优化：

三级缓存是什么：

一级缓存（注册表）ConcurrentHashMap
二级缓存（ReadWriteMap）guava#LoadingCache
三级缓存（ReadOnlyMap）ConcurrentHashMap

优化内容：

# 是否开启readOnly读缓存
use-read-only-response-cache: true

eureka寻找一个服务

是从三级缓存中找，如果有则返回，如果没有则去二级缓存拿并更新，如果二级缓存已经失效，触发guava的回调函数从注册表中同步。

配置是否开启三级缓存，eureka默认是开启的，（默认开启的好处是什么：可以避免读写冲突，保证高并发环境下的可用性），如果关闭readOnly读缓存，可以实现更快速的读取服务列表

结论：

如果业务需要增加读取服务列表的速度，可以将readOnly读缓存的配置设置为false

引入cap概念：

CAP原则又称CAP定理，指的是在一个分布式系统中，
一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
 
​

实际上eureka  实现的是ap(可用性（Availability）、分区容错性（Partition tolerance）)，优先保证可用性

接下来了解一下eureka是如何实现三级缓存的读操作：

 源码展示：