Shulou(Shulou.com)06/02 Report--

This article mainly explains "the registration method and expansion of Eureka service". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the registration method and expansion of Eureka service".

SpringCloud from incomprehension to abandonment, Chapter 2: registration and Discovery of Eureka Services

Eureka

When designing Eureka, Netflix abides by the AP principle, CAP principle, also known as CAP Theorem, which means that in a distributed system, Consistency (consistency), Availability (availability) and Partition tolerance (partition fault tolerance) cannot be achieved at the same time. 1. Eureka introduction Eureka is a sub-module of Netflix, is a Rest-based service for service location, and has realized cloud intermediate service discovery and failover. Service registration and discovery is very important for micro-service architecture. with service discovery and registration, you only need to use the service identifier to access the service without modifying the configuration file of the service invocation. Registries that function similar to dubbo, such as zookeeper

Eureka basic architecture

Spring Cloud encapsulates the Eureka module developed by Netflix to implement service registration and discovery (compare with Zookeeper). Eureka adopts the design architecture of Cmurs. Eureka Server serves as the server of the service registration function, and it is the service registry. For other microservices in the system, clients using Eureka connect to the Eureka Server and maintain a heartbeat connection. In this way, the maintenance staff of the system can use Eureka Server to monitor whether the micro-services in the system are running properly. Some other modules of SpringCloud (such as Zuul) can use Eureka Server to discover other micro services in the system and execute the relevant logic. Eureka contains two components: EurekaServer and EurekaClient EurekaServer provide service registration services. After each node starts, it will register in EurekaServer, so that the information of all available service nodes will be stored in the service registry of EurekaServer. The information of service nodes can be seen visually in the interface that EurekaClient is a Java client, which is used to simplify the interaction of EurekaServer. The client also has a built-in load balancer using the polling (round-robin) load algorithm. After the application starts, a heartbeat is sent to the Eureka Server (the default period is 30 seconds). If EurekaServer does not receive a heartbeat from a node in multiple heartbeat cycles, EurekaServer will remove the service node from the service registry (default is 90 seconds)

Three major structures

1. Eureka server provides service registration and discovery 2. Service provide registers its own services with Eureka, so that service consumers can find 3. Service consumer can obtain a list of registered services from Eureka, thus consuming services 2 and building projects

Project structure

General module API service provider Provider service consumer Consumereureka service registry module (1), cloud-eureka-7001

POM

Mainly contains a spring-cloud-starter-eureka-server

Cloud com.lee 1.0-SNAPSHOT 4.0.0 cloud-eureka-7001 org.springframework.cloud spring-cloud-starter-eureka org.springframework springloaded org.springframework.boot spring-boot-devtools

Note:

Basically, we are going to introduce a new technical component of cloud, which will have two steps: 1, add a related maven coordinate org.springframework.cloud spring-cloud-starter-eureka-server 2, and mark the relevant annotation label @ EnableEurekaServer @ EnableZuulProxy @ EnableXXXXX on the main startup class to launch the new component.

APPLICATION.YML

Mainly expose eureka ports and external service addresses

Server: port: 7001eureka: instance: hostname: localhost # eureka server instance name client: register-with-eureka: false # false indicates that you do not register yourself with the registry. Fetch-registry: false # false means that the client is the registry, and my responsibility is to maintain the service instance. I do not need to retrieve the service service-url: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ # to set up the address lookup service and registration service that interact with Eureka Server.

Main startup class

Start the class on the server side of package com.lee.cloud;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;//EurekaServer and accept other microservices to register in @ EnableEurekaServer@SpringBootApplicationpublic class EurekaServer7001_App {public static void main (String [] args) {SpringApplication.run (EurekaServer7001_App.class,args);}}

test

Http://localhost:7001 (2), register the existing departmental micro services into the Eureka service center

Modify cloud-provider-dept-8001

POM-add eureka client config configuration Center

