Use of Region and zone in Springcloud

I. BACKGROUND

A large number of users or the geographical distribution of users of a wide range of projects, there will generally be more than one room. This time if the online Springcloud service, we hope that the service in a computer room first call the same room service

, when the same machine room service is not available, then to call other room services, in order to achieve the effect of reducing delay.

Second, the concept

Eureka provides two concepts of region and zone for partitioning, both of which are derived from Amazon's AWS:

(1) Region: can be easily understood as a geographical division, such as Asia, or north China, or Beijing and so on, no specific size restrictions. According to the specific circumstances of the project, the region can be divided into reasonable discretion.

(2) Zone: can be easily understood as the region of the specific room, for example, the division of Beijing, and then Beijing has two computer rooms, you can divide under this region of the Zone1,zone2 two zone.

Iii. deployment architecture diagram for partitioned services

As shown, there is a region:beijing, below the zone-1 and zone-2 two partitions, each of which has a registry Eureka server and a service provider. We create a zone-1 within the

Consumer-1 service consumers, it will first call the same zone within the Service-1, when the Service-1 is not available, will be called zone-2 within the Service-2.

Iv. examples

(1) Eureka Server-1:

SpringApplication:NameServer-1ServerPort30000EurekaInstancePrefer-ip-address:TrueStatus-page-url-path:/actuator/infoHealth-check-url-path:/actuator/health hostname: localhost client: Register-with-eureka: true fetch-registry: true Prefer-same-zone-eureka: true #地区 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:

SpringApplication:NameServer-2ServerPort30001EurekaInstancePrefer-ip-address:TrueStatus-page-url-path:/actuator/infoHealth-check-url-path:/actuator/health hostname: localhost client: Register-with-eureka: true fetch-registry: true Prefer-same-zone-eureka: true #地区 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

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

Configuration file

SpringApplication:NameServiceServerPort30010EurekaInstancePrefer-ip-address:TrueStatus-page-url-path:/actuator/infoHealth-check-url-path:/actuator/healthMetadata-map: zone: zone-1 client:  Register-with-eureka: true Fetch-registry: true Prefer-same-zone-eureka: true  #地区  region:  Beijing Availability-zones: Beijing:  Zone-1,zone-2 Service-url: zone-1: http:/ /localhost:30000/eureka/ zone-2: http://localhost:30001/eureka/< Span class= "hljs-string" >zone.name: zone-1       

(4) Service2

SpringApplication:NameServiceServerPort30011EurekaInstancePrefer-ip-address:TrueStatus-page-url-path:/actuator/infoHealth-check-url-path:/actuator/healthMetadata-map: zone: zone-2 client:  Register-with-eureka: true Fetch-registry: true Prefer-same-zone-eureka: true  #地区  region:  Beijing Availability-zones: Beijing:  Zone-2,zone-1 Service-url: zone-1: http:/ /localhost:30000/eureka/ zone-2: http://localhost:30001/eureka/< Span class= "hljs-string" >zone.name: zone-2       

(5) Consumer-1

Test code

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

Configuration file

SpringApplication:NameConsumerServerPort30030EurekaInstancePrefer-ip-address:TrueStatus-page-url-path:/actuator/infoHealth-check-url-path:/actuator/health Metadata-map: zone: Span class= "hljs-string" >zone-1 Client: Register-with-eureka: Span class= "hljs-literal" >true fetch-registry: true Prefer-same-zone-eureka: true  #地区  region: beijing Availability-zones:  Beijing: zone-1,zone-2 service-url:< Span class= "hljs-attr" > zone-1: http://localhost:30000/eureka/ Zone-2: http://localhost:30001/eureka/       

Five, the configuration file detailed

The entire partition is divided into two steps:

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

(2) Service invocation: To ensure preferential invocation of services within the same zone, only when the service within the same zone is not available, to call the service of the zone.

1. configuration file for service registration

eureka:  client:    prefer-same-zone-eureka: true    #地区 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 registry (Eureka Server), it is registered according to the configuration under Eureka.client. Here we are primarily concerned with the case of multiple registries, the service will note

Registration Center and which registry to maintain heartbeat detection. Registration Center Selection Logic:

(1) If Prefer-same-zone-eureka is false, follow the list under Service-url to register with the first registry and maintain heartbeat detection. No longer registers and maintains heartbeats with other registries in the list. Only in the first

In the case of a failed registration, it will be registered to the other registry in turn, a total of 3 retries, if the 3 Service-url are not registered successfully, the registration failed. Every other heartbeat time, will try again.

(2) If Prefer-same-zone-eureka is true, first through the region to take the first zone within the Availability-zones, and then through the zone to take service-url under the list, and register with the first registry in the list

and maintain heartbeat, no longer register and maintain heartbeat to other registries in the list. Only if the first registration fails, the other registry is registered in turn, a total of 3 retries, if 3 Service-url are not registered as

The registration fails. Every other heartbeat time, will try again.

Therefore, in order to ensure that the service registered to the same zone of the registration center, must pay attention to the order of the Availability-zones, you have to write the same zone in front

2. configuration file for service invocation

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

Service consumers and service providers belong to which zone respectively, are determined by Eureka.instance.metadata-map.zone. The service consumer will first pull a list of service providers through the Ribbon to the registry and then

Eureka.instance.metadata-map.zone the specified zone to filter, after filtering if there are multiple instances of the service provider in the same zone, it will be called in turn. Only all service providers within the same zone are not

Service providers in other zones are called when they are available.

Reprinted from 1190000014107639

Use of Region and zone in Springcloud