1. When you think of Config-server as a profile center, remember not to have a service named "producer", which is estimated to be a keyword in spring cloud producer.
2. Suppose: There is a service service0, and its context-path is/service/0. There is a service with Zuul as reverse proxy, it is equipped with SERVICE0 routes, Service0:/service/0/**. At this point, if you want to access reverse via SERVICE0 proxy, you need to enter/ service/0/service/0.
3. Thread pool Reject policy exception:[Java] View Plain Copy 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&NBsp;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]
People who understand the Java thread pool principle should know that there are 2 possible scenarios that cause this exception:
1. Shutdown the thread pool, unable to receive new tasks
2. Thread pool saturation, depending on the settings, or the default rejection policy, the new task is rejected.
From "Com.netflix.discovery.TimedSupervisorTask" can be seen in general, is a service discovery timing task.
After Google,stackoverflow, there is no better explanation.
And then on the issue of GitHub Spring-cloud-netflix, I saw this answer:
"No one has yet shown that this anomaly will have a negative effect on the application," said the Big Brother.
Therefore, there is no good solution for the time being.
4. The configuration Center's repo already has a configuration file for service A, but service a does not find a profile when it starts:
If you are git repo, you need to git the Add service a.yml before you can access it.
5.healthcheck:spring Cloud CAMDEN.SR6, if configured
Eureka:
Client:
healthcheck:
enabled:true
And adding actuator dependencies, it will cause the service to be down in the Eureka State.
6, Service lease configuration:
Eureka:
instance:
2 #续约间隔
4 #租约寿命
7. When using a configuration center, you must distinguish between hump naming and underlining:
If your service A, in the Configuration Center configuration file, one of the configuration is:
Eureka:
instance:
${eureka.instance.ip-address}:${server.port}
The local profile for service A at this time is:
Eureka:
instance:
At this point, after the program starts, in the registry, you will see that the status of service A is:
${eureka.instance.ip-address}:${server.port}
Solution: Change the underscore name to the hump.
8.Debug source when found, if it is DALSTON.SR1 version and use Eureka as a registry, Ribbon default ServerList use is Eurekaribbonclientconfiguration.ribbonserverlist, not ribbonclientconfiguration.ribbonserverlist.