Blog

Implementing Microservices via JHipster

by | Jul 20, 2017 | Microservices | 0 comments

Armedia Solution Engineering Team

  • Vishal Deshpande
  • Andrew Slade
  • William Phillips
  • Naga Krishna Sumanth Kovvuri

How does Armedia Develop Microservices?

Microservices are powerful tools, but there can be difficulty in getting them started and off the ground. To facilitate this process, Armedia utilizes JHipster in order to quickly spin up new microservices. JHipster is an open-source project generation tool used to quickly develop a modern web application using AngularJS and the Spring Framework via a Yeoman generator. We use the microservice generator capabilities of JHipster as it creates the scaffolding required to coordinate the microservices with the JHipster Registry, greatly easing the architectural burden and reducing project start-up time.

The entry point for your microservices is through the gateway application, which is generated using application type: microservice gateway. In addition to serving as an entry point, it also provides services such as routing, load balancing, and API documentation for all the microservices connected to the gateway.

Once the microservices and the gateway are up and running, they all register and also get their configuration from a runtime application called the JHipster Registry. The JHipster Registry handles the organization of microservices with the gateway, as well as managing microservices that are scaled horizontally.

JHipster also generates Docker containers for each microservice, allowing separation and easy spinning up of microservices on any architecture we want. It also supports SonarQube out-of-the-box, which is a code quality checking tool for the purpose of reducing bugs and improving speed and reliability.

JHipster has many wonderful features out of the box, including automatic documentation, internationalization, unit tests, as well as end-to-end tests all wired up together. In addition, it supports the generation of monolithic applications as well, letting you benefit from either design path you choose to take.

Below is an example screenshot of JHipster Tool on how easy it is to generate a microservice application:

JHipster Tool

What is the structure of Armedia’s microservice architecture?

the structure of Armedia’s microservice architecture

In the above Diagram:

The Green component is the microservice gateway. This is the core of the microservice architecture. It handles web traffic and serves an Angular application. It additionally handles routing, load balancing, and API for all microservices. All external applications talk to the gateway to get information from a microservice, and all microservices respond to the gateway.

Some example microservices are shown in orange. The service requests sent from the gateway, and each focus on a specialized task.

The Event Bus serves as an internal messaging system between microservices. This way microservices don’t have to require the same information as the gateway would require to communicate with a microservice, but instead can achieve an expedited connection. Inter-microservice communication is a necessity in order to avoid duplication of tasks and information.

The external frontend applications which interact with our microservices are shown in blue. They are AngularJS applications which are serviced by the gateway. When a user logs in from an AngularJS application, a call is made to the micro-service gateway where the login details are validated. The gateway responds with a JWT token back to the Angular application which serves as authentication, which the gateway and each microservice can validate via a common secret key. Now, with a valid JWT token, the front-end applications can make REST calls to any of the microservices. Each of these REST calls to the microservices has this JWT token appended in the Header’s section which microservices are able to validate and authenticate users using that token.

Those tokens are self-sufficient: they have both authentication and authorization information, so microservices do not need to query a database or an external system. This ensures a scalable architecture.

In order to keep the front-end and microservices in sync, we use Swagger as a documentation and endpoint testing tool. Whenever a microservice’s REST API has any changes or additions, the Swagger document for the microservice is updated.

When it comes to microservices, the quality of the code becomes paramount, as bad bugs or exploits could lead to downtime. To be proactive, we are using SonarQube as a code quality checking tool. Before a new version of a microservice is deployed, we always ensure that the code quality is exceptional.

Of course, with having microservices on multiple, separate machines, getting the metrics for each microservice is paramount. The gateway application has an auto-generated metric suite which we have dubbed “AppStats”. From one location, we can get the current state of our architecture and can use these metrics to better improve the speed and uptime of our architecture.

Below is a screenshot of “various options available in a Gateway application” and “Application Metrics”:

JHipster homepage

application metrics

Categories

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *