在Eureka-Server启动的时候，会启动一个定时任务，用来清理过期的客户端
renewsLastMin.start() ： 在每个Eureka-Server端都维护着，每分钟的续约数量，续约数量是有一个Long类型的变量
来存储的，每过一分钟就需要对这个变量进行清0 ， 因此这个地方是为了启动这个线程
是用来清理过期客户端的任务类
serverConfig.getEvictionIntervalTimerInMs() ： 默认为60秒 , 可配置。
//判断是否过期
// 续约的时候会调用，用来更新最后更新时间
duration ： 过期间隔，默认为90秒
evictionTimestamp ： 实例下线时间，当客户端下线时，会更新这个时间。
lastUpdateTimestamp ： 为最后更新时间 ， 这里有个错误，因为续约的时候，更新这个时间的时候，加上了duration ， 但是在最终做判断的时候
lastUpdateTimestamp + duration + additionalLeaseMs ， 这个地方还加了一遍，也就导致了，当前时间必须要大于实际最后更新时间180秒，才会认为他过期 （撇开additionalLeaseMs这个因素不谈）
从上面可以得知 , 这里有个分批过期的概念，每次最多过期15%的机器，超过15%则不会自动过期
假如检测到过期的实例数量为4台 ， 总数量为10
执行过程过下：
第一个60秒到来，执行任务
也就说仅仅只可以过期两台，那么另外两台怎么办，只能等待下一次任务执行的时候
第二个60秒到来，执行任务 ， 计算是否开启保护机制时，这个时候呢，
numberOfRenewsPerMinThreshold还是原来的值，也就是 10 2 0.85 = 17 , 但是由于
存活的机器数量只有6台，则每秒最大续约数为12 ， 12>17 = false , 所以会开启自动保护机制
（如果在一分钟之类，另外两台机器恢复了心跳，16>17 ， 依旧会开启），只能等待15分钟
之后，定时任务重新计算这两个参数的值。
开启自我保护机制之后，则不会继续往下执行了。。
总结： 由上可知，客户端具体的过期时间，是不确定的，但是必须大于180秒， 如果加上定时任务的时间间隔，240秒，
如果第一轮任务执行不到的话，可能会等到第二轮的时候执行，但是如果开启了自我保护机制，则没有第二轮的说法了。
如果不想启用这种机制，那么可以关闭自我保护机制，同时设置registrySizeThreshold = 0； 就可以一次性过期。