一起养成写作习惯!这是我参与「掘金日新计划 · 4 月更文挑战」的第4天,点击查看活动详情
简介
Eureka,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中,以实现SpringCloud的服务发现功能。
Eureka Client是一个java客户端,用于简化与Eureka Server的交互,客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。
Eureka Server提供服务注册服务,各个节点启动后,会在Eureka Server中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。
客户调用
-
还记得我们的feature/cloud-pre上order模块是如何调用payment的吗。是的我们通过resetTemplate进行http方式调用的。现在我们还是通过他进行调用只不过调用地址是payment注册在eureka上的服务名。
-
这里客户端如何注册和payment配置一样的。因为虽然是order调用payment,但是对于eureka来说payment和order都是客户端。所以配置都是一样的。
-
现在在单机的eureka上我们看到了单机的order服务和集群的payment服务。下面我们order调用payment的地方做如下修改
-
只是调用跟地址进行了修改。当然前提是restTemplate支持了负载均衡。
-
下面结果如何读者可以自行测试了。
http://localhost/order/getpayment/123针对这个接口调用多次。会发现返回结果里的服务端口会不断的8001,8002切换。因为restTemplate默认是轮询的。而我们这里payment提供了两个服务。到这里我们就实现了eureka单机版的服务注册及调用
Eureka自我保护
为什么要自我保护
- 上面我们发现有两个8002的payment。为什么会出现如此奇怪的问题呢。排查发现一开始我通过idea启动了8001,8002。然后我又通过引入外部配置文件的方式重新启动了8002。这个时候原来的8002实例其实已经挂了。这个时候eureka会认为出现50%的客户端没有准时发送心跳。50<85 这个时候eureka认为大批客户端可能因为网络波动导致没有及时回复。eureka会开启自我保护机制。
- 虽然上面是个反面列子。也恰恰说明了为什么需要自我保护。加入这个时候8002在其他机器上因为网络延迟被踢出就会出现冤假错案。所以这也解释了为什么上述出现两个8002.
如何开启自我保护
- 自我保护的功能是默认开启的。
eureka.server.enable-self-preservation: false我们通过此属性设置false就是关闭自我保护。
自我保护如何激活
- 其实上面两个8002是一种意外。我们无意中触发了自我保护。
- 自我保护机制条件 : 最近一分钟收到心跳数线程占总线程85%以下。
- 低于85%说明没有指定活跃数进行心跳回复,所以认为是网络波动了。