Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

1. Build projects

Create a normal SpringBoot project.

1. Modify the Application

Modify the EurekaServerApplication class: the key annotation @enableEurekaserver is declared as a registry.

package com.cloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;


@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(EurekaServerApplication.class, args);
	}
}
Copy the code

2. Modify the POM file

Then modify the POM file: be sure to watch the version, the current version is really messy, and some of the annotations are dried.

<? The XML version = "1.0" encoding = "utf-8"? > < project XMLNS = "http://maven.apache.org/POM/4.0.0" XMLNS: xsi = "http://www.w3.org/2001/XMLSchema-instance" Xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" > < modelVersion > 4.0.0 < / modelVersion > < the parent > < groupId > org. Springframework. Boot < / groupId > The < artifactId > spring - the boot - starter - parent < / artifactId > < version > 2.2.5. RELEASE < / version > < relativePath / > <! -- lookup parent from repository --> </parent> <groupId>com.baocl</groupId> < artifactId > eureka - consumer - feign < / artifactId > < version > 0.0.1 - the SNAPSHOT < / version > < name > eureka - consumer - feign < / name > <description>Demo project for Spring Boot</description> <properties> <java.version>1.8</java.version> <spring-cloud.version>Hoxton.SR1</spring-cloud.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId>  <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion> </exclusions> </dependency> </dependencies> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>Copy the code

3. Modify the application. The properties

Finally, the most important configuration file, application.properties, summarizes the common configurations.

spring.application.name=eureka-server eureka.client.serviceUrl.defaultZone=http://localhost:${server.port}/eureka/ Server. port=1001 eureka.instance.hostname=localhost # Whether to register yourself with the service registry eureka.client.register-with-eureka=false # Whether to retrieve the service Eureka.client. fetch-registry=false # Enable self-protection mode, default is true. By default, if Eureka Server does not receive a heartbeat from a microservice instance within a certain period of time, the Eureka Server will log out of the instance (default: 90 seconds). However, when a partition failure occurs and the microservice cannot communicate with the Eureka Server, this behavior can become very dangerous -- the microservice itself is healthy and should not be logged out. #Eureka solves this problem by "self-protecting mode" -- when a Eureka Server node loses too many clients in a short period of time (possibly due to a network partition failure), # the node goes into self-protecting mode. Once in this mode, Eureka Server protects the information in the service registry and does not delete the data in the service registry (that is, does not unregister any microservices). The Eureka Server automatically exits self-protection mode after the network fault is recovered. To sum up, self-protection mode is a security protection measure to deal with network abnormalities. Its architectural philosophy is to prefer to keep all microservices at the same time (both healthy and unhealthy microservices will remain), # rather than blindly cancel any healthy microservices. Using self-protection mode can make Eureka cluster more robust and stable. #eureka.server.enable-self-preservation=false 60S # Eureka. server.eviction- interval-timer-in-MS =5000 # Self-protection renewal percentage threshold factor If the actual contract number is less than contract number threshold, then open the ego to protect # eureka. Server renewalPercentThreshold = 0.85 # between nodes connection timeout. 200 # # eureka. Server. PeerNodeConnectTimeoutMs = read information between nodes of timeout. 200 # # eureka. Server. PeerNodeReadTimeoutMs = every x seconds updates its cache on the client cache was obtained from the server (1001 page to skip the cache will not take effect) #eureka.server.response-cache-update-interval-ms= 2000Copy the code

Then start the service, access the configured port number, the screen appears, which means OK.

4. General principles

Spring Cloud communication is mainly carried out in the form of HTTP requests. When the service is registered with Eureka after startup, Eureka Server will synchronize the registration information to other Eureka Servers. When the service consumers want to invoke the service provider, they will obtain the address of the service provider from the service registry. The service provider address is then cached locally, and the next call is directly fetched from the local cache to complete the call. When the Service registry Eureka Server detects that the service provider is unavailable due to downtime or network reasons, it sets the service status to DOWN in the service registry and publishes the current service provider status to subscribers. The subscribed service consumers update the local cache. Once started, the service provider periodically (30 seconds by default) sends heartbeats to Eureka Server to prove that the current service is available. If the Eureka Server does not receive the heartbeat from the client within a certain period of time (90 seconds by default), the Eureka Server considers that the service is down and logs out of the instance.