SpringCloud version Hoxton SR5 - Lecture 2: Differences between eureka, Eureka and zookeeper and usage scenarios.

Keywords: Spring Zookeeper Tomcat network

------------------------------------------------ Cute dividing line---------------

Quote what I wrote: SpringCloud version Hoxton SR5 - Lesson 1: Understanding First look at what eureka can do, or its positioning and role in the project.

The functions and functions mentioned before are in plain Chinese, using examples.

 

Technical Term:

eureka What is it?

Eureka is one of Netflix's sub-modules and a core module. There are two components in eureka, one is Eureka Server (a stand-alone project), the other is EurekaClient (our micro-service), which is used to locate services for load balancing and failover of middle-tier servers.It is used to interact with Server and makes the interaction very simple: you only need the service identifier to get the service.

And spring-cloud Relationships:

Spring Cloud encapsulates the Eureka module developed by Netflix for service registration and discovery (Zookeeper can be compared).Eureka uses a C/S design architecture.Eureka Server serves as the service registration function and is the service registration center.Other microservices in the system use Eureka clients to connect to Eureka Server and maintain a heartbeat connection.In this way, the maintainer of the system can use Eureka Server to monitor the normal operation of each micro-service in the system.Some other modules of SpringCloud, such as Zuul, can use Eureka Server to discover other micro-services in the system and execute related logic.

 

My explanation:

Eureka's service registration and discovery (similar to zookeeper's) is to register all microservices that use the Eureka client with the Eureka server and use a heartbeat detection mechanism to bind all microservices to the Eureka server.

Eureka exposes a unified access IP for other microservices with the same functions, but it is not useful to use Eureka alone and access items with IP addresses exposed by eureka. Load balancing must be done with Ribbon, and then IP can be invoked for access. The access technology of IP does not necessarily need to use fegin, httpclient RestTemplate provided by spring is also possible.

The composition and features of eureka:

Next, to elaborate:

To use Eureka, you first need to know its components (two parts):

1. Client: The client is the micro-server we write. Just do a little client configuration for Eureka, which is very simple.

2. Server: The server side is to create a springboot project, introduce the dependency of Eureka, do a little configuration, start the server, can be understood as a little configuration jar package, and then run on the server.His main function is to receive the heartbeat of all clients and save them. When ribbon calls, it gives the service address inside to ribbon to complete the call of load balancing function.

Then you need to know the features of eureka: (these features need to be turned on in the configuration file)

1. Eureka's self-protection mechanism: When 85% of services go down within 15 minutes, Eureka thinks it's having a problem, and Eureka doesn't remove services that don't have a heart beat for a long time, EurekaNew service registration and query requests can still be received, but will not be registered synchronously with other nodes (that is, to ensure that the current node is available). When the network is stable, new registration information for the current instance will be synchronized with other nodes.

2. Clean up the Eureka interval: for example, in a custom time range, if no client heartbeat is detected, the service is excluded.(In the Eureka cluster model, there is no client or server in the strict sense, because the server can also be a client.Cluster mode servers, which are also clients of the cluster, can register with each other for high availability purposes)

3. The server of eureka, or the client, registers itself.This feature does not need to be turned on in single mode (it starts by default)

 

==================================================== Eureka Single Edition========================================
Note the version number: https://cloud.spring.io/spring-cloud-static/Hoxton.SR5/reference/html/ The version is described on the website:

Release Train Version: Hoxton.SR5

Supported Boot Version: 2.2.1.RELEASE 

 

 

Eureak server:

Server-side dependency:
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.8.BUILD-SNAPSHOT</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR5</spring-cloud.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </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>
Server side configuration:
#################################################### Basic Public Configuration #######################################################
server:
  port: 6004


