Article From:https://www.cnblogs.com/junjiang3/p/9061867.html

1. Background

In general, there are multiple computer rooms with relatively large users or wide geographical distribution of users. At this time, if the springCloud service is on line, we hope that the service in a computer room will call the services in the same computer room first.

,When the service of the same computer room is not available, the service of other computer rooms will be invoked to reduce the delay.

Two. Concept

eurekaTwo concepts, region and zone, are provided for partitioning. These two concepts all come from Amazon’s AWS:

(1)region:It can be simply interpreted as geographical zoning, such as the Asian region, or North China, or Beijing and so on. There is no specific size restriction. According to the specific circumstances of the project, region can be reasonably divided.

(2)zone:It can be simply understood as the specific machine room in region, for example, region is divided into Beijing, and then Beijing has two machine rooms, which can be divided into Zone1, zone2 and two zone under this region.

Three, partition service deployment architecture diagram

As shown in the figure above, there is a region:beijing, with two partitions of zone-1 and zone-2 below, each with a registry Eureka Server and a service provider Service. We create one within zone-1

Consumer-1If you serve the consumer, it will give priority to calling Service-1 in the same zone. When Service-1 is not available, the Service-2 in zone-2 will be called.

Four. Examples

(1)Eureka Server-1:

spring:
  application:
    name: Server-1
server:
  port: 30000
eureka:
  instance:
    prefer-ip-address: true
    status-page-url-path: /actuator/info
    health-check-url-path: /actuator/health
    hostname: localhost
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-1,zone-2
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

(2)Eureka Server-2:

spring:
  application:
    name: Server-2
server:
  port: 30001
eureka:
  instance:
    prefer-ip-address: true
    status-page-url-path: /actuator/info
    health-check-url-path: /actuator/health
    hostname: localhost
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-2,zone-1
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

(3)Service1

Test code

@RestController
public class HiController {
    @Value("${zone.name}")
    private String zoneName;
    
    @RequestMapping(value = "/hi", method = RequestMethod.GET)
    public String hi() {
        return zoneName;
    }
}

configuration file

spring:
  application:
    name: service
server:
  port: 30010
eureka:
  instance:
    prefer-ip-address: true
    status-page-url-path: /actuator/info
    health-check-url-path: /actuator/health
    metadata-map:
      zone: zone-1
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-1,zone-2
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

zone.name: zone-1

(4)Service2

spring:
  application:
    name: service
server:
  port: 30011
eureka:
  instance:
    prefer-ip-address: true
    status-page-url-path: /actuator/info
    health-check-url-path: /actuator/health
    metadata-map:
      zone: zone-2
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-2,zone-1
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

zone.name: zone-2

(5)Consumer-1

Test code

@RestController
public class HiController {
    @Autowired
    private RestTemplate restTemplate;

    @RequestMapping(value="/consumer")
    public String hi() {
        return restTemplate.getForObject("http://service/hi", String.class);
    }
}

configuration file

spring:
  application:
    name: consumer
server:
  port: 30030
eureka:
  instance:
    prefer-ip-address: true
    status-page-url-path: /actuator/info
    health-check-url-path: /actuator/health
    metadata-map:
      zone: zone-1
  client:
    register-with-eureka: true
    fetch-registry: true
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-1,zone-2
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

Five. Detailed explanation of the configuration file

The whole partition is divided into two steps:

(1)Service registration: to ensure that the service is registered in the same zone registration center, because if registered to the registration center of the other zone, the network delay is relatively large, and the heartbeat detection is likely to be a problem.

(2)Service invocation: to ensure that the services in the same zone are called first, the service of other zone is called only when the service in the same zone is not available.

1、Configuration file for service registration

eureka:
  client:
    prefer-same-zone-eureka: true
    #region    region: beijing
    availability-zones:
      beijing: zone-1,zone-2
    service-url:
      zone-1: http://localhost:30000/eureka/
      zone-2: http://localhost:30001/eureka/

When a service (as a eureka client) registers with the Eureka server, it will register according to the configuration under eureka.client. Here, we are mainly concerned about the situation where there are multiple registries.

Which Registry does it go to, and with which registry to maintain heartbeat detection? Registry selection logic:

(1)If prefer-same-zone-eureka is false, register according to the first registration center of list under service-url and maintain heartbeat detection with it. It will not register and maintain heartbeat to any other registry in list. onlyThere are in the first

When a registration fails, the registration will be registered with other registries in turn, and the total retrial is 3 times. If the 3 service-url is not registered successfully, the registration fails. Every other heartbeat time will try again.

(2)If prefer-same-zone-eureka is true, the first zone in the availability-zones is taken by region, and then the list under the service-url is taken through this zone, andThe first registry in list is registered

And maintain heartbeat, no longer register and maintain heartbeat to other registries in list. Only when the first registration fails, will it be registered with other registries in a row. A total of 3 attempts will be repeated, if 3 service-url are not registered.

Work, the registration failed. Every other heartbeat time will try again.

Therefore, in order to ensure the registration of services to the same zone registry, we must pay attention to the order of availability-zones, and we must write the same zone in front.

2、Configuration file for service invocation

eureka:
  instance:
    metadata-map:
      zone: zone-1

Which zone of service consumers and service providers belong to is determined by eureka.instance.metadata-map.zone. Service consumers will first pull a list of service providers through the ribbon to the registry, then pass through.

The zone specified by the eureka.instance.metadata-map.zone is filtered and then called if there are multiple instances of the same service provider in the same zone. Only all service providers within the same zone do not.

When available, the service providers in other zone will be called.

 

Reprinted from https://segmentfault.com/a/1190000014107639

 

Leave a Reply

Your email address will not be published. Required fields are marked *