This is what you need Eureka!

Personal blog navigation page (click on the right link to open a personal blog): Daniel take you on technology stack 

First, what is Eureka

Eureka is an open source Netflix company's products, it is based on REST (Representational State Transfer) services, mainly for the AWS cloud. Eureka provides a complete Service Registry and Service Discovery achieve realization, Spring is one of the most important Cloud system components.

In simple terms Eureka open source Netflix is ​​a service registration and discovery products, and provides a java client. Of course, Eureka after springcloud efforts to improve, can be used in any scenario requires the use of registry.

Eureka consists of two components: Eureka Eureka server and client. Eureka is the registry server. Eureka is a client java client, to simplify the interaction with the server, the load balancer as polling, to provide failover for the service and support.

Here is the Eureka usage scenarios

Viewed from above Eureka Server role as registry, providing discovery and registration functions and services.

Service Provider service providers, their services will be registered to Eureka Server, while checking the heartbeat by running state services.

Service Consumer service the caller, get a list of registered service from Eureka Server, find the address of the corresponding service calls and use.

Two, Eureka core concepts

1, Eureka Server: registry server

Registration of foreign central server provides three main functions:

(1) Service Registration

When the service provider starts, it will register through Eureka Client to Eureka Server Information, Eureka Server will store information on this service, two-story Eureka Server internal caching mechanism to maintain the entire registry.

(2) provide registry

Service consumer to invoke a service, if no cache Eureka Client registry, it will get the latest registry from Eureka Server.

(3) Synchronization Status

Eureka Client By registering, Eureka Server heartbeat mechanism and synchronize the current status of the client.

2, Eureka Client: Client Registry

Eureka Client is a java client for simplifying interaction with the Eureka Server. Eureka Client will pull, update, cache information in Eureka Server. So when all of Eureka Server nodes shoot down, service consumers can still use the information in the cache to find the provider of the service, but there will be inconsistent information when the service has changed.

3, Register: Registration Service

Service providers, will register itself into the registry, the service provider is also a Eureka Client. When Eureka Client to register with the Eureka Server, which provides its own metadata, such as IP addresses, ports, operational status indicator URL, home and so on.

4, Renew: Service contract

Eureka Client sends a heartbeat to renew every 30 seconds. To inform Eureka Server through the renewal of the Eureka Client operating normally, no problems. By default, if Eureka Server does not receive Eureka Client renewal within 90 seconds, Server-side will be deleted from the registry instance, can be configured for this event, generally not recommended to change.

5, Eviction Service removed

When Eureka Client and Eureka Server no longer have a heartbeat, Eureka Server service instance will be deleted from the list of registered service, a service removed.

6, Cancel: service offline

Eureka Client would like Eureka Server to send a cancellation request, after sending the request, the client instance registry information from Eureka Server instance is deleted when the program is closed. The request will not automatically off the assembly line, it needs to be called at the contents:

DiscoveryManager.getInstance().shutdownComponent();

7, GetRegistry: obtain registration list information

Eureka Client Registry to obtain information from the server, and caches it locally. The client will use this information to find additional services to make remote calls. The registration list is updated information on a regular basis (every 30 seconds). Every return a list of registration information may differ from the cache of information Eureka Client, Eureka Client automatically.

If for some reason the registration information list information can not be timely match, Eureka Client will re-acquire the entire registry information. Eureka Server cache registration list information, as well as the entire registry information for each application is compressed, compressed content and the content is not exactly the same compression. Eureka Client and Eureka Server can communicate using JSON / XML format. By default Eureka Client JSON compression using the information to obtain registration forms list.

8, Remote Call: remote call

When Eureka Client acquired from the registration center to the service provider information, you can call the corresponding service via HTTP requests; there are multiple service providers, Eureka Client client automatically automatic load balancing Ribbon.

Third, the self-protection mechanism

By default your money, if Eureka Server does not receive a heartbeat micro service instances within 90 seconds, will cancel the instance. But in the micro-architecture are usually cross-process service calls between services, network communications are often faced with many problems, such as micro-service status is normal, the network partition fails, resulting in this instance was canceled.

Numerous examples are written off within a fixed period of time, could seriously threaten the availability of a micro-service architecture, in order to solve this problem, Eureka has developed a self-protection mechanism, then what is self-protection mechanism?

Eureka Server during operation will fail to count heartbeats ratio is below 85% within 15 minutes, if less than 85%, Eureka Server enter into self-protection mechanism.

After Eureka Server self-protection mechanism is triggered, the page will be prompted:

Eureka Server into the self-protection mechanism, the following situations:

(1) Eureka no longer be removed because for a long time and should not receive heartbeat expired registration service from the list.

(2) Eureka still be able to accept new registration and inquiry services, but will not be synchronized to (that is, to ensure that the current node is still available) on other nodes.

