Eureka 是为微服务提供服务注册和发现的产品（）

落花踏尽游何处，笑入胡姬酒肆中。这篇文章主要讲述Eureka 是为微服务提供服务注册和发现的产品？相关的知识，希望能为你提供帮助。

Eureka
1、Eureka 是为微服务提供服务注册和发现的产品
2、为什么要用eureka
多个服务间，如订单中心调用库存中心，如果没有eureka，那订单中心就要写死一个URL来访问库存中心接口。这期间，如果商品中心又加了一台机器呢？那订单中心岂不是要加一个URL然后轮询去调用，所以才会用eureka提供服务注册和发现
3、使用场景

文章图片

4、Eureka有两类
一类是 eureka-server ，一类是 eureka-client ，eureka-server是单独一个服务，专门用来发现其它服务的，可通过浏览器访问。eureka-client其实就是项目中拆分出来的每个服务，需要被eureka-server发现的
5、Eureka-server集群，eureka这么重要的服务注册中心，不可能是单点的，如果挂了就完蛋了
6、Eureka-server初始化的过程

文章图片

首先 erueka-server启动时会读取eureka-server.properties配置文件，初始化eureka-server的运行环境
然后会读取eureka-client.properties配置文件，构造服务实例信息。eureka-server初始化也要读取eureka-client配置文件的原因是，eureka-server把自己本身也当成了一个服务实例，因为要组成eureka-server集群，它也要向其他的eureka-server去注册
构造一个registry，eureka-server的注册表，其它服务过来注册的注册信息都放在这里
然后构造一个eureka-server的集群信息，叫peerEurekaNode，负责委会eureka-server的集群信息
然后基于上面4个组件，构造出一个eurekaServerContext，eureka-server的上下文
然后这个eureka-server就会从其他几点拷贝注册表
将自己作为一个服务实例，注册到其他eureka-server
这就是eureka-server初始化的过程

7、eureka-client初始化

文章图片

首先从eureka-client.properties 中读取服务实例的配置
根据读取到的配置信息构造服务实例信息InstanceInfo
然后初始化网络通信组件 EurekaTransport(给eureka-server发送请求用的)
去eureka-server抓取全量注册表
然后启动2个定时任务
2. 每隔30s抓取一次增量注册表
3. 每隔30s给eureka-server发送心跳
最后把自己注册到eureka-server上

8、eureka-client 增量抓取注册表

文章图片

eureka-client每隔30s向eureka-server拉去一次增量注册表
eureka-server返回两部分数据，增量注册表和全量初测表的hash值
通过对比本地hash值判断自己的注册表是否是最新的
如果不是最新的，就重新全量获取注册表

9、eureka-server注册表的多级缓存机制

文章图片

前面不是说 eureka-client每隔30s发送一次心跳给eureka-server么，并且每隔30s会抓取一次增量注册表
然后，其实eureka-server内部在给eureka-client注册表时，是有一个多级缓存机制的，一共三层，registry、ReadWriteCacheMap、ReadOnlyCacheMap （画图）
然后这个registry，会接收来自eureka-client发送的心跳。当eureka-client3次心跳未发送，那registry就会认为这个节点挂了。然后每隔60s会清理一次这些挂了的服务
当registry 清理挂了的节点后，会实时同步到ReadWriteCacheMap中
ReadWriteCacheMap缓存的过期时间为180s，过期后从registry拉去全量注册表
ReadWriteCacheMap每隔30s会向ReadOnlyCacheMap同步数据
所以，当一个服务非正常下线，系统最多要经过240s才能发现这个服务挂了 90 + 60 + 30 + 30 + 30（ribbon）
如何避免这种情况
2. kill服务的时候，使用kill - 15 让服务释放资源，别用-9
3. 设置可以直接从ReadWriteCacheMap中读取
4. 设置readOnlyCacheMap的同步时间
5. 设置清理未续约节点的时间
6. 设置心跳的间隔
为什么要用缓存，猜测
1. 因为eureka优先保证可用性，不能保证强一致性，cap理论，这两点是无法同时满足的。registry使用的事concurrentHashmap，是线程同步的，如果不用缓存，那总有那么一瞬间eureka-client是读取不到数据的，因为这时registry可能正在干别的事，如同步集群间的注册表，如果用缓存可以保证只要erueka-client来读取，肯定能读取到，不会有等待的情况，优先保证可用性。（猜测）