Spring Cloud Building MicroServices Architecture (vi) High-availability service registry

At the beginning of the Spring Cloud series, we introduced service registration and discovery, which mainly demonstrated how to build and start the Service registry Eureka Server, and how to register the service with Eureka Server, but in the previous example, This service registration center is a single point, obviously this is not suitable for online production environment, then on the basis of the previous article, we will look at how to build a highly available Eureka server cluster.

Example of a single point Eureka server:

• GitHub
• Open source China

Eureka server is highly available

Eureka server enables highly available deployments by running multiple instances and registering each other in addition to a single point of operation, so we only need to configure the Eureke server for other available serviceurl to achieve a highly available deployment.

The following is based on the eureka-server in Chapter1-1-1, and its transformation, the construction of a two-node service registration center.

• Create application-peer1.properties , configure as a Peer1 service center, and point Serviceurl to Peer2

12345

Spring.application.name=eureka-serverserver.port=1111eureka.instance.hostname=peer1 eureka.client.serviceurl.defaultzone=http://peer2:1112/eureka/

• Create application-peer2.properties , configure as a Peer2 service center, and point Serviceurl to Peer1

12345

Spring.application.name=eureka-serverserver.port=1112eureka.instance.hostname=peer2 eureka.client.serviceurl.defaultzone=http://peer1:1111/eureka/

• /etc/hostsadding transformations to Peer1 and Peer2 in a file

12	127.0.0.1 peer1127.0.0.1 Peer2

• spring.profiles.activeto start Peer1 and Peer2 separately through attributes

12	Java-jar Eureka-server-1.0.0.jar--spring.profiles.active=peer1java-jar Eureka-server-1.0.0.jar-- Spring.profiles.active=peer2

• At this point visit Peer1 's registry: http://localhost:1111/ as shown, we can see that registered-replicas there are already eureka-server in the Peer2 node. Similarly, access to Peer2 's registry: http://localhost:1112/ you can see that registered-replicas there are already peer1 nodes, and these nodes are in the available shards (available-replicase). We can also try to turn off Peer1, refresh http://localhost:1112/ , and see Peer1 nodes become unusable shards (Unavailable-replicas).

Service Registration and Discovery

After setting up a multi-node service registry, our master needs a simple requirements service configuration to register the service with the Eureka server cluster. We modify the configuration file based on the Compute-service in Chapter1-1-1 application.properties :

1234	spring.application.name=compute-serviceserver.port=2222 eureka.client.serviceurl.defaultzone=http://peer1:1111/ eureka/,http://peer2:1112/eureka/

The above configuration mainly eureka.client.serviceUrl.defaultZone changes the properties, pointing the registry to the Peer1 and Peer2 we built earlier.

Below, we start the service, through access http://localhost:1111/ and http://localhost:1112/ , can observe that Compute-service is also registered on both Peer1 and Peer2. If Peer1 is disconnected at this time, since Compute-service also registers with Peer2, other services on Peer2 can still access compute-service, thus enabling a highly available service registry.

Deep understanding

Although we use two nodes as an example above, we may need to build more than two Eureka server nodes in the production environment because of the load and so on. So how to configure Serviceurl to synchronize services in a cluster requires a deeper understanding of the synchronization mechanism between nodes to make decisions.

Eureka server synchronization follows a very simple principle: as long as one side connects the nodes, information can be propagated and synchronized. What do you mean? Let's take a look at what happens in the following experiment.

• Scenario One: Let's say we have 3 registries, we'll peer1, Peer2, and Peer3 each point serviceurl to another two nodes. In other words, Peer1, Peer2 and Peer3 are 22 registered with each other. Start the three service registries and point the Compute-service serviceurl to Peer1 and start to get the cluster effect as shown.

Access http://localhost:1112/ , you can see 3 registries composed of clusters, compute-service services through Peer1 synchronization to the mutual registration of Peer2 and Peer3.

From the above experiment, we can draw the following conclusions to guide us to build a high-availability cluster of service registries:

• 22 The method of registration can realize the full equivalence of nodes in the cluster, achieve the highest availability cluster, and no one registry fault will affect the registration and discovery of the service.

Spring Cloud Building MicroServices Architecture (vi) High-availability service registry