Org.springframework.cloud spring-cloud-starter-eureka org.springframework.cloud spring-cloud-starter-config

YML-New eureka service address

Eureka: client: # client registers in the list of eureka services service-url: defaultZone: http://localhost:7001/eureka

Main startup class-added to automatically register this service into the eureka service after startup

@ EnableEurekaClient / / this service will be automatically registered into the eureka service after startup

Test:

1. Start cloud-eureka-70012, start cloud-provider-dept-80013, http://localhost:7001 Note: the microservice name exposed in eureka, that is, the name of spring:application:name in the yml of provider, if the service cannot be found, it is likely to be caused by inconsistent versions of spring-cloud-starter-eureka and org.springframework.cloudspring-cloud-dependenciesDalston.SR1 (3), the information of actuator and registered microservice is improved-host mapping name is modified.

Display in Eureka service

ApplicationAMIsAvailability ZonesStatusCLOUD-DEPTn/a (1) (1) UP (1)-windows10.microdone.cn:cloud-dept:8001

Goal: modify the display of the windows10.microdone.cn:cloud-dept:8001

Cloud-provider-dept-8001 modification:

YML

Eureka: instance: instance-id: cloud-dept8001

Results:

ApplicationAMIsAvailability ZonesStatusCLOUD-DEPTn/a (1) (1) UP (1)-cloud-dept8001 (4), actuator and registered micro-service information perfect-host IP message prompt

When the mouse moves over the upper hyperlink, the link in the lower left corner of the browser displays

Cloud-provider-dept-8001 modification:

YML

Eureka: instance: prefer-ip-address: true # access path can display IP address (5), actuator and registered micro-service information perfect-Info content construction

Cloud-dept8001 knows more about the construction of content after clicking.

Cloud-provider-dept-8001 modification:

POM

Org.springframework.boot spring-boot-starter-actuator

YML

Info: # the content begins with info, followed by app.name: cloud author.name: lee app.function: departmental service provider build.artifactId: $project.artifactId$ build.version: $project.version$

CLOUD parent project POM

Microservicecloud src/main/resources true org.apache.maven.plugins maven-resources-plugin $

Results:

Access: http://192.168.101.39:8001/info shows: {"app": {"name": "cloud", "function": "departmental service provider"}, "author": {"name": "lee"}, "build": {"artifactId": "$project.artifactId$" "version": "$project.version$"}} 3. Eureka cluster configuration

(1) create cloud-eureka-7002 and cloud-eureka-7003 by imitating cloud-eureka-7001

(2) modify the mapping

C:\ Windows\ System32\ drivers\ etc add the following host file: 127.0.0.1 eureka7001.com 127.0.0.1 eureka7002.com 127.0.0.1 eureka7003.com

(3) yml configuration of three eureka services

Eureka: instance: hostname: eureka7001.com # # instance name of eureka server. Knowledge localhost has changed its name. Eureka: client: defaultZone: http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka # # can also be http://localhost:7002/eureka,http://localhost:7003/eureka

(4). Cloud-provider-dept-8001 YML service address modification

Eureka: client: service-url: defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka

Test:

Http://eureka7001.com:7001http://eureka7002.com:7002http://eureka7003.com:7003

