- Question 1: EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
Answer: By default, if Eureka Server does not receive the heartbeat of a microservice instance within a certain period of time, Eureka Server will log off the instance (90 seconds by default). But when a network partition failure occurs, the microservice and Eureka Server cannot communicate normally, and the above behavior may become very dangerous-because the microservice itself is actually healthy, this microservice should not be logged out at this time.
Eureka solves this problem through the "self-protection mode"-when the Eureka Server node loses too many clients in a short period of time (a network partition failure may occur), then this node will enter the self-protection mode. Once in this mode, Eureka Server will protect the information in the service registry and will no longer delete the data in the service registry (that is, it will not log out any microservices). When the network failure is restored, the Eureka Server node will automatically exit the self-protection mode.
In summary, the self-protection mode is a safety protection measure to deal with network abnormalities. Its architectural philosophy is to prefer to retain all microservices at the same time (both healthy and unhealthy microservices will be retained), rather than blindly log off any healthy microservices. Using self-protection mode can make the Eureka cluster more robust and stable.
In Spring Cloud, you can use eureka.server.enable-self-preservation = false to disable self-preservation mode.
- Question 2: Eureka's high-availability solution. In the above example, Eureka has only one 8761 registration center, so how to avoid single point problems?
Answer: We can use the cluster method to solve the problem. For example, there are now three machines: Server1, Server2 and Server3. In a high-availability solution, the three machines must be registered in pairs. For example, S1 needs to register with S2 and S3 separately, and currently he cannot realize the transitivity of registration. In this way, if Server1 goes down, we can continue to get services from Server2 and 3.
- Question 3: Why not use zookeeper as a registry? When using dubbo, it is generally combined with zk (as a registry). So why is Eureka used in SpringCloud instead of zk?
Answer: Let's compare. In CAP theory, zk pays more attention to C and P, that is, consistency and partition fault tolerance. But Eureka cares more about A and P, A is highly available. There is a difference between master and follower in zk. When it enters the election mode, it cannot provide services normally. But in Eureka, clusters are equal and have the same status. Although consistency cannot be guaranteed, at least registration services can be provided. According to different business scenarios, there are trade-offs.
- Question 4: Use IP registration in spring eurake: I encountered a very strange problem when developing spring cloud, that is, when the service registered the instance in spring eureka, the machine name was used, and then localhost, xxx.xx, etc. appeared Content, as shown below:
Answer: A lot of online said that it is eureka.instance.preferIpAddress=true, but in fact, it seems that this parameter does not work. Finally, modify the C:\Windows\System32\drivers\etc\hosts file to add host name mapping to solve it.
- Question five: circuit breaker feature: com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
Solution: Missing configuration file application.properties file
- Question 6: Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder'profile' in string value "${profile}"
Solution: The file directory and name in the configuration file are incorrect. The distributed configuration client must require the bootstrap.properties file. spring.cloud.config.label represents the file name of the configuration. spring.application.nam represents the key value in the file. spring.cloud.config.label represents the name of the upper-level directory of the configuration file.
- Question 7: No label found for: trunk
Solution: There is a problem with the directory structure.
- Question 8: How to solve the problem that Eureka Server does not kick out nodes that have been shut down
In the development process, we often hope that Eureka Server can quickly and effectively kick out the nodes that have been shut down, but because of the Eureka self-protection mode and the long heartbeat cycle, novices often encounter Eureka Server not kicking out the shutdown nodes. Node problem.
The solution is as follows:
Server-side configuration:
eureka:
server:
enable-self-preservation: false
eviction-interval-timer-in-ms: 4000
Client configuration:
eureka:
client:
healthcheck:
enabled: true
instance:
lease-expiration-duration-in-seconds: 30
lease-renewal-interval-in-seconds: 10
- Question 9: How to solve the refresh is not allowed: Method Not Allowed HttpRequestMethodNotSupportedException
Solution: no configuration library file
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>