Spring Cloud 中出现的一些坑，记录一下

1.当你把config-server当做配置文件中心的时候,切记不要有以"producer"命名的服务,估计producer在spring cloud里是关键字.

2.假设:有一个服务 service0, 它的context-path为 /service/0.     有一个以zuul作为reverse proxy的服务,  它配有service0的routes,为: service0: /service/0/**.此时,如果你要通过reverse proxy来访问service0,则需要输入 /service/0/service/0.  

3.线程池拒绝策略异常:

java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@427829d8 rejected from java.util.concurrent.ThreadPoolExecutor@5f0345ff[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
    at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) ~[na:1.7.0_79]
    at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) [na:1.7.0_79]
    at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) [na:1.7.0_79]
    at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:110) ~[na:1.7.0_79]
    at com.netflix.discovery.TimedSupervisorTask.run(TimedSupervisorTask.java:62) ~[eureka-client-1.4.11.jar:1.4.11]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_79]
    at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_79]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_79]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [na:1.7.0_79]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
    at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]

了解Java线程池原理的人应该会知道,导致这个异常可能有2种情况:

1.把线程池shutdown了,无法接收新任务

2.线程池饱和,根据设置的,或默认的拒绝策略,对新任务进行拒绝.

从"com.netflix.discovery.TimedSupervisorTask" 可以大致看出,是一个服务发现的定时任务.

Google,StackOverflow之后,也没有比较好的解释.

然后在github spring-cloud-netflix 的issue上看到一条这样的回答:

这位大兄弟说:目前还没有人表明,这个异常会对应用有负面影响.

所以,暂时没有好的解决方法.

4.配置中心的repo已经有服务A的配置文件,但是服务A启动时却找不到配置文件:

如果是Git repo,需要先git add 服务A.yml 再commit 才能访问到.

5.healthcheck:  spring cloud Camden.SR6 下,如果配置

eureka:
  client:
    healthcheck:
      enabled: true

并添加actuator依赖,那么会导致该服务在eureka中一直是down的状态.

6,服务租约配置:

eureka:
  instance:
    lease-renewal-interval-in-seconds: 2 #续约间隔
    lease-expiration-duration-in-seconds: 4 #租约寿命

7.使用配置中心的时候,必须区分驼峰命名和中划线命名:

如果你的服务A,在配置中心的配置文件里,有一条配置为:

eureka:
  instance:
    instance-id: ${eureka.instance.ip-address}:${server.port}

此时服务A的本地配置文件里有:

eureka:
  instance:
    ipAddress: 127.0.0.1 

此时,程序启动后,在注册中心,会看到服务A的status为:

${eureka.instance.ip-address}:${server.port}

解决方案:将中划线命名统一改为驼峰即可.

8.Debug源码的时候发现,如果是Dalston.SR1 版本并且使用Eureka作为注册中心,Ribbon 默认的 ServerList 使用的是 EurekaRibbonClientConfiguration.ribbonServerList 而不是 RibbonClientConfiguration.ribbonServerList