eureka相关的教程网上已经很多了，大家可以查询一下随便看看即可，我这里着重讲一下eureka中的三级缓存，并说一下基于eureka注册中心做的平滑上线的方案；
Eureka server端及client端交互流程eureka注册中心的作用主要是作为管理各个微服务通信状态的媒介，各个微服务启动后将自己的信息登记到注册中心，并每隔一段时间进行一次心跳续约，表名自己还活着，而注册中心不仅要管理好这些注册上来的微服务信息，同时还负责将这些注册信息定期同步给各个微服务，这样各个微服务在调用其他微服务时则不用再来注册中拉取服务列表了，直接中自己本地选择一个调用即可，省时高效；
Eureka三级缓存 eureka上述交互主要是依赖这里的三层缓存进行的，而这三层缓存指的是与微服务客户端进行交互时，三个维护微服务注册列表缓存，三层缓存交互逻辑：
eureka server端维护了两个map，
其一是com.netflix.eureka.registry.ResponseCacheImpl#readWriteCacheMap，它主要负责负责实时更新注册上来的微服务列表，更新频率由client端决定（client端通过renew续约参数配置控制，默认是30s，client端心跳过期时间是默认是90s），驱逐不可用服务（默认是将60s没有续约成功的服务剔除掉）；其二是com.netflix.eureka.registry.ResponseCacheImpl#readOnlyCacheMap，它主要负责与client端进行交互，client通过就是从这个map中拉取注册列表的；而它里面的服务注册信息是从readWriteCacheMap同步过来的，这里的时间间隔是30s； Eureka自我保护
上述三层缓存中提到，eureka server端会将没有及时续约的微服务从注册列表中剔除掉，那如果说有一段时间网络不稳定，就是没有续约成功，那岂不是无辜剔除了一个好的服务；这种问题eureka已经替我们想到了，eureka自带自我保护功能（也可以关闭，但是不建议关闭）；
触发时机：如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制
触发后的表现缺点1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2。Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
Eureka假如一直带着这种自我保护机制，我们不能将为了不错杀一个好人，就放着坏人也置之不理吧。如果在保护期间某个微服务刚好非正常下线了，此时服务消费者就会拿到一个无效的服务实例，此时就会发生调用失败的情况，对于这个问题springcloud也是给我们提供了一下解决方案，后面会有负载均衡的重试机制、hystrix的服务熔断，这里主要讲一下平滑上线的方案；
平滑上线 平滑上线的必要性eureka的三级缓存以及自我保护功能，并不会及时将已经下线的实例服务进行剔除，导致网关仍然会路由那些不可用状态的服务，如果我们的业务是一些容错率比较低的服务，那么就需要要使用平滑上线了
平滑上线解决方案这里提供的解决方案主要是依据三层缓存的原理，将微服务先将client端进行renew的操作终止掉，再等待其他客户端拉取的最新的服务列表中不包含将要下线的微服务，这时即可进行下线操作，重启的时候，正常启动后会重新注册上来；具体方案如下：
在服务stop脚本中调用EurekaClient.shutdown让微服务停止renew停止renew成功后，执行睡眠90s再执行停止服务的kill操作；