(3) When the network is stable, the current instance of the new registration information is synchronized to the other nodes.

Eureka is a mechanism of self-protection mechanism to prevent manslaughter service provided. When individual clients appear heartbeat lost contact, then that is the client's problem, remove the client; when Eureka captured a lot of heart failure, then that might be a network problem, into the self-protection mechanism; when a client heartbeat recovery, Eureka will automatically exit the self-protection mechanism.

If the service provider just off the assembly line in a non-normal protection period, the Service consumers will get a valid service instance, failure is called. For this problem requires service consumers have some fault-tolerant mechanisms such as retries, circuit breakers.

Four, Eureka High Availability Cluster

In theory, the service consumer local cache address of the service provider, even if Eureka Server goes down, it will not affect calls between the service, but when it comes to the service offline, the local cache information will appear deviation, affect the stability of the whole micro-services, so build Eureka Server clusters to improve the high availability of the entire architecture, it is very necessary.

As can be seen from the figure between Eureka Server Cluster Replicate to synchronize data with each other through, does not distinguish between the master node and each slave node, all nodes are equal. In this architecture, each registered increase the availability of nodes to each other, each node needs to add one or more links to other nodes serviceURL valid.

If a station Eureka Server downtime, Eureka Client requests automatically switches to the new Eureka Server node. When the server downtime restored, Eureka will again be incorporated into the server cluster management. When the node starts to accept client requests, all operations will be replicated between nodes, the request to all nodes other currently known in Eureka Server.

Also follow Eureka Server synchronization is a very simple principle: as long as there is an edge node connection, you can synchronize information and dissemination. So, if there are multiple nodes, between the nodes only need to be joined in pairs to form a passage, the other information can be shared registry. But also the Eureka Client, between multiple Eureka Server is accomplished via a P2P service registry synchronize each Eureka Server.

State between Eureka Server cluster is using asynchronous synchronization, there is no guarantee the state between nodes must be the same, but can basically guarantee the final state is the same.

Five, Eureka partition

Eureka provides the Region and Zone to partition two concepts:

 Region: it can be understood as different regions geographically, such as Asia, in China, Dalian and so on. There is no limit specific size. According to the project specific circumstances, it can be self rational division Region.

Zone: can be simply understood as a specific room within the region, such as region is divided into Dalian, Dalian has two rooms, you can divide the region again under zone1, zone2 two zone.

Six, Eureka assurance AP

Eureka Server each node are equal, hang a few nodes will not affect the normal node, the remaining nodes can still provide registration and inquiry services. And Eureka Client when registering a the Eureka, if it is found the connection fails, it will automatically switch to other nodes. As long as there is still a Eureka Server, you can guarantee registration services are available (to ensure availability), but found the information may not be current (not guarantee strong consistency).

Seven, Eureka workflow

1, Eureka Server starts successfully, wait for the server to register.

During startup If you configure the cluster, through the Replicate registry synchronization between clusters, each Eureka Server exists independent full service registry information.

2, Eureka Client to start the registry based on the configuration of Eureka Server address registration services.

3, Eureka Client sends a heartbeat to Eureka Server every 30 seconds to prove that client service is normal.

4, when the inner Eureka Server90 seconds Eureka Client does not receive a heartbeat, the registry is considered node fails, the instance will be written off.

5, unit time Eureka Server statistics to a large number of Eureka Client does not send a heartbeat, it is considered possible for the network anomaly, into the self-protection mechanism, no longer sending heartbeat excluding client.

6, when the Eureka Client heartbeat returned to normal, Eureka Server automatically exit the self-protection mechanism.

7, Eureka Client full amount or timing of incremental access to services registry from the registry, and the acquired information is cached locally.

8, when a service call, Eureka Client will start the local cache to find and obtain services. If you can not get, starting with registration center refresh the registry, and then synchronized to the local cache.

9, Eureka Client to the target server to obtain information, initiate a service call.

10, Eureka Client sends to the closed Eureka Server cancellation request, Eureka Server instance removed from the registry.

Eight, Eureka Server data storage

Eureka Server data storage into two layers: data storage layer and the buffer layer.

Register to record the data storage layer service information on Eureka Server, data caching layer is the result of the packaging, it can be returned directly at the Eureka Client calls.

Eureka Server data storage layer is double ConcurrentHashMap, we know ConcurrentHashMap is thread safe and efficient Map collection.

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

ConcurrentHashMap first layer key = spring.application.name application name is registered client instance; value is nested ConcurrentHashMap.

Nested ConcurrentHashMap key = instanceId second layer is the only instance of the service id, value of the object Lease, Lease object store registration information of all of this example, including IP, port, and other properties.

