在使用Spring Cloud的过程中,常常会遇到一些问题,这里来对Spring Cloud的常见问题做一些总结。
Eureka 常见问题
Eureka注册服务慢
默认情况下,服务注册到Eureka Server的过程较慢。在开发或者测试时,常常希望能够加速这一过程,从而提升工作效率。
Spring Cloud官方文件详细描述了该问题的原因并提出了解决方案:
服务的注册涉及到周期性心跳,默认30s一次(通过客户端配置的serviceUrl)。只有当实例、服务器端和客户端的本地缓存中的元数据都相同时,服务才能被其他客户端发现(所以可能需要3次心跳)。可以使用参数
eureka.instance.leaseRenewalIntervalInSeconds
修改时间间隔,加速客户端连接到其他服务的过程。ps: 再生产环境中最好坚持使用默认值,因为在服务器内部有一些计算,它们会对续约做出假设。
上述原文出自:http://cloud.spring.io/spring-cloud-static/Camden.SR1/#_why_is_it_so_slow_to_register_a_service
综上,要想解决服务注册慢的问题,只须将eureka.instance.leaseRenewalIntervalInSeconds
设成一个更小的值。该配置用于设置Eureka Client 向Eureka Server发送心跳的时间间隔,默认是30,单位是秒。再生产环境中,建议坚持使用默认值。
已停止的微服务节点未注销或不注销
在开发环境下,常常希望Eureka Server能迅速有效地注销已停止的微服务实例。然而,由于Eureka Server清理无效节点周期长(默认90s),以及自我保护模式等原因,可能会遇到微服务注销慢或者不注销的问题。解决方案如下:
-
Eureka Server端:
配置关闭自我保护,并按需配置Eureka Server清理无效节点的时间间隔。eureka.server.enable-self-preservation
设置为false,关闭自我保护,从而保证会注销微服务
eureka.server.eviction-interval-timer-in-ms
清理间隔(单位毫秒,默认是60*1000)
-
Eureka Client端:
配置开启健康检查,并按需配置续约更新时间和到期时间eureka.client.healthcheck.enable
设为true,开启健康检查(需要spring-boot-starter-actuator依赖)
eureka.instance.lease-renewal-interval-in-seconds
续约更新时间间隔(默认30s)
eureka.instance.lease-expiration-duration-in-seconds
续约到期时间(默认90s)
需要注意的是,这些配置仅在开发或测试时使用,生产环境建议坚持使用默认值。
示例:
-
Eureka Server配置:
eureka:
server:
eureka.server.enable-self-preservation: false
eureka.server.eviction-interval-timer-in-ms: 4000 -
Eureka Client 配置:
eureka:
client:
healthcheck:
enabled: true
instance:
lease-renewal-interval-in-seconds: 30
eureka.instance.lease-expiration-duration-in-seconds: 10
如何自定义微服务的Instance ID
Instance ID用于唯一标识注册到Eureka Server上的微服务实例。
在Eureka Server的首页可以直观地看到各个微服务的Instance ID,如下图的 localhost:microservice-provider-user:8010 就是Instance ID。
在Spring Cloud中,服务的Instance ID的默认值是${spring.cloud.client.hostname}:${spring.application.name}:${spring.application.instance_id:${server.port}}
。 如果想要自定义这部分内容,只须在微服务中配置 eureka.instane.instance-id属性即可,例如:
spring:
application:
name: microservice-provider-user
eureka:
instance:
# 将Instance ID设置成IP:端口的形式
instance-id: ${spring.cloud.client.ipAdress}:${server.port}
Hystrix/Feign 整合Hystrix后首次请求失败
原因分析
Hystrix默认超时时间是1秒,如果在1秒内得不到响应,就会进入fallback逻辑。由于Spring 懒加载的机制,首次请求往往会比较慢,因此某些机器上可能出现响应大于1秒的情况。
解决方案
-
延长Hystrix的超时时间,示例:
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
该配置让Hystrix的超时时间改为5秒。 -
禁用Hystrix超时,示例:
hystrix.command.default.execution.timeout.enabled: false
-
对于Feign,还可为Feign禁用Hystrix,示例:
feign.hystrix.enabled: false
这样既可为Feign全局禁用Hystrix支持。该方式比较极端,不建议使用。
Spring Cloud各组件配置属性
Spring Cloud中大部分问题都可使用配置属性来解决。下面罗列相关组件的配置地址,方便查阅。
Spring Cloud 的配置
Spring Cloud的所有组件配置都在其官方文档的附录,地址如下:
http://cloud.spring.io/spring-cloud-static/Camden.SR4/#_appendix_compendium_of_configuration_properties
原生配置
Spring Cloud 整合了很多类库,例如Eureka、Ribbon、Feign等。这些组件自身也有一些配置属性,如下:
- Eureka的配置: https://github.com/Netflix/eureka/wiki/Configuring-Eureka
- Ribbon的配置: https://github.com/Netflix/ribbon/wiki/Programmers-Guide
- Hystrix的配置:https://github.com/Netflix/Hystrix/wiki/Configuration
- Turbine的配置:https://github.com/Netflix/Turbine/wiki/Configuration-(1.x)
Spring Cloud 定位问题思路总结
-
排查配置问题
-
YAML缩进是否正确
-
配置属性是否正确
-
配置属性的位置是否正确
配置属性位置不正确可能会导致应用的不正常,举几个常见的例子:
应当配置在Eureka Client项目上的属性,配置在了Eureka Server项目上。
应当写在bootstrap.yml中的属性,写在了application.yml中,例如:spring:
cloud:
config:
uri: http://localhost:8080/
该属性应当写在bootstrap.yml中。
-
-
排查环境问题
- 环境变量
- 依赖下载是否完整: 再启动前使用
mvn clean package
打包,确认依赖完整性。 - 网络问题
-
排查代码问题
很多时间常常因为缺少了某个注解,或者是依赖缺失,导致了各种异常。设置合理的日志级别,会对问题的定位有奇效。 -
排查Spring Cloud自身问题