First look at a picture 0. This picture is the official architecture diagram provided by Eureka. The whole picture basically lists the core functions of the entire Eureka. When you want to read the source code of Eureka, you can refer to this picture and the following articles.
EurekaServer
EurekaServer is what we often call the server Eureka server startup can refer to this article EurekaServer automatic assembly and startup process analysis
It maintains a service registry that contains all client information
When the server starts, it does the following things:
- Initiate data synchronization requests to other servers in the cluster: Eureka application registration and cluster data synchronization source code analysis
- Open the thread to clean up expired leases: Eureka client renewal and server-side expired lease cleanup source code analysis
EurekaClient
EurekaClient is the client we often talk about. Eureka client startup can refer to this article: EurekaClient automatic assembly and startup process analysis
The client is bound to the application, and in a sense it is the spokesperson of the application instance in the registry
When the client starts, it does several things:
- Initiate a registration request to the server: Eureka application registration and cluster data synchronization source code analysis
- Open the lease renewal thread: Eureka client renewal and server-side expired lease cleanup source code analysis
- First obtain the full list of available services once and start a thread for timed incremental obtaining: Eureka obtains the source code analysis of the service list
When the service goes offline, it will send an offline notification to the server: Eureka service offline source code analysis
service partition
In the figure, the three EurekaServers are separated by lines. The three us-east-xx on the EurekaServer actually represent the three partitions where the three servers are located.
Why does the concept of partition appear? When the number of users of a project is relatively large, multiple sets of services are generally deployed in multiple computer rooms in multiple cities. In order to avoid network delays, we hope that a service will preferentially call services in the same computer room when conditions permit. In order to achieve this function, Ribbon also provides a load balancing algorithm.
self-protection mode
In order to avoid the solution of network partition failure: Eureka self-protection mode source code analysis