Zones

A cluster-based on a peer-to-peer replication model is a good way to go in most cases, but not always enough. Eureka has one more interesting feature that can be very useful in a clustered environment. A zone mechanism is, in fact, the default behavior. Even if we have a single standalone service discovery instance, every client's property has to be set to eureka.client.serviceUrl.defaultZone in the configuration settings. When will this be useful to us? To analyze it, we go back to the example from the previous section. Let's imagine that now we have our environment divided into three different physical networks, or we just have three different machines processing the incoming requests. Of course, discovery services are still grouped logically in the cluster, but each instance is placed in a separated zone. Every client application would be registered in the same zone as its main discovery server. Instead of one instance of the Zuul gateway, we are going to launch three instances, each one for a single zone. If the request comes into a gateway, it should prefer those clients that leverage services within the same zone before trying to call services registered in another zone. The current system architecture is visualized in the following diagram. Of course, for example purposes, the architecture was simplified to be able to run on a single local machine. In the real world, like I mentioned before, it would be launched on three different machines or even on three different groups of machines, physically separated into other networks: