Eureka profile
Introduction to the
-
Eureka is a service discovery framework developed by Netflix. As a REST-based service, Eureka is mainly used to locate middle-tier services running in AWS domains for load balancing and middle-tier service failover. SpringCloud integrates it into its sub-project spring-Cloud-Netflix to implement SpringCloud’s service discovery capabilities.
-
Eureka consists of two components: Eureka Server and Eureka Client.
-
EurekaServer provides the service registration service. After each node is started, it is registered in the EurekaServer. In this way, the service registry in the EurekaServer stores information about all available service nodes.
-
Eureka Client is a Java Client designed to simplify the interaction with Eureka Server. The Client is also a built-in load balancer using round-robin load algorithms.
-
When the application starts, it sends heartbeat messages to the Eureka Server. The default heartbeat interval is 30 seconds. If the Eureka Server does not receive a heartbeat from a node within multiple heartbeat intervals, the Eureka Server removes the node from the service registry (default: 90 seconds). (Self-protection mechanism)
-
Data is synchronized between Eureka servers through replication. Eureka also provides a client cache mechanism. Even if all Eureka servers fail, clients can still use the information in the cache to consume other services’ apis. In summary, Eureka ensures high availability, flexibility and scalability of the system through heartbeat checking, client caching and other mechanisms
The three roles
Eureka Server: Provides registration and discovery of services
Service Provider: Service producers register their services with Eureka so that Service consumers can find them
Service Consumer: The Service Consumer finds the Consumer Service by getting the list of registered services from Eureka
Eureka service setup
This environment continues the Rest environment from the last Blog post, so our Eureka environment is built in Rest
Eureka
- Create a new module
springcloud-eureka-7001
Import Eureka’s dependencies
<! -- eureka -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
<version>2.2.5. RELEASE</version>
</dependency>
Copy the code
- write
application.yml
configuration
server:
port: 7001
# eureka configuration
eureka:
instance:
hostname: localhost # Eureka server instance name
client:
register-with-eureka: false # indicates whether to register yourself with Eureka
fetch-registry: false # false: Set yourself as the registry
service-url: # Monitor page
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
Copy the code
- Write the main startup class
package springcloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer // Eureka server startup class
public class EurekaServer {
public static void main(String[] args) { SpringApplication.run(EurekaServer.class,args); }}Copy the code
- Visit http://localhost:7001/ to test it out
Service provider
- Import dependence
<! -- eureka -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>2.2.5. RELEASE</version>
</dependency>
Copy the code
- in
application.yml
configurationeureka
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka/
Copy the code
- The main startup class starts the server and adds
@EnableEurekaClient
- Start the test, eureka starts too!! (If you started Eureka before, restart Eureka first and then start the service provider)
5. We can also modify the description information of service provider in Eurekaapplication.yml
In the configuration
eureka:
instance:
instance-id: provider-detail-message Configure the description
Copy the code
- If the power goes out suddenly, or your service crashes, is the service provider still in Eureka?
We find that the service provider is still there, and this relates to Eureka’s self-protection mechanism.
- Although the service provider is dead, Eureka still saves its information, so we can check its monitoring information
So how do we look at this, we need to add some configuration
- Add dependency to improve monitoring information
<! -- Actuator perfect monitoring information -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy the code
- in
application.yml
Configuring Monitoring Information
info:
app.name: springcloud-provider
company.name: apach
Copy the code
- Start the service provider
- Of course, we can also get information about these services
- write
DeptController.java
To obtain information about these services
@Autowired
private DiscoveryClient client;
// Sign up for microservices to get information
@GetMapping("/message")
public Object discovery(a){
// Get microservices
List<String> services = client.getServices();
System.out.println("Acquired Microservices"+services);
// Get the specific microservice through the id of the microservice
List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER");
for (ServiceInstance instance : instances) {
System.out.println(instance.getHost());
System.out.println(instance.getInstanceId());
System.out.println(instance.getPort());
System.out.println(instance.getUri());
System.out.println(instance.getServiceId());
}
return client;
}
Copy the code
- Add to the main boot class
@EnableDiscoveryClient
- Start the test
Eureka VS Zookeeper
What is CAP?
- C (Consistency) Strong Consistency
- A Availability
- P (Partition tolerance) Fault tolerance of a Partition
The core of CAP theory
A distributed system cannot meet the requirements of consistency, availability and fault tolerance of partitions at the same time
According to CAP principle, NoSQL database can be divided into three categories: CA principle, CP principle and AP principle
- CA: single-point cluster. A system that meets the requirements of consistency, availability, and poor scalability
- CP: consistent, partition fault tolerant system, usually not particularly high performance
- AP: Systems that satisfy availability and partition fault tolerance may generally have lower requirements for consistency
Among them
Eureka guarantees that AP — > meets availability, partition fault-tolerant systems, which may generally require less consistency
Zookeeper ensures CP – > consistent, partition fault-tolerant systems, usually with low performance
That’s why we chose Eureka