Architecture of the sample solution

Interestingly, a replication mechanism was one of the major motivations to begin work on the new version of the Eureka Server. Eureka 2.0 is still under active development. Besides optimized replication, it will also provide some interesting features such as a push model from the server to clients for any changes in the registration list, auto-scaled servers, and a rich dashboard. This solution seems promising, but Spring Cloud Netflix still uses version 1 and to be honest I was not able to find any plans for the migration to version 2. The current Eureka version for Dalston.SR4 Release Train is 1.6.2. The configuration of the clustering mechanism on the server side comes down to one thing, the set URL of another discovery server using eureka.client.* properties section. The selected server would just register itself in the other servers, which were chosen to be a part of the created cluster. The best way to show how this solution works in practice is of course by example.

Let's begin with the architecture of the example system, which is shown in the following diagram. All of our applications will be run locally on different ports. At this stage, we have to introduce the example of the API gateway based on Netflix Zuul. It would be helpful for the purpose of load balancing tests between three instances of a service registered in different zones: