Spring Cloud distributed micro-service Cloud architecture Source Analysis-eureka

Before looking at the specific source code, we first review what we have achieved before, so we can find a suitable cut-in to analyze. First, the three main elements of service registries, service providers, and service consumers, the latter (i.e., the Eureka Client) are the active initiators of most of the communication behavior throughout the operating mechanism, and the registry is primarily the recipient of the request. So, we can look at the Eureka client as the portal to see how it accomplishes these active communication behaviors.

When we register a normal spring boot app with Eureka Server, or get a list of services from Eureka Server, there are two main things:

@enablediscoveryclient annotations are configured in the main class of the application
The location of the service registry is specified in Application.properties with the Eureka.client.serviceUrl.defaultZone parameter
Follow the above clues, we first look at the @enablediscoveryclient source code as follows:

/** * Annotation to enable a DiscoveryClient implementation. * @author Spencer Gibb */@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import(EnableDiscoveryClientImportSelector.class)public @interface EnableDiscoveryClient {}

From the note we can tell that this annotation is used to open an instance of discoveryclient. By searching for discoveryclient, we can find a class and an interface. The relationship can be obtained by combing:

The org.springframework.cloud.client.discovery.DiscoveryClient on the left is the interface of Spring Cloud, which defines the common abstract methods used to discover services. And Org.springframework.cloud.netflix.eureka.EurekaDiscoveryClient is the implementation of the interface, from the name can be judged, it is to achieve the Eureka Discovery Service encapsulation. So Eurekadiscoveryclient relies on Eureka's Com.netflix.discovery.EurekaClient interface, Eurekaclient inherits the Lookupservice interface, which is the content of the Netflix open source package, which The main definition is the abstraction of the discovery service for Eureka, and the Com.netflix.discovery.DiscoveryClient class in the Netflix package is the real implementation of the discovery service.

Well, let's take a look at the Discoveryclient class in detail. First of all, the comments on the head of the class have a general understanding, the general content of the comments are as follows:

This class is used to help collaborate with Eureka Server.

The Eureka client is responsible for the following tasks:

• Registering a service instance with the Eureka server
• Renew a lease to Eureka Server
• Canceling leases to Eureka Server during service shutdown
• Querying the list of service instances in Eureka Server

The

Eureka client also needs to configure a list of URLs for the Eureka server.
Before we specifically study Eureka client-specific tasks, let's take a look at where the URL list for Eureka Server is configured. Based on the property name we configured: Eureka.client.serviceUrl.defaultZone, we find the load properties related to this property by Serviceurl, but they are @deprecated labeled in the SR5 version. And in the gaze you can see that @link to the alternative class com.netflix.discovery.endpoint.EndpointUtils, we can find the following function in this class:

public static Map<String, List<String>> getServiceUrlsMapFromConfig(            EurekaClientConfig clientConfig, String instanceZone, boolean preferSameZone) {    Map<String, List<String>> orderedUrls = new LinkedHashMap<>();    String region = getRegion(clientConfig);    String[] availZones = clientConfig.getAvailabilityZones(clientConfig.getRegion());    if (availZones == null || availZones.length == 0) {        availZones = new String[1];        availZones[0] = DEFAULT_ZONE;    }    ……    int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones);    String zone = availZones[myZoneOffset];    List<String> serviceUrls = clientConfig.getEurekaServerServiceUrls(zone);    if (serviceUrls != null) {        orderedUrls.put(zone, serviceUrls);    }    ……    return orderedUrls;}

Region, Zone
In the above function, we can find that the client loaded two items sequentially, the first one is region, the second is zone, from which we can judge the relationship between them:

With the Getregion function, we can see that it reads a region back from the configuration, so a microservices application can belong to only one region, and defaults to default if not specifically configured. If we want to set it ourselves, we can define it by the Eureka.client.region property.

public static String getRegion(EurekaClientConfig clientConfig) {    String region = clientConfig.getRegion();    if (region == null) {        region = DEFAULT_REGION;    }    region = region.trim().toLowerCase();    return region;}

With the Getavailabilityzones function, we can know that when we do not specifically configure zone for region, we will default to Defaultzone. This is also the origin of our previous configuration parameter Eureka.client.serviceUrl.defaultZone. To specify a zone for an app, we can set it by using the Eureka.client.availability-zones property. From the return content of the function, we can have a zone that can have multiple, and is configured by commas. Thus, we can judge that region is a one-to-many relationship with zone.

public String[] getAvailabilityZones(String region) {    String value = this.availabilityZones.get(region);    if (value == null) {        value = DEFAULT_ZONE;    }    return value.split(",");}

Serviceurls
The exact address of the Eureka server is only started after the region and zone information has been obtained. It determines in which zone configuration the Serviceurls is loaded, based on the parameters passed in by an algorithm.

int myZoneOffset = getZoneOffset(instanceZone, preferSameZone, availZones);String zone = availZones[myZoneOffset];List<String> serviceUrls = clientConfig.getEurekaServerServiceUrls(zone);

To get the implementation of Serviceurls, we can view the concrete implementation class Eurekaclientconfigbean of geteurekaserverserviceurls function in detail, This class is an implementation of the Eurekaclientconfig and Eurekaconstants interfaces, which is used to load the contents of the configuration file, and there is a lot of useful information here, let's start with the information we care about here, about Defaultzone. By searching the Defaultzone, we can easily find the following function, it is implemented, how to parse the parameters of the process, through this content, we can know, The Eureka.client.serviceUrl.defaultZone property can be configured with more than one, and it needs to be separated by commas.

public List<String> getEurekaServerServiceUrls(String myZone) {    String serviceUrls = this.serviceUrl.get(myZone);    if (serviceUrls == null || serviceUrls.isEmpty()) {        serviceUrls = this.serviceUrl.get(DEFAULT_ZONE);    }    if (!StringUtils.isEmpty(serviceUrls)) {        final String[] serviceUrlsSplit = StringUtils.commaDelimitedListToStringArray(serviceUrls);        List<String> eurekaServiceUrls = new ArrayList<>(serviceUrlsSplit.length);        for (String eurekaServiceUrl : serviceUrlsSplit) {            if (!endsWithSlash(eurekaServiceUrl)) {                eurekaServiceUrl += "/";            }            eurekaServiceUrls.add(eurekaServiceUrl);        }        return eurekaServiceUrls;    }    return new ArrayList<>();}

When a client selects an instance for access in the list of services, it follows the rules for zone and region: give priority access to the instance in the same zone as yourself, and then access the instances in the other zone. With the two-level definition of region and zone and the physical structure of actual deployment, we can effectively design a fault-tolerant cluster of regional failures.
Source source technical support for complete projects 1791743380

Spring Cloud distributed micro-service Cloud architecture source code Analysis-eureka