According to this storage structure we can find, Eureka Server is the first layer stores all the service name, service name corresponding to the information and examples, that the first layer is applied in accordance with the service name of this dimension to segmentation store:

应用名1:应用1实例 Map
应该名2:应用2实例 Map
...

The second layer is an example of the unique ID is stored, then the final memory structure according to this data format is:

                :  应用1实例A:实例A的注册信息 
应用名1:应用1实例:  应用1实例B:实例B的注册信息 
                :  应用1实例C:实例C的注册信息
                :  ....
-----------------              
                :  应用2实例F:实例F的注册信息 
应该名2:应用2实例:  应用2实例G:实例G的注册信息 
                :  ... 

...

Data storage layer data structure as shown below:

When such as the status of the service changed, synchronizes registry data in Eureka Server information, such as registration services, while excluding service.

Nine, Eureka cache mechanism

Eureka Server in order to provide the response efficiency, a two-layer structure of the cache, the registration information needed Eureka Client directly stored in the cache structure.

The first level cache: readOnlyCacheMap, essentially ConcurrentHashMap, data dependent timing synchronization from readWriteCacheMap, the default time of 30 seconds.

readOnlyCacheMap: CurrentHashMap is a read-only cache. This is mainly used in order for the client to obtain registration information, updates its cache, depending on the update timer, and readWriteCacheMap made by comparing the values, if the data is inconsistent, places data readWriteCacheMap prevail.

Second-level cache: readWriteCacheMap, is essentially Guava cache.

readWriteCacheMap: readWriteCacheMap primary synchronization data in the storage layer. Determining whether or not the cache when the acquired data in the buffer, if the data does not exist, to load by the load method CacheLoader, after loading the data into the cache successfully, along with the data.

readWriteCacheMap cache expiration time, the default is 180 seconds when the service offline, the data in this cache expiration, registration, status changes, will be cleared.

When the total amount of acquired Eureka Client or increment data acquisition will start a buffer; if one does not exist in the cache, and then from the secondary cache acquires; if there is no secondary cache, this time the first storage layer synchronizing data cache, then acquires from the cache.

Layer Eureka Server by the caching mechanism, can be very effective to enhance the response time of the Eureka Server by the data storage layer and the buffer layer is cut to provide different data support according to usage scenarios.

Ten, code examples

1. Project framework:

2, Eureka server application.yml

server:
  port: 9000
eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false
    fetch-registry: false
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
    instance:
      prefer-ip-address: true

3, client startup class

package cn.itcast.product;

...

@SpringBootApplication
@EntityScan("cn.itcast.product.entity")
@EnableEurekaClient
public class ProductServiceApplication {
   public static void main(String[] args) {
      SpringApplication.run(ProductServiceApplication.class, args);
   }
}

4, some basic controller, service, bean not write, using a database spring data jpa way queries.

5, start the service

Eureka Server --> Eureka Providor --> Eureka Consumer

Eureka Server

6, Eureka Consumer calling services

XI summary

Explain the core concept of Eureka, Eureka self-protection mechanism, Eureka high availability clusters. By analyzing the principle of Eureka, Eureka can clearly feel the ingenious design, through a series of mechanisms, the perfect solution to the registry of stability and high availability.

Eureka order to protect the registry of high availability, non-tolerant strong data consistency, data service node may be inconsistent data between Eureka Client may be inconsistent. More suitable span multiple rooms, service availability for registry demanding usage scenarios.

Attached Java / C / C ++ / machine learning / Algorithms and Data Structures / front-end / Android / Python / programmer reading / single books books Daquan:

(Click on the right to open there in the dry personal blog): Technical dry Flowering
===== >> ① [Java Daniel take you on the road to advanced] << ====
===== >> ② [+ acm algorithm data structure Daniel take you on the road to advanced] << ===
===== >> ③ [database Daniel take you on the road to advanced] << == ===
===== >> ④ [Daniel Web front-end to take you on the road to advanced] << ====
===== >> ⑤ [machine learning python and Daniel take you entry to the Advanced Road] << ====
===== >> ⑥ [architect Daniel take you on the road to advanced] << =====
===== >> ⑦ [C ++ Daniel advanced to take you on the road] << ====
===== >> ⑧ [ios Daniel take you on the road to advanced] << ====
=====> > ⑨ [Web security Daniel take you on the road to advanced] << =====
===== >> ⑩ [Linux operating system and Daniel take you on the road to advanced] << = ====

There is no unearned fruits, hope you young friends, friends want to learn techniques, overcoming all obstacles in the way of the road determined to tie into technology, understand the book, and then knock on the code, understand the principle, and go practice, will It will bring you life, your job, your future a dream.

Published 47 original articles · won praise 0 · Views 267

Guess you like

Origin blog.csdn.net/weixin_41663412/article/details/104893065