Shulou(Shulou.com)06/01 Report--

How to use Java to build micro services, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

To build micro-services, Java is a very good choice. How to build a microservice using Java in a container? This paper describes three construction schemes for you, no matter which one, to implement micro-services, the components using the Java ecosystem are all industry-proven.

Overview

1. There are three strategies for building micro-services in the Java ecosystem: no container, self-made container and external container.

two。 Providing microservices in a containerless manner will package the entire application, including all dependencies, and put it into a fat JAR package.

3. Self-contained microservices are also packaged into a single JAR package, and the JAR package contains embedded frameworks with third-party class libraries.

4. The micro-service mode of the external container will package the entire Java EE container and service implementation into a Docker container.

The architecture based on microservices brings new challenges to architects and developers, and the emerging new languages and development tools enable us to meet this challenge. Java is no exception, and this article will explore new ideas for building microservices in the Java ecosystem.

Do not discuss whether micro-services are good or bad, or whether you should design applications with micro-services architecture in the first place, or whether you should restructure existing large applications into micro-services architecture.

The methods discussed here are not the only ones, but they will inspire us to see other possibilities. Although this article focuses on the Java ecosystem, the concepts in it are also common to other languages and technologies.

I have named several ways in this article as "No Container", "self-made Container", and "external Container". These terms are not widely used, but they are sufficient to distinguish the characteristics of each method, which I will discuss in the following sections.

Containerless scheme

In a containerless approach, developers treat all components on the JVM as part of the application.

The containerless approach to deployment using a single JAR package (so-called "fat JAR deployment") means that the application and all its dependencies are packaged into a JAR file that can be started as a separate Java process.

```sh

$java-jar myservice.jar

`

One of the advantages of this method is that you can simply stop the service as needed to achieve the purpose of capacity expansion or reduction; another advantage is that it is convenient to implement distributed deployment by synchronizing only one JAR file.

On the other hand, its disadvantage is the compatibility of class library dependencies. For example, if you need to make the application support transactional features, you are on your own, or you need to introduce support for this feature is a third-party class library. In the future, whenever you need to support other features, such as persistence, you are likely to encounter compatibility issues between class libraries.

Self-made container scheme

A variation of the deployment of a single JAR package is to build your service based on a built-in framework. In this way, the framework can provide the features required by the service, and developers can choose which features are included in the service.

You might argue that this is not exactly the same as the "containerless" scheme. However, I want to distinguish between them here, because the "self-container" solution actually provides a set of compatible third-party class libraries.

In this case, it seems appropriate to use the Java EE container as a necessary basis. So the only thing you need is Jave EE's API. Note that these dependencies are already provided by the container, which means that the final applied WAR file will be very small. This microservice is implemented in the same way as the Wildfly Swarm example above: [Gist Snippet] (https://gist.github.com/ivargrimstad/c368221fa079285856e7)

The advantage of this approach is that the container provides the implementation of validated standard functions through standard API, so as a developer, you can focus entirely on business functions without paying attention to the underlying details.

Another advantage of this solution is that the application layer code does not depend on the Jave EE application server it deploys Whether it is [GlassFish] (https://glassfish.java.net/), [WildFly] (http://wildfly.org/), [WebLogic]) (http://www.oracle.com/us/products/middleware/cloud-app-foundation/weblogic/overview/index.html), [WebSphere] (http://www.ibm.com/software/websphere) or any other Jave EE-compatible implementation).

The disadvantage is that you need to deploy the service into a container, so it increases the complexity of deployment to a certain extent.

Docker

[Docker] (https://www.docker.com/) is coming out now. By packaging the implementation of Java EE containers and services into a Docker image, the effect can be similar to that of a single JAR package, except that the service is packaged into a Docker image rather than a JAR package.

```sh

Dockerfile

FROM jboss/wildfly:9.0.1.Final

ADD myservice.war / opt/jboss/wildfly/standalone/deployments

`

Start the service by starting the image in the Docker engine.

```sh

$docker run-it-p 8081 purl 8080 myorganization/myservice

`

Snoop

Careful readers may notice the @ EnableEurekaClient annotation in the previous Spring Boot example, which registers the service through Eureka so that it can be discovered by the service consumer. [Eureka] (https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance) is part of the Spring Cloud Netflix toolset that greatly simplifies the configuration of service discovery.

Java EE does not provide this feature, but there are several open source solutions accordingly. One of them is [Snoop] (https://github.com/ivargrimstad/snoop), which has a [similar function] to Eureka (https://github.com/ivargrimstad/snoop)). The only thing you need to do to route a Java EE microservice is to use the @ EnableSnoopClient annotation, as shown in the example [Gist Snippet] (https://gist.github.com/ivargrimstad/34bfe4b5368a35d30007)).

Java is a very good choice for building micro-services, and any of the solutions mentioned in this article can be implemented. For relatively simple services, "no container" or "self-made container" is a better choice, but using external containers can build more complex services more quickly and easily.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.