在使用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秒的情况。

解决方案

1. 延长Hystrix的超时时间，示例：
   hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
   该配置让Hystrix的超时时间改为5秒。

2. 禁用Hystrix超时，示例：
   hystrix.command.default.execution.timeout.enabled: false

3. 对于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 定位问题思路总结

1. 排查配置问题

   • YAML缩进是否正确
   • 配置属性是否正确
   • 配置属性的位置是否正确
     配置属性位置不正确可能会导致应用的不正常，举几个常见的例子：
     应当配置在Eureka Client项目上的属性，配置在了Eureka Server项目上。
     应当写在bootstrap.yml中的属性，写在了application.yml中，例如：

   spring:
   	cloud:
   		config:
   			uri: http://localhost:8080/
   

   该属性应当写在bootstrap.yml中。

2. 排查环境问题

   • 环境变量
   • 依赖下载是否完整： 再启动前使用 mvn clean package 打包，确认依赖完整性。
   • 网络问题

3. 排查代码问题
   很多时间常常因为缺少了某个注解，或者是依赖缺失，导致了各种异常。设置合理的日志级别，会对问题的定位有奇效。

4. 排查Spring Cloud自身问题