Eureka is a REST-based service used to locate services for cloud middleware layer service discovery and failover. Service registration and discovery is very important for micro services. With service registration and discovery, services can be accessed by using only the identifier of the service, without modifying the configuration file for service invocation. It functions like a registration center for Dubbo, such as Zookeeper.
Principle understanding
Eureka Basic Architecture
- SpringCloud encapsulates the **Eureka module developed by Netflix to implement service registration and discovery** (compared to Zookeeper)
- The Eureka module is designed with CS architecture. Eureka Server serves as the service registration function and is the service registration center.
- Other micro services in the system use the EurekaClient to connect to EurekaServer and maintain a heartbeat connection. This allows system maintainers to monitor the proper functioning of each micro-service in the system through EurekaServer, and some other modules of Springcloud, such as Zuul, can discover other micro-services in the system through EurekaServer and execute related logic.
Compare with dubbo architecture
Eureka consists of two components: Eureka Server&Eureka client
- Eureka Server: Provides service registration, and after each node starts, it is registered in Eureka Server so that the service registry in Eureka Server stores information about all available service nodes, which can be visually seen in the interface.
- Eureka Client is a Java client that simplifies interaction with Eureka Server and also has a built-in load balancer that uses a polling load algorithm. After the application starts, a heartbeat is sent to Eureka Server (the default cycle is 30 seconds). If Eureka Server does not receive a node's heartbeat during multiple heartbeat cycles, Eureka Server will remove the service node from the service registry (default cycle is 90s)
Three major roles
- Eureka Server: Registration and discovery of services
- Service Provider: A service producer that registers its services with Eureka so that service consumers can find them
- Service Consumer: Service consumers, get a list of registered services from Eureka to find consumer services
Construction steps
eureka-server
- Establishment of springcloud-eureka-7001 module
- pom.xml configuration
<!--Guide Pack~-->
<dependencies>
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka-server -->
<!--Import Eureka Server rely on-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
<!--Hot Deployment Tools-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
</dependencies>
- application.yml
server:
port: 7001
# Eureka configuration
eureka:
instance:
# Instance name of Eureka server
hostname: 127.0.0.1
client:
# Indicates whether to register yourself with the Eureka registry (this module is a server itself, so it is not required)
register-with-eureka: false
# fetch-registry if false means that it is the registry and the client is normalized to ture
fetch-registry: false
# Eureka Monitoring Page~
service-url:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
Default port and access path for Eureka in source code:
- Main startup class: Start Eureka Server
/**
* @Auther: csp1999
* @Date: 2020/05/18/10:26
* @Description: After startup, access http://127.0.0.1:7001/
*/
@SpringBootApplication
// Startup class for the @EnableEurekaServer server, which can be registered by others~
@EnableEurekaServer
public class EurekaServer_7001 {
public static void main(String[] args) {
SpringApplication.run(EurekaServer_7001.class,args);
}
}
- Access after successful startup http://localhost:7001/ Get the following page
eureka-client
Adjust springcloud-provider-dept-8001 created before
- Import Eureka Dependencies
<!--Eureka rely on-->
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
- Add Eureka configuration to application
# Eureka configuration: Configure service registry address
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
- Add the @EnableEurekaClient comment to the Zhu startup class
/**
* @Auther: csp1999
* @Date: 2020/05/17/22:09
* @Description: Startup Class
*/
@SpringBootApplication
// @EnableEurekaClient opens the Eureka client annotation and automatically registers the service with the registry after the service starts
@EnableEurekaClient
public class DeptProvider_8001 {
public static void main(String[] args) {
SpringApplication.run(DeptProvider_8001.class,args);
}
}
- Start the 7001 server first, then start the 8001 client for testing, then access the monitoring page http://localhost:7001/ View the results as shown in the diagram, successful.
- Modify the default description information on Eureka
# Eureka configuration: Configure service registry address
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
instance:
instance-id: springcloud-provider-dept-8001 #Modify the default description information on Eureka
The result is as follows:
If you stop springcloud-provider-dept-8001 for 30 seconds at this time, monitoring will turn on the protection mechanism:
6. Configure monitoring information about service loading
(1) pom. Adding dependencies to XML
<!--actuator Perfect monitoring information--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
(2) application.yml Add Configuration
# info configuration info: # Name of project app.name: haust-springcloud # Name of the company company.name: Software College of Xiyuan Campus, Henan University of Science and Technology
(3) Refresh the monitoring page and click to enter
Skip to the new page as follows:
Eureka self-protection mechanism
At a time when the microservice is unavailable, eureka will not immediately clean up, but will still save the information of the microservice.
- By default, when the eureka server does not receive an instance's heartbeat for a certain period of time, it deletes the instance from the registry (default is 90 seconds), but if a large number of instance heartbeats are lost in a short period of time, it triggers the eureka server's self-protection mechanism, such as restarting the micro-service instance frequently when developing tests. But we rarely restart eureka server together (because the eureka Registry will not be modified during development), which triggers this protection mechanism when the number of hearts received in a minute decreases dramatically. You can see Renews threshold s and Renews (last minute) in the eureka management interface when the latter (the number of heartbeats received in the last minute) is less than the former (the heart rate threshold), triggering the protection mechanism, and a red warning appears: EMERGENCY!EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT.RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEGING EXPIRED JUST TO BE SAFE. As you can see from the warning, eureka believes that although it can't receive the heartbeat of instances, they are still healthy and that eureka will protect them from deleting them from the registry.
- The purpose of this protection mechanism is to avoid network connection failure. In the event of a network failure, normal communication between the micro-service and the registry cannot occur, but the service itself is healthy and should not be cancelled. If eureka deletes the micro-service by mistake due to a network failure, the micro-service will not be re-registered with the eureka server even if the network is recovered. Since registration requests are only initiated when the microservice is started, then only heartbeat and service list requests are sent, the instance is running but never perceived by other services. Therefore, eureka server enters self-protection mode when it loses too many client heartbeats in a short period of time. In this mode, eureka protects information in the registry, does not log off any micro-services, and automatically exits protection mode when network failure recovers. Self-protection mode can make clusters more robust.
- However, during the development and testing phase, we need to reinvent the publication frequently. If the protection mechanism is triggered, the old service instance is not deleted. At this time, the request may run to the old instance, which has been closed, causing the request to be wrong and affecting the development tests. Therefore, during the development and testing phase, we can turn off the self-protection mode by simply adding the following configuration to the eureka server configuration file: eureka.server.enable-self-preservation=false [closing self-protection mechanisms is not recommended]
Register for microservices, get some messages (team development will use)
DeptController. New methods for java:
/**
* DiscoveryClient Can be used to get some configuration information, get specific micro services!
*/
@Autowired
private DiscoveryClient client;
/**
* Get some information about registered microservices~,
*
* @return
*/
@GetMapping("/dept/discovery")
public Object discovery() {
// Get a list of microservices
List<String> services = client.getServices();
System.out.println("discovery=>services:" + services);
// Get a specific micro-service information, through the specific micro-service id, applicaioinName;
List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER-DEPT");
for (ServiceInstance instance : instances) {
System.out.println(
instance.getHost() + "\t" + // Host Name
instance.getPort() + "\t" + // Port number
instance.getUri() + "\t" + // uri
instance.getServiceId() // Service id
);
}
return this.client;
}
Add the @EnableDiscoveryClient annotation to the main startup class:
@SpringBootApplication
// @EnableEurekaClient opens the Eureka client annotation and automatically registers the service with the registry after the service starts
@EnableEurekaClient
// @EnableEurekaClient opens the service discovery client annotation, which can be used to obtain some configuration information for specific microservices
@EnableDiscoveryClient
public class DeptProvider_8001 {
...
}
The result is as follows:
Eureka: Cluster Environment Configuration
Initialization
Create new springcloud-eureka-7002, springcloud-eureka-7003 modules.
- For pom.xml add dependency (same as springcloud-eureka-7001)
<!--Guide Pack~-->
<dependencies>
<!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka-server -->
<!--Import Eureka Server rely on-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
<version>1.4.6.RELEASE</version>
</dependency>
<!--Hot Deployment Tools-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
</dependencies>
- application.yml configuration (same as springcloud-eureka-7001)
server:
port: 7003
# Eureka configuration
eureka:
instance:
hostname: localhost # Instance name of Eureka server
client:
register-with-eureka: false # Indicates whether to register yourself with the Eureka registry (this module is a server itself, so it is not required)
fetch-registry: false # fetch-registry If false, indicates that it is a registry
service-url: # Monitor Page~
# Override Eureka's default port and access path ---> http://localhost:7001/eureka/
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
- Main startup class (same as springcloud-eureka-7001)
/**
* @Auther: csp1999
* @Date: 2020/05/18/10:26
* @Description: After startup, access http://127.0.0.1:7003/
*/
@SpringBootApplication
// Startup class for the @EnableEurekaServer server, which can be registered by others~
public class EurekaServer_7003 {
public static void main(String[] args) {
SpringApplication.run(EurekaServer_7003.class,args);
}
}
Cluster members are related to each other
Configure some custom native names, locate the local hosts file, and open it. At the end of the file, add the local name you want to access. The default is localhost:
Modify the application. The configuration of yml, as shown in the figure for springcloud-eureka-7001, can also be modified to the name of springcloud-eureka-7002/springcloud-eureka-7003
Associate springcloud-eureka-7001 with springcloud-eureka-7002, springcloud-eureka-7003, application under complete springcloud-eureka-7001 in clusters. YML is as follows:
server:
port: 7001
#Eureka configuration
eureka:
instance:
hostname: eureka7001.com #Instance name of Eureka server
client:
register-with-eureka: false #Indicates whether to register yourself with the Eureka registry (this module is a server itself, so it is not required)
fetch-registry: false #fetch-registry If false, indicates that it is a registry
service-url: #Monitor Page~
#Override Eureka's default port and access path ---> http://localhost:7001/eureka/
# Single machine: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
# Cluster (Affiliation): 7001 Affiliates 7002, 7003
defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
Springcloud-eureka-7002 is also associated with springcloud-eureka-7001 and springcloud-eureka-7003 in the cluster. Application under complete springcloud-eureka-7002. YML is as follows:
server:
port: 7002
#Eureka configuration
eureka:
instance:
hostname: eureka7002.com #Instance name of Eureka server
client:
register-with-eureka: false #Indicates whether to register yourself with the Eureka registry (this module is a server itself, so it is not required)
fetch-registry: false #fetch-registry If false, indicates that it is a registry
service-url: #Monitor Page~
#Override Eureka's default port and access path ---> http://localhost:7001/eureka/
# Single machine: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
# Cluster (Affiliation): 7002 Affiliates 7001, 7003
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
The same is true for the springcloud-eureka-7003 configuration.
Modify the Eureka configuration by using the yml configuration file under springcloud-provider-dept-8001: Configure the service registry address
# Eureka configuration: Configure service registry address
eureka:
client:
service-url:
# Registry Address 7001-7003
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
instance:
instance-id: springcloud-provider-dept-8001 #Modify the default description information on Eureka
This sets up a simulated cluster so that you can mount a project on three servers:
Contrast and Zookeeper Differences
CAP Principles
RDBMS (MySQL\Oracle\sqlServer) ===> ACID
NoSQL (Redis\MongoDB) ===> CAP
What is ACID?
- A: Atomicity
- C: Consistency
- I: Isolation
- D: Persistence
What is a CAP?
- C: Strong consistency
- A: Availability
- P: Partition fault tolerance
CAP's three-in-two: CA, AP, CP
Core of CAP Theory
- A distributed system cannot meet the three requirements of consistency, availability, and partition fault tolerance at the same time.
- According to CAP principle, NoSQL database is divided into three categories: satisfying CA principle, satisfying CP principle and satisfying AP principle:
(1) CA: A single-point cluster, a system that satisfies consistency and availability, usually with poor scalability.
(2) CP: Systems that meet consistency and partition fault tolerance usually do not perform particularly well.
(3) AP: Systems that meet availability and are partitioned fault-tolerant may generally require less consistency.
Where is Eureka better than Zookeeper as a Distributed Services Registry?
The well-known CAP theory states that a distributed system cannot satisfy C (consistency), A (availability), P (fault tolerance) at the same time. Since partition fault tolerance P must be guaranteed in a distributed system, we can only trade off between A and C.
- Zookeeper ensures that systems with CP->consistency and partition fault tolerance usually do not perform particularly well.
- Eureka guarantees that AP->systems that meet availability and partition fault tolerance may generally require less consistency.
Zookeeper(CP)
When querying the registry for a list of services, we can tolerate registry returning registration information a few minutes ago, but not receiving services that are directly down loaded and unavailable. That is, the service registration function requires higher availability than consistency. However, zookeeper has such a situation that when the master node loses contact with other nodes due to network failure, the remaining nodes will be re-elected for leader. The problem is that the election lead took too long, 30-120s, and the entire zookeeper cluster was unavailable during the election, resulting in a paralysis of registration services during the election. In a cloud deployment environment, it is a relatively common occurrence for the zookeeper cluster to lose the master node due to network issues. Although services can ultimately be restored, the long election period that results in long-term unavailability of registration is intolerable.
Eureka(AP)
Eureka prioritizes usability at design time. The Eureka nodes are equal. Hanging a few nodes will not affect the normal work of the nodes. The remaining nodes can still provide registration and query services. When Eureka's client registers with an Eureka, it automatically switches to another node if it finds that the connection fails. As long as one Eureka is still present, it can maintain the availability of the registration service. However, the information it finds may not be up-to-date. In addition, Eureka has a self-protection mechanism, which allows more than 85% of the nodes to have no normal heartbeat within 15 minutes. Eureka then assumes that there is a network failure between the client and the registry, and the following situations occur:
- Eureka no longer removes services from the registration list that should expire due to prolonged confiscation of a heartbeat
- Eureka can still accept registration and query requests for new services, but will not be synchronized to other nodes (that is, to ensure that the current node is still available)
- When the network is stable, new registration information for the current instance is synchronized to other nodes
Therefore, Eureka can cope well with situations where network failures cause some nodes to lose contact, rather than paralysing the entire registration service like Zookeeper.
Thank you and refer to: