Today I’d like to continue talking about the organization of code in microservices.

Yesterday, we talked about whether to use aggregation engineering in micro-service projects (whether to build micro-service projects with aggregation engineering?). So today we are going to talk about the organization of the common code base in microservices.

1. Common code base

In any project, it is inevitable that we will have a common code base, which may hold some utility classes or entity classes for other projects to use.

The common practice is to upload the public code base to the company private server, and then everyone can add dependencies to the project. This way, I believe many friends have played.

But I don’t know if you’ve ever thought about it, but one of the drawbacks of this approach is that it doesn’t work on fast iterative projects.

In a fast-iterating project, the Common changes frequently, which means that developers have to constantly package common and upload it, while others constantly change the version numbers referenced.

In traditional monolithic applications, where teams may not be as large and the common does not change as often, the disadvantages of using Maven to manage common code blocks are not obvious.

However, the current popular micro-service architecture is suitable for large army operations, and the number of micro-services is also large. In micro-service projects, dozens or hundreds of micro-services are often used. In order to solve the serialization problem of calls between micro-services, we may extract entity classes into a common, and each micro-service can modify the common according to its own needs. Even if each micro-service modifies the common once a day, it will be reflected in the Common day and night. Other microservices have to constantly change their version numbers to keep up with the changes day and night.

In this case, it’s obviously not a good idea to use Maven to continue managing Common, because it means you have to keep packaging, and all microservices have to keep changing the version number of common referenced.

In case anyone is being too critical, Songo should add that this is common in fast-iterating microservices projects, especially the larger the team and the more microservices there are, the more Maven’s disadvantage in managing common blocks of code becomes obvious. In a traditional singleton application, you might not feel the problem as easily.

Maven is actually more focused on package dependency management, as you can see from Songo’s description above. Although it can synchronize common code across projects, there is no bidirectional synchronization. (Bidirectional synchronization means that updates to Common from microservices are automatically synchronized to the Common library. Updates to the common library are also automatically synchronized to microservices.) Maven is better suited for situations where the common code base is stable.

2. Solutions

If the common code base is constantly changing and Maven is not particularly convenient, what other solutions do we have?

There must be a plan, or Songo wouldn’t be jacking this article.

Here is a Git Subtree that our team is currently using.

2.1 the Git Subtree

Before Git Subtree, the official solution was Git Submodule, but since Git1.5.2, Git has added and recommended to use this function to manage subprojects. You can use Git Subtree if your local Git version is 1.5.2 or higher.

Git Subtree does not have dependency management, but it is very handy when dealing with a common code base that can be replaced quickly, and it can be synchronized in both directions!

2.2 Specific Applications

Git Subtree Git Subtree Git Subtree Here’s Songo to tell you a little bit about it.

First, suppose I now have a project called VMAll. Vmall is a microservice project that contains many microservices and a common code block called VMall-common that is iterating rapidly (note that vmAll and VMall-common belong to two different repositories).

Vmall-common I have submitted it to GitHub at github.com/lenve/vmall…

Now I want to reference vmall-common in the vmAll project. How do I do that? Execute the following code in the VMAll repository:

git subtree add --prefix=vmall-common https://github.com/lenve/vmall-common.git master --squash
Copy the code

Finally, the –squash parameter means that history information is not pulled and only a COMMIT information is generated. This parameter is optional and can be omitted. After executing this command, vmall-common will be visible in the vmAll project, and vmall-common will exist as a normal folder, whatever it is.

At this point we can start normal development.

If we modify vmall-common in the process of development, we can commit vmall-common to its own repository by using the following command:

git subtree push --prefix=vmall-common https://github.com/lenve/vmall-common.git master
Copy the code

If you commit this change in vmall-common’s own repository, it is a normal Git commit command, which I don’t need to say much about.

When the code in VMall-common changes, other microservices can update the code with the following instruction:

git subtree pull --prefix=vmall-common https://github.com/lenve/vmall-common.git master --squash
Copy the code

These three commands are basically enough for most everyday operations, but it is inconvenient to enter a long address each time. We can give the address an alias:

git remote add -f vmall-common https://github.com/lenve/vmall-common.git
Copy the code

Thus, the top three commands can be simplified:

git subtree add --prefix=vmall-common vmall-common master --squash
git subtree pull --prefix=vmall-common vmall-common master --squash
git subtree push --prefix=vmall-common vmall-common master
Copy the code

3. Summary

Today, I talked with my friends about the organization of code in code micro service.

In a nutshell, Maven is good for managing stable common codels, Git Subtree is good for handling rapidly changing common codels, and supports bidirectional synchronization! Git Subtree: If you want to add –squash, and when you want to add — Git Subtree: If you want to add –squash, you can add — Git Subtree.

Ok, interested partners can come down to try ~ if you think you have a harvest, remember to click on the next watch under the encouragement of Songgo oh ~