Spring Cloud的一些坑

最新推荐文章于 2024-09-15 19:46:31 发布

chenlunhuang5289

最新推荐文章于 2024-09-15 19:46:31 发布

阅读量137

点赞数

文章标签： java

原文链接：https://my.oschina.net/u/2449415/blog/1590002

版权

1.负载均衡失效

通过zuul访问服务当服务有多个节点时，访问竟然是轮询，如果有一个节点down掉了，依然会轮循到此机器。该问题困扰我很久，为什么会这么蠢？

终于在github找到开发者说道：

Brixton

In Brixton we use the Ribbon HTTP Client when proxying requests through Zuul. This means you can use all ribbon.* properties to configure retry and connection logic with Zuul.

Camden

In Camden we no longer use the Ribbon HTTP Client so none of the ribbon.* properties will help you control the retry logic.

原来是版本的问题，所以如果用Camden以后版本的注意了，如果要用ribbon的负载，就要加上

ribbon.restclient.enabled=true

之后retry的策略以及超时时间都可以控制了

2.一些参数说明

服务端:

eureka.server.enable-self-preservation

默认为true,简单的说就是eureka认为有的时候client没有出错只是因为网络问题导致没连上client,所以不能简单的拿掉client,Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）

eureka.server.eviction-interval-timer-in-ms

清除无效节点的时间,默认60000

客户端:

eureka.client.registry-fetch-interval-seconds

表示eureka client间隔多久去拉取服务注册信息，默认为30秒，对于api-gateway，如果要迅速获取服务注册状态，可以缩小该值，比如5秒

eureka.instance.lease-expiration-duration-in-seconds

leaseExpirationDurationInSeconds，表示eureka server至上一次收到client的心跳之后，等待下一次心跳的超时时间，在这个时间内若没收到下一次心跳，则将移除该instance。

默认为90秒
如果该值太大，则很可能将流量转发过去的时候，该instance已经不存活了。
如果该值设置太小了，则instance则很可能因为临时的网络抖动而被摘除掉。
该值至少应该大于leaseRenewalIntervalInSeconds

eureka.instance.lease-renewal-interval-in-seconds

leaseRenewalIntervalInSeconds，表示eureka client发送心跳给server端的频率。如果在leaseExpirationDurationInSeconds后，server端没有收到client的心跳，则将摘除该instance。除此之外，如果该instance实现了HealthCheckCallback，并决定让自己unavailable的话，则该instance也不会接收到流量。