#################################################### stand-alone eureka Server Side Configuration #######################################################
eureka:
  server:  # Configure Server
      enable-self-preservation: true  #Turn on self-protection (when 85% of services fail to detect a heartbeat within 15 minutes, the Eureka server considers itself a problem, does not remove the client's instance of eureka, and still calls normally)
      eviction-interval-timer-in-ms: 6000 #Set the cleanup interval to exclude the instance if no heartbeat from the eureka client is detected within a custom time (unit: default is 60*1000 in milliseconds)
  instance:
    hostname: localhost # Configure the access address for the current service


  client:  # Configure Client
    registerWithEureka: false #Whether to register yourself as a client (default is true, single mode set to false, because it is not necessary)
    fetchRegistry: false  #Whether registration information needs to be obtained from the server (default is true, single mode set to false, because it is not necessary)
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka


spring:
  application:
    name: server-eureka-stand #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)
Server startup code:
package com.springcould;

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

/**
 * @author: wangqinmin
 * @date : 2020/6/10
 * @description: When I go out laughing to heaven, am I a Artemisia annua
 */
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {

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

 

Eureka client:

Client dependency:
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.8.BUILD-SNAPSHOT</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR5</spring-cloud.version>
    </properties>

    <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-client</artifactId>
    </dependency>

    <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>
Client Configuration:
#################################################### Basic Public Configuration #######################################################
server:
  port: 8000  # Configure Project Access Port
  tomcat:
    uri-encoding: UTF-8   # Configure tomcat startup encoding
    max-threads: 1000     # Configure tomcat maximum access default 200
    min-spare-threads: 30 # Configure tomcat minimum access default 10

#################################################### eureka Client Configuration #######################################################
eureka: # Note that the following time settings take effect when the network is unstable, but if you manually close the client instance of eureka, you will send information directly to the Eureka server and close the service registered in Eureka
  client:
    serviceUrl:
      defaultZone: http://localhost:6004/eureka/#Register address provided by the Eureka server for single machine configuration, referring to defaultZone property value configured by the server (that is, register the Eureka client with the Eureka server)
  instance:
    instance-id: client-login-1 #This instance is registered with the unique instance ID of the eureka server (that is, it assigns an ID to the current project, which is registered with the eureka server when the current project is running)
    prefer-ip-address: true #Whether to display IP address
    leaseRenewalIntervalInSeconds: 30 #How long does a eureka client need to send a heartbeat to the Eureka server to indicate that it is still alive, defaulting to 30 seconds (in seconds as configured below)
    leaseExpirationDurationInSeconds: 90 #How long does the Eureka server wait to delete an instance after receiving its last heartbeat, defaulting to 90 seconds

spring:
  application:
    name: server-login #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)
Client startup code:
package com.springcloud;

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

/**
 * @author: wangqinmin
 * @date : 2020/6/10
 * @description: When I go out laughing to heaven, am I a Artemisia annua
 */
@SpringBootApplication
@EnableEurekaClient
public class LoginApplication {

    public static void main(String[] args) {
        SpringApplication.run(LoginApplication.class);
    }

}

Depending on the configuration of the server, the access address is:http://localhost:6004 After 2 startups, you can see that the server-login service is registered with the server side of eureka.

 

================================================== Eureka Cluster Edition========================================

The dependency and startup code for cluster mode is the same as for single-machine mode.
The only difference is configuration.
Configuration of server side in cluster mode, I use three as clusters, paste out the configuration to compare and see how different each configuration is under the cluster, I also write a comment:

------------------------------>First:

#################################################### Basic Public Configuration #######################################################
server:
  port: 6001


#################################################### eureka Server Side Configuration #######################################################
eureka:
  server:  # Configure Server
      enable-self-preservation: true  #Turn on self-protection (when 85% of services fail to detect a heartbeat within 15 minutes, the Eureka server considers itself a problem, does not remove the client's instance of eureka, and still calls normally)
      eviction-interval-timer-in-ms: 6000 #Set the cleanup interval to exclude the instance if no heartbeat from the eureka client is detected within a custom time (unit: default is 60*1000 in milliseconds)
  instance:
    hostname: wangqinmin.com # Configure the current service address, which cannot be duplicated in cluster mode (e.g., three servers in a cluster, in the case of native testing: one localhost, one 127.0.0.1 and one mapping configured by the hosts system)


  client:  # Configure Client
    serviceUrl:
      defaultZone: http://127.0.0.1:6002/eureka,Http://localhostThe 6003/eureka #cluster does not configure the ip of the current Eureka server, which completes the mutual registration of the Eureka server.


spring:
  application:
    name: server-eureka-cluster #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)




------------------------------>The second:

#################################################### Basic Public Configuration #######################################################
server:
  port: 6002


#################################################### eureka Server Side Configuration #######################################################
eureka:
  server:  # Configure Server
      enable-self-preservation: true  #Turn on self-protection (when 85% of services fail to detect a heartbeat within 15 minutes, the Eureka server considers itself a problem, does not remove the client's instance of eureka, and still calls normally)
      eviction-interval-timer-in-ms: 6000 #Set the cleanup interval to exclude the instance if no heartbeat from the eureka client is detected within a custom time (unit: default is 60*1000 in milliseconds)
  instance:
    hostname: 127.0.0.1 # Configure the current service address, which cannot be duplicated in cluster mode (e.g., three servers in a cluster, in the case of native testing: one localhost, one 127.0.0.1 and one mapping configured by the hosts system)


  client:  # Configure Client
    serviceUrl:
      defaultZone: http://localhost:6003/eureka,http://wangqinmin.com:6001/eureka #cluster does not configure its own ip, this configuration can complete the mutual registration of Eureka servers.For example, if 6001 and 6002 are down, 6003 can register 6001 and 6002.This completes high availability.


spring:
  application:
    name: server-eureka-cluster #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)


------------------------------>Third:

#################################################### Basic Public Configuration #######################################################
server:
  port: 6003


#################################################### eureka Server Side Configuration #######################################################
eureka:
  server:  # Configure Server
      enable-self-preservation: true  #Turn on self-protection (when 85% of services fail to detect a heartbeat within 15 minutes, the Eureka server considers itself a problem, does not remove the client's instance of eureka, and still calls normally)
      eviction-interval-timer-in-ms: 6000 #Set the cleanup interval to exclude the instance if no heartbeat from the eureka client is detected within a custom time (unit: default is 60*1000 in milliseconds)
  instance:
    hostname: localhost # Configure the current service address, which cannot be duplicated in cluster mode (e.g., three servers in a cluster, in the case of native testing: one localhost, one 127.0.0.1 and one mapping configured by the hosts system)


  client:  # Configure Client
    serviceUrl:
      defaultZone: http://wangqinmin:6001/eureka,http://127.0.0.1:6002/eureka #cluster does not configure its own ip, this configuration can complete the mutual registration of Eureka servers.For example, if 6001 and 6002 are down, 6003 can register 6001 and 6002.This completes high availability.


spring:
  application:
    name: server-eureka-cluster #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)
The client configuration is the same.
//A set of code to deploy multiple micro-services with the same configuration.


//The configuration is as follows:
#################################################### Basic Public Configuration #######################################################
server:
  port: 8000  # Configure Project Access Port
  tomcat:
    uri-encoding: UTF-8   # Configure tomcat startup encoding
    max-threads: 1000     # Configure tomcat maximum access default 200
    min-spare-threads: 30 # Configure tomcat minimum access default 10

#################################################### eureka Client Configuration #######################################################
eureka: # Note that the following time settings take effect when the network is unstable, but if you manually close the client instance of eureka, you will send information directly to the Eureka server and close the service registered in Eureka
  client:
    serviceUrl:
      defaultZone: http://wangqinmin.com:6001/eureka,http://127.0.0.1:6002/eureka,http://localhost:6003/eureka #cluster configuration
              # Register the client side of this project into all the servers, in order to prevent the server from not registering itself
              #(Normally, this is not a problem, even if some people don't know eureka and randomly configure cluster servers, so this is the safest way to do it. If you follow the configuration of my servers, this will not happen.)
              # The reason for the problem is that the self-registration configuration is turned off manually.
              # Another disadvantage of this configuration is that services that are not connected will continuously fail in the log
  instance:
    instance-id: client-login-1 #This instance is registered with the unique instance ID of the eureka server (that is, it assigns an ID to the current project, which is registered with the eureka server when the current project is running)
    prefer-ip-address: true #Whether to display IP address
    leaseRenewalIntervalInSeconds: 30 #How long does a eureka client need to send a heartbeat to the Eureka server to indicate that it is still alive, defaulting to 30 seconds (in seconds as configured below)
    leaseExpirationDurationInSeconds: 90 #How long does the Eureka server wait to delete an instance after receiving its last heartbeat, defaulting to 90 seconds

spring:
  application:
    name: server-login #The instance is registered with the name of the eureka server (in cluster mode: microservices with the same functionality must have the same name, since all microservices are invoked directly with this name when load balancing is invoked)

Then start.

 

Next, let's say the difference between Eureka and zookeeper. When do you use eureka?When do I use zookeeper?

The main differences are: principle problem, CAP theorem.

In 1998, Eric Brewer, a computer scientist at the University of California, proposed that distributed systems have three indicators.

Consistency - Consistency
 Availability - Availability
 Partition tolerance - Partition fault tolerance

Their first letters are C,A,P
 Eric Brewer says these three indicators cannot be achieved at the same time.This conclusion is called the CAP theorem.

P can be guaranteed, so both Eureak and zookeeper have P, but C and A cannot have both.

 

Consistency. C:

Zookeeper is designed to follow the CP principle of consistency.Zookeeper has such a situation that when master node loses contact with other nodes due to network failure, the remaining nodes will re-elect the leader. The problem is that the time to elect the leader is too long: 30-120s, and the entire Zookeeper cluster is not available during the election, but the zookeeper is to ensure that all nodes are available before the service can be invoked properly.This results in paralysis of registration services during the election. In cloud deployed environments, loss of master nodes for the Zookeeper cluster due to network environments is a relatively common occurrence. Although services can ultimately be restored, the long election period makes long-term service registration unavailable.Ultimately, the system paralyses for a period of time.

Availability A:

Eureka is designed to follow AP principles, that is, usability.Eureka nodes (services) are equal, there is no master-slave division, several nodes down will not affect the normal operation, the remaining nodes (services)Registration and query services are still available, and when a client of Eureka registers with an Eureka or discovers a connection failure, it automatically switches to another node, that is, it can register as long as one Eureka is still available (guarantees availability).In this case, at most, some micro-service interfaces may not be tunable, but the entire distributed architecture is still functioning properly, and Eureka will exclude unavailable services, resulting in all services available, combined with hystrix degradation capabilities integrated by springcloud or zool filtering capabilities, all of which will be resolved.

When do you use eureka?When do I use zookeeper?

Example: For example, on Taobao Day, thousands of visitors came in. Do we use eureka or zookeeper?For example, if zookeeper was used, and the zookeeper node hung up when it was snapped up at 00:00 p.m. that night, would we wait for zookeeper to re-elect a new leader?Think of it as a complication. If zookeeper keeps voting for Taobao Festival at 00:00-00:30 due to network fluctuations?Of course, this is almost nonexistent, and zookeeper is still competent, just ideal.As an architect, however, you need to prioritize availability in your choice.

Under what circumstances can you consider using zookeeper?Zookeeper can be used on distributed locks in addition to service registration and discovery, ensuring data accuracy, but eureka is recommended for service registration and discovery.

 

Posted by Dilbert137 on Thu, 18 Jun 2020 18:59:31 -0700