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

The recent slowdown in work has slowed the frequency of updates, and it took time to build the spring cloud Chinese community, almost daily with toothpaste-like time to do something meaningful. Failed to update the blog post as planned, and I am very sorry for my friends who continue to follow my blog.

Before I wrote the Spring Cloud series, I had a thicker plan, and now I'm getting a lot of feedback and questions, so I'm going to make some adjustments, and then pull out some of the more focused points to write something.

Today this article is mainly about the high availability of Eureka server.

Objective

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.

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

Spring.application.name=eureka-server server.port=1111 Eureka.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

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

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

127.0.0.1 Peer1 127.0.0.1 Peer2

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

Java-jar Eureka-server-1.0.0.jar--spring.profiles.active=peer1 Java-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 :

Spring.application.name=compute-service server.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.

Reproduced in: http://blog.didispace.com/springcloud6/

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