Build microservices using Java

Build microservices using Java

[Editor's note] This article is translated from Dzone Guide to the Java Ecosystem. Dzone is an excellent website on Java. This article introduces several methods to build microservices using Java, including Container-less, Self-contained, and In-container. Translation experience is insufficient. If you have any mistakes, please kindly advise.

Quick browsing

1. In the Java ecosystem, policies for constructing microservices include Container-less, Self-contained, and In-container.
2. The Container-less microservice packs applications and their dependencies into a single jar file.
3. Self-contained microservice is also packaged into a single Jar file, but it also includes an embedded framework, which contains optional third-party lib, of course, these lib are compatible.
4. The In-container microservice is packaged into a complete Java EE container, which is implemented In the Docker image.
   The microservice-based architecture brings new challenges to architects and developers. However, with the increase in the number of language upgrades and tools, developers and architects are fully capable of meeting these challenges. Java is no exception. This article discusses different methods to build microservices in the Java ecosystem.

Introduction

This article will not discuss whether microservices are good or bad, nor suggest you use microservices to design your apps in advance, or extract these services when they appear in the monolith application.

The method described here is not unique, but it gives you a good overview of these possibilities. Even if the Java ecosystem is a field of interest in this article, these concepts can also be passed into other languages and technologies.

In this article, these methods are called Container-less, Self-contained, and In-container. These terms may not yet be fully established, but here they can be used to differentiate these methods. I will explain their meaning in the following sections.

Container-less

In the Container-less method, developers must take everything at the top layer of JVM as part of the application.

The Container-less method makes it possible to deploy a single JAR (also known as "fat JAR"). This means that applications and their dependencies can be packaged in a single JAR file, and runs as an independent Java program.

 

$ java -jar myservice.jar

The advantage of this method is that service startup and stop are extremely easy when the application is scaling in and out. Another advantage is that the deployment is simple. You only need to pass a JAR file.

The disadvantage of this method is the compatibility of the lib library. You need to independently solve things like transaction processing, or introduce a third-party lib library to provide support for the solution. Later, if you need support such as persistence, you may need to face the compatibility problem of the lib library.

Self-contained

Another transformation of a single JAR deployment is to use an embedded framework to build microservices. In this method, the Framework provides the implementation of the required services. At the same time, developers can choose which services they want to include.

You may think this is the same as the Container-less solution, but I want to differentiate them here, because the self-cotained method allows you to use a third-party lib library, and you know that these lib libraries are compatible.

This method involves tools such as Spring Boot and Wild Swarm.

Spring Boot

Spring Boot and Spring Cloud Netflix projects provide excellent support for using Java to build microservices. Spring Boot allows you to select Tools in various Spring ecosystems and popular third-party tools, and package these tools with your applications. Spring Initializr allows you to use the simple check box list to complete this operation. Here is a simple example of the Hello World Service, Gist Sinppet.

Wildfly Swarm

In Java EE, Wildfly Swarm corresponds to Spring Boot. It allows you to select the required Java EE specification and package it and the application in the form of a JAR file. Hello World, Gist Snippet.

The advantage of the Self-contained method is that you can select only components that are sufficient for the service to run.

The disadvantage of this method is that the configuration is a little complicated, and the JAR file generated from this method is a little large, because it is built for the container functions required by the actual service.

In-container

Although a complete Java EE container is required to be able to deploy a microservice, it seems to require a lot of overhead, but remember that: some developers claim that microservices do not mean that they are tiny or simple.

In these cases, it seems appropriate to regard the Java EE container as a required platform, because the only dependency you need is the Java ee api. Note: The dependency is satisfied because its implementation is provided by the container. This means that the resulting WAR file is extremely sophisticated. The implementation of this service is the same as the preceding Wildfly Swarm example. Refer to Gist Snippet here.

The advantage of this method is that the container provides the implementation of the test and verification standard functions through the standard APIs. Therefore, as a developer, you can focus entirely on business functions, besides the application code, the underlying code is maintained.

Another advantage of this method is that the actual application code does not depend on the Java EE application server where the code is deployed, whether it is GlassFish, WildFly, Weblogic, WebSphere, or other Java EE compatibility implementations.

The disadvantage of this method is that you need to deploy the service in the container, which increases the deployment complexity.

Docker

Docker starts from here. By packaging Java EE containers and services into a Docker image, you can achieve the same effect as a single JAR development. The difference is that the service is in the container instead of the JAR file.

Dockerfile
FROM jboss/wildfly:9.0.0.1.final
ADD myservice.war /opt/jboss/wildfly/standalone/deployments

Wake up the service by starting the Docker image in the Docker engine.

docker run -it -p 8081:8080 myorganization/myservice

 

Snoop

Careful readers may have noticed the @ EnableErekaClient annotation in the Spring Boot code segment. This annotation registers the service in Eureka so that it can be discovered by the service requestor. Eureka is part of the Spring Cloud Netflix package and is an extremely easy-to-use and configuration service discovery solution.

Java EE does not provide such functions externally, but there are several open source solutions. One of them is Snoop, which is similar to Eureka. To make a Java EE microservice available for service search, the only thing that needs to be done is to use the @ EnableSnoopClient annotation, as shown in this example: Gist Snippet.

Summary

Java is a good choice when building microservices. The methods described here can complete the task well. As for your personal special circumstances, the best method depends on your service requirements. For simple services, a container-less or self-contained service is the best choice. However, with the implementation of in-container, developers can implement advanced services faster and simpler. In short, Java is an effective ecosystem for the implementation of microservices.