Spring cloud introductory series three: use Eureka to build a high-availability service registry

In the previous article, I shared how to use Eureka for service governance . The service registry built in it is a single piece.

However, in practical applications, in order to prevent serious consequences from the downtime of a single service, distributed systems generally adopt the form of server clusters. The same is true for service registration centers. Multiple services are required to work together to form a highly available service registration center. . This way, if one of them goes down, the system can run normally.

So how to build a highly available service registry?

Since the eureka registry can be used as both a server (service registry) and a client (to register itself with another registry),

We can register with each other by deploying two services, peer1 and peer2, on the machine.

1. Code implementation

　　Or use the eureka service example in the previous article, and we will modify it on this basis:

1. Added /eureka/src/main/resources/application-peer1.properties

   server.port=1111
   
   spring.application.name=eureka-service
   #Set the hostname to peer1
   eureka.instance.hostname=peer1
   
   #eureka.client.register-with-eureka=false
   #eureka.client.fetch-registry=false
   #Set eureka's serviceUrl to peer2
   eureka.client.serviceUrl.defaultZone=http://peer2:1112/eureka

2. Added /eureka/src/main/resources/application-peer2.properties

   server.port=1112
   
   spring.application.name=eureka-service
   eureka.instance.hostname=peer2
   #eureka.client.register-with-eureka=false
   #eureka.client.fetch-registry=false
   #Set eureka's serviceUrl to peer1
   eureka.client.serviceUrl.defaultZone=http://peer1:1111/eureka

   Since peer1 and peer2 need to register with each other, in steps 1 and 2, the two configurations eureka.client.register-with-eureka=false and eureka.client.fetch-registry=false cannot be used, and need to be commented out or delete.

3. Set the host and add it to the hosts file in the C:\Windows\System32\drivers\etc directory

   127.0.0.1 peer1
   127.0.0.1 peer2

   to resolve peer1 and peer2.

4. Configure two startup services
   1. )

       

   2. )

       

       
5. Start eureka1 and eureka2
6. Page visit http://localhost:1111/

   We will find that there will be peer2 in DS Replicas (sharding); there will be 2 in the service instance, one is 1111 and the other is 1112; in registered-replicas (registered shards) and available-replicas (available shards) ) appears in peer2:1112. For the same reason, we can also see similar effects when we visit http://localhost:1112/. If you stop peer2, you will find that peer2 has run to unavailable-replicas (unavailable shard) when you visit http://localhost:1111/. The specific screenshot is omitted.

2. Problems encountered in debugging

I encountered a problem when debugging the above content, that is, peer1 and peer2 have not been able to register with each other successfully. The page performance is that the service instance is empty and available-replicas is empty, and the corresponding service is in unavailable-replicas. Later, after many implementations and analysis, I finally found that the following two configurations are still retained in my application.properties file. The service will read this configuration when it starts.

Although these two configurations are true by default, they are overwritten by application.properties. At this time, it is good to comment out these two configurations.

If you configure it again in application-{profiles}.properties, you can overwrite the configuration in application.properties.

The code reading order is as follows:

First read the default configuration --> then read application.properties --> read application-{profiles}.properties.