This article is the third and final part of the trilogy of microservices project code organization. Through these three articles, WE believe that you have a basic understanding of how to organize the code in microservices. The first two are respectively:

  1. Should we build a micro service project or not?
  2. Is Maven really appropriate for managing common code bases in microservice projects?

The third article is relatively easy, I didn’t plan to write it, but last week a friend asked me a question about Maven, and THEN I found that some friends still don’t know enough about aggregation engineering, so I came up with this article, and I want to talk about aggregation engineering with you again.

1. Microservices architecture

There are often some differences between the theoretical microservices architecture and the practical microservices.

In theory, in microservices architecture, individual microservices can be in various languages, such as the Eureka registry we use, which supports multiple languages, so that the advantages of various languages can be fully utilized. If this is the case, versioning the project as a whole is neither necessary nor manageable.

But in practice, considering the technology stack of the team, the existing technology ecology and other factors, in most cases, we may not incorporate other languages into the project, such as Java development, I believe most of our partners do so.

Since unification is developed in the Java language, a requirement arises that projects rely on unification management.

The question is not absolute.

Large micro services belong to different team, each team safeguard their own projects, and then through the RPC or HTTP the way of interaction between each other, in this case, the version number can be left to the team maintains, this version upgrade, you don’t have to upgrade together, can the teams alone, upgrade them one by one.

However, this approach may lead to another problem, which is fragmentation of dependent versions. After N iterations, there may be very different versions of microservices that the two projects rely on.

As a result, in practice, some teams may prefer to unify project versions.

Unified management is also very simple, just make a parent, but some friends are easy to confuse this kind of parent with aggregation engineering, so let’s talk about how to unified management project version number.

2. Manage version numbers in a unified manner

2.1 Polymerization Engineering

Let’s talk about aggregation engineering, I won’t rewrite the code here, take micro personnel (github.com/lenve/vhr) as…

The server side of micro personnel projects is an aggregation project.

We can take a look at the POM.xml file of vhrServer:

<parent>
    <artifactId>vhr</artifactId>
    <groupId>org.javaboy</groupId>
    <version>1.0 the SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>vhrserver</artifactId>
<packaging>pom</packaging>
<modules>
    <module>vhr-mapper</module>
    <module>vhr-model</module>
    <module>vhr-service</module>
    <module>vhr-web</module>
</modules>
Copy the code

In this aggregation project, vhr-Model is used to put entity classes, vhr-mapper is used to put Dao layer, vhr-Server is used to put Service layer, and vhr-Web is a Spring Boot project.

In an aggregation project, vhr-Web, as part of the aggregation project, cannot be packaged independently because it relies on vhr-service, which relies on vhr-mapper, which relies on vhr-Model. We need to package it from the VHRServer so that it automatically resolves dependencies between modules.

Packaging vhr-Web separately generates the following error:

Unified packaging from vHRServer results in the following:

As you can see, we need to package the aggregation project directly, and the internal dependencies will take care of themselves.

Javaboy :vhr-service:pom: 1.0-snapshot: artifact org.javaboy:vhr-service:pom: 1.0-snapshot: artifact org.javaboy:vhr-service:pom: 1.0-snapshot Can we go back to packing the Vhr-Web?

This is not possible, because this is an aggregation project, can not do so, can only be packaged from the aggregation agency.

2.2 Unified Version Management

Although the aggregation project mentioned above can also achieve unified version number management, but we can not use this method in microservices.

If you think of a microservice system, it contains many subsystems, such as commodity management, transaction management, logistics management, etc., to package the commodity management, you have to package from the aggregation department, after the completion of the other microservice modules also generated their own packages, which is too inefficient.

But we also want to achieve unified version number management, how to do? Create a parent-child project. This project structure is very similar to aggregation engineering, but different, and a lot of people get confused, so I’m going to show you a little bit.

First, we define a generic Maven project as a parent project. I will present the POM.xml file for your reference.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.0. RELEASE</version>
    <relativePath/>
</parent>
<packaging>pom</packaging>
<groupId>org.javaboy.vmall</groupId>
<artifactId>vmall</artifactId>
<version>1.0 the SNAPSHOT</version>
<properties>
    <! - omitted - >
</properties>
<dependencyManagement>
    <dependencies>
        <! - omitted - >
    </dependencies>
</dependencyManagement>
Copy the code

As you can see, the parent project itself also has a parent in Spring Boot.

Packaging here is still POM, and then we define dependencyManagement to manage dependencies that are not included in spring-boot-starter-parent. But notice that there is no Modules node, which is a big difference.

Next, we create other microservice projects, which can be tiled as follows:

It can also be made into a hierarchical parent-child form like the following:

You can do it either way.

Then modify parent again in each microservice project:

After this, we can manage the dependent versions in the microservices uniformly.

This kind of project structure is not the same as convergent engineering, this kind of project package, can be packaged independently.

First we will install the parent project into the local repository:

Install vmall-common module and package vmall-app-manager. Note that the current VMall-app-Manager can be packaged independently without the need for unified packaging from the total parent. In microservice projects, if the project version needs to be managed uniformly, this method can be adopted.

You can explore the differences between this approach and aggregation engineering.

3. Summary

Well, today’s content is relatively simple, combined with the previous two articles, I believe that you have a certain idea of how to organize the code of the microservice project.

If you feel that you have gained something, remember to click on songko under the encouragement of watching oh ~