We have created our gateway and two microservice applications. These microservices have two different databases. So far, it has been easy and simple to create these with JHipster. We also enabled service discovery with Eureka for the applications. This means we would have to run a service registry in order to deploy the applications.
JHipster provides two different options we have previously seen, Consul and JHipster Registry. For our use case, since we have chosen Eureka, we need to go with JHipster Registry. We learned about JHipster Registry in Chapter 8, Microservice Server-Side Technologies. Now, we will learn how to set up and start it in our local development environment.
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.
All the microservice applications and the gateway will register/deregister themselves with/from JHipster Registry when the applications start and stop.
Let's recap a little bit of what we've learned already. The JHipster Registry is made up of a Eureka server and Spring Cloud Config Server and they help in doing the following:
- The Eureka server helps with 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 two ways in which we can set up JHipster Registry to run locally: we can either download the JAR file (pre-packaged) and run it directly, or we can use a Docker container to run it. We will learn how to do each of these now.