4. Eureka self-protection mechanism A micro-service is unavailable at some time, or has not been called for a long time, eureka will not clean up immediately, and the information of the micro-service will still be saved. (network congestion or call timeout) what is self-protection mode? By default, if EurekaServer does not receive the heartbeat of a microservice instance within a certain period of time, EurekaServer will log out the instance (default is 90 seconds). However, when a network partition failure occurs, the micro-service and EurekaServer cannot communicate properly, and this behavior can become very dangerous-- because the micro-service itself is actually healthy, it should not have been unregistered at this time. Eureka solves this problem through "self-protection mode"-when an EurekaServer node loses too many clients in a short period of time (a network partition failure may occur), then the node will enter self-protection mode. Once in this mode, EurekaServer protects the information in the service registry and no longer deletes the data in the service registry (that is, it does not log out any microservices). When the network failure recovers, the Eureka Server node automatically exits self-protection mode. In self-protection mode, Eureka Server protects the information in the service registry and no longer logs out any service instances. When the number of heartbeats it receives returns above the threshold, the Eureka Server node automatically exits self-protection mode. Its design philosophy is that it would rather keep the wrong service registration information than blindly cancel any potentially healthy service instance. In a word, it is better to live than to die. Self-protection mode is a kind of security protection measure to deal with network anomalies. Its architectural philosophy is that it would rather keep all microservices at the same time (both healthy and unhealthy microservices will be retained) rather than blindly cancel any healthy microservices. Using self-protection mode, you can make the Eureka cluster more robust and stable. 5 、 Eureka and Zookeeper compare RDBS (mysql/oracle/sqlserver)-> ACIDNOSQL (redis/mongodb)-> CAP- -ACID: atomicity atomicity, Consistency consistency, isolation independence, durability persistence CAP: consistency strong consistency, availability high availability, Partition tolerance partition fault tolerance- -Eureka complies with AP Zookeeper complies with CP as a service registry Why is Eureka better than Zookeeper? the famous CAP theory points out that a distributed system cannot satisfy C (consistency), A (availability) and P (partition fault tolerance) at the same time. Because partition fault tolerance P must be guaranteed in distributed systems, we can only make a tradeoff between An and C. So Zookeeper guarantees CP and Eureka is AP. 1. Zookeeper guarantees that when CP queries the registry for the list of services, we can tolerate that the registry returns the registration information from a few minutes ago, but cannot accept that the service is directly down unavailable. In other words, the service registration function requires higher availability than consistency. However, there will be such a situation in zk, when the master node loses contact with other nodes because of a network failure, the remaining nodes will re-elect leader. The problem is that the election time of the leader is too long, 30 ~ 120s, and the entire zk cluster is not available during the election, which leads to the paralysis of the registration service during the election. In the cloud deployment environment, it is highly likely that the zk cluster will lose its master node due to network problems. Although the service can eventually be restored, the long-term unavailability of registration caused by a long election time cannot be tolerated. 2. Eureka ensures that AP Eureka understands this, so usability is a priority at design time. All the nodes in Eureka are equal, the failure of several nodes will not affect the work of normal nodes, and the remaining nodes can still provide registration and query services. On the other hand, if the client of Eureka finds that the connection fails when registering with an Eureka, it will automatically switch to another node. As long as an Eureka is still there, the registration service can be guaranteed (availability is guaranteed), but the information found may not be up-to-date (strong consistency is not guaranteed). In addition, Eureka also has a self-protection mechanism. If more than 85% of the nodes do not have a normal heartbeat within 15 minutes, then Eureka believes that there is a network failure between the client and the registry, and the following situations will occur: 2.1. Eureka no longer removes services from the registration list that should have expired because they have not received a heartbeat for a long time. Eureka can still accept registration and query requests for new services. However, it will not be synchronized to other nodes (that is, to ensure that the current node is still available) 2.3.When the network is stable, the new registration information of the current instance will be synchronized to other nodes. therefore, Eureka can well deal with the situation that some nodes lose contact due to network failure, and will not paralyze the entire registration service like zookeeper.

Expand knowledge

# Service Discovery @ AutoWireprivate DiscoveryClient client;List serviceList = client.getServices (); / / list all services in Eureka List instanceList = client.getInstances ("CLOUD-DEPT"); / / find service instance instance.getServiceId (); / / instance IDinstance.getHost (); / / instance host instance.getPort (); / / instance port instance.getUri () / / instance Uri @ EnableDiscoveryClient / / + Service Discovery Notes on the main launch class. Thank you for reading. The above is the content of "Registration method and extension of Eureka Service". After the study of this article, I believe you have a deeper understanding of the registration method and expansion of Eureka Service, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.