We have created our gateway and two microservice applications. The microservices have two different databases. So far, it has been easy and simple to create those with JHipster.
JHipster provides two different options we have previously seen, Consul and JHipster Registry. For our use case, let's go with JHipster Registry. We have already learned about JHipster Registry in Chapter 8, Introduction to Microservice Server-Side Technologies. Now, we will see how to set up and start it in our local development environment.
Now, these three services basically act as Eureka clients. We need a service registry that registers and deregisters the application as and when the application is started and stopped, respectively; this is JHipster Registry. The Eureka server (JHipster Registry server) acts as a master to all the Eureka clients.
Since JHipster Registry, as the name suggests, acts as a registry service, all microservice applications and the gateway will register/deregister themselves when the application starts and stops.
Let's recap a little bit of what we learned already. The JHipster Registry is made up of a Eureka server and Spring Cloud Config server and they help in the following
- The Eureka server helps in service discovery and load balancing the requests.
- The Spring Cloud Config server acts as a single place where we will manage the external properties of applications across environments. It also provides a dashboard for users. With this, users can manage and monitor the application.
This makes JHipster Registry an ideal choice for both monolithic and microservice architectures.
There are three ways in which we can set up JHipster Registry to run locally.
We can either download the WAR file (pre-packaged) and run it directly, or clone our GitHub repository and run from there. We can also use a Docker container to run it. We will see how to do each of these now.