Eureka 使用的常见问题总结

Posted 2023-04-13

参考技术A 在我们启动一个服务后，可能要过一分多钟才能被其他服务调用到，那么这种情况不管是开发/测试环境，亦或是生产环境都会影响效率。出现该问题的原因有以下几种：

所以终上所述，一个服务注册上线需要的最大时间为30（eureka.server.response-cache-update-interval-ms）+30（eureka.client.registry-fetch-interval-seconds）+30（ribbon.ServerListRefreshInterval）=90秒。

在服务停掉后，Eureka Server并不能快速的将已停止的服务实例剔除，对调用方而言，请求到已停止的服务实例上则会提示拒绝连接，出现该问题的原因有以下几种：

综合以上服务注册慢/注销慢的原因，我们的解决方案其实就是将上述的一些参数时间缩短。参考配置如下：

上述的配置只适用于中小型应用，需要注意的是，如果把请求Eureka Server的时间都调小的话（比如获取注册表、发送心跳等），在系统服务实例的数量很大的情况下，那么会对Eureka Server造成压力。

如果Eureka服务节点在短时间里丢失了大量客户端的心跳连接时，（注：可能发生了网络故障，有可能客户端实例还在正常运行），那么这个Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好。

对于不存在跨区、跨网络机房的中小型应用而言，建议关闭自我保护模式。

springcloud使用总结

虽然springcloud全家桶里面包含了很多优秀的技术，包括负载均衡，路由选举，断路器，熔断机制，零配置，分布式锁，链路追踪等，但是在实现的过程中它的运维成本却大大增加。

一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。

Ribbon，主要提供客户侧的软件负载均衡算法。
Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。下面是用到的一些负载均衡策略：

• 简单轮询负载均衡

• 加权响应时间负载均衡

• 区域感知轮询负载均衡

• 随机负载均衡

Ribbon中还包括以下功能：

• 易于与服务发现组件（比如Netflix的Eureka）集成

• 使用Archaius完成运行时配置

• 使用JMX暴露运维指标，使用Servo发布

• 多种可插拔的序列化选择

断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正??，应用程序可以尝试调用操作。

断路器增加了稳定性和灵活性，以一个系统，提供稳定性，而系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对一个操作，即很可能失败，而不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提高每次改变状态的时间的事件，该信息可以被用来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在打开状态。

类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

参考： https://www.cnblogs.com/ilinuxer/p/6580998.html