Eureka acquaintance and build

I. Overview of service discovery

1, the origin of the service discovery

Service Discovery and Registry (collectively referred to as service discovery), is to follow the way of software development architecture gradually evolved

Early single architecture

For external dependencies, often taken in the form calls the domain interface, such as text transmission interface, and will pass appId appKey corresponding domain name to call, send a text message to complete.

SOA architecture development

Monomers architecture is split into coarse-grained services architecture, then rely on the inside more, how it is invoked between services? In the form of http expose services, the service A deployed on multiple virtual machines, service B to make the call by calling the ip address of the service A: 1, A service of ip maintained by the service B, by configuring nginx's upstream a service of all instances of ip write in, but it also exposed some of the implementation details of the service a and a and B can not be decoupled; 2, B service by calling the internal domain name service a, and all instances by their own service a ip the nginx maintenance.

Micro-era service

Due to the rise docker, leading ip service A is not fixed, so the above approach is more trouble, there are two options: 1, nginx update files at deployment time, using ngx_http_dyups_module go through the rest api's nginx upstream update without the need to reload; 2, the registry service as a standard component information, gateway component obtains instance through the service registry, dynamic routing.

2, Eureka Introduction

What is it Eureka

The explanation given in the official website:

Eureka is a REST (Representational State Transfer) based service that
is primarily used in the AWS cloud for locating services for the
purpose of load balancing and failover of middle-tier servers. We call
this service, the Eureka Server. Eureka also comes with a Java-based
client component,the Eureka Client, which makes interactions with the
service much easier. The client also has a built-in load balancer that
does basic round-robin load balancing. At Netflix, a much more
sophisticated load balancer wraps Eureka to provide weighted load
balancing based on several factors like traffic, resource usage, error
conditions etc to provide superior resiliency.

In fact, it can be summarized in one sentence: Eureka is REST-based services, for location services to implement service discovery and failover Drive intermediate layer

Second, the principle of distributed systems CAP

1. What is the principle of CAP

CAP is the principle of the design principles of distributed systems
C: Consistency strong consistency
A: Availability Availability
P: Partition tolerance partitions fault tolerance
CAP principle means that a maximum of only three elements simultaneously achieve two o'clock, three could not take into account

2, Eureka and compare Zookeeper

Also registered as a service center, we compare the difference between Eureka and Zookeeper (here is not to say what kind of superior, can only say that different scenarios should choose their own components):

Zookeeper choices are CP

Election mechanism Zookeeper used, when the master is not available, we must elect a follower to serve as duty master, but the time of the elections relatively long time, and during this period the entire cluster are in an unusable state, so reach Availability High Availability .

Eureka is selected AP

Eureka all nodes are equal, if not all of the nodes goes down, the request will be transferred to the normal node service, but may obtain instance information is not the latest (self-protection mechanisms), there is no guarantee strong Consistency consistency.

Three, Eureka Architecture Overview

Eureka is based on CS architecture: Eureka server and Eureka client

Four, Eureka's self-protection mechanism

Overall, a micro-services at a time is not available, Eureka does not clear immediately, but will still be saved to the instance of micro-information services.
By default, if Eureka does not receive a heartbeat examples of micro services within a certain time, then the instance will be removed, such behavior is very dangerous, because the micro network service instances may be due to fluctuations the cause can not communicate with Eureka, but this time the service itself is healthy. The self-protection mechanism is to solve this problem, when in Eureka losing too much in a short time when the micro-service instances, goes into self-protection mode, information in the registry is no longer removed until the network is restored to exit the self-protection mode (income the heart rate to reach the threshold value).
Design philosophy: rather reserved error of service registration information, and do not blindly remove any possible health service instance.

Five, Eureka engineering structures

Fairly simple engineering structures

Project structure

pom.xml

<?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>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.example</groupId>
    <artifactId>eureka01</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>eureka01</name>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.RELEASE</spring-cloud.version>
    </properties>

    <dependencies>

        <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>

spring-cloud-starter-netflix-eureka-server引入Eureka Server

Master Boot class Eureka01Application

package com.example.eureka01;

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

@SpringBootApplication
@EnableEurekaServer
public class Eureka01Application {

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

}

Add annotations @EnableEurekaServer in startup class, open Eureka Server

ymal profile

server:
  servlet:
    context-path: /eureka01
  port: 8080

spring:
  application:
    name: eureka

eureka:
  instance:
    prefer-ip-address: true #是否使用ip而不是hostname注册
    instance-id: eureka01
  client:
    #是否向注册中心注册自己,如果不使用defaultZone就必须使用注册参数和检索参数作为高可用配置
    register-with-eureka: true
    #检索服务，eureka的职责是维护服务
    fetch-registry: true
    #是否偏好使用处于相同zone的服务提供者
    prefer-same-zone-eureka: true
    # 可以理解成地区
    region: guangzhou
    #可以理解成可用的机房
    availability-zones:
      #region和zone的对应关系
      guangzhou: zone-1,zone-2
    service-url:
      #eureka server对外暴露的服务注册和服务发现地址
      #defaultZone就是一个可用区域
      #defaultZone: http://localhost:8080/eureka01/eureka/,http://localhost:8081/eureka02/eureka/
      # 分机房
      zone-1: http://localhost:8080/eureka01/eureka/
      zone-2: http://localhost:8081/eureka02/eureka/
  server:
    #是否开启自我保护机制，默认开启
    enable-self-preservation: true

Individual configuration items have comments, more than that, talk about the main zone area and region, region can be understood as the region, while zone can be understood as the engine room, the space in the back will say, of course, can be used directly defaultZone to expose registry address, since I was using register-with-eureka and fetch-registry to do the communication between Eureka, so the two registration centers will be registered with each other.

Project begining

Project address: https: //github.com/IvanChiu0/Eureka

Follow-up

Later there will be two chapters are devoted to talk about: Interpretation of Eureka and Eureka source configuration in detail.