Is Maven really suitable for managing public code bases in microservice projects?
Posted May 26, 2020 • 4 min read
Today I still want to talk to you about the organization of code in microservices.
Yesterday I talked about whether to use the aggregation project in the microservice project( Microservice project build, whether to aggregate project? ) We are very interested in this topic, so today we will talk about the organization of public code bases in microservices.
- Public Code Base
For any project, we will inevitably have a public code base. This public code base may store some tool classes or entity classes for use by other projects.
The normal way is to upload the public code base to the company's private server, and then everyone can add dependencies to the project. This way, I believe many small friends have played.
But I don't know if you have thought about it. This method actually has a drawback, that is, it is not suitable for fast iteration projects.
In a fast iterative project, common changes are very frequent, which means that developers have to keep uploading common packages, and other people keep changing the referenced common version number.
In traditional monolithic applications, there may not be too many team members, and common changes are not very frequent, so the disadvantage of using Maven to manage public code blocks is not obvious.
The current popular microservice architecture is suitable for large army operations, and there are many microservices with many people. In microservice projects, there are dozens and hundreds of microservices. In order to solve the serialization problem when calling between microservices, we may draw entity classes into a common common. Each microservice can modify common according to its own needs, even if each microservice modifies common once a day. Reflecting on common is also a day-to-day change, and other microservices have to constantly modify the version number to follow this change day and night.
In this case, it is obviously not suitable to use Maven to continue to manage common, because it means that you have to keep packaging, and all microservices have to constantly modify the referenced common version number.
In order to prevent someone from lifting the bar, Songge has to add that the situation mentioned above is more common in fast iterative microservice projects, especially the larger the team, the more microservices, the more disadvantage Maven manages public code blocks obvious. In traditional monolithic applications, you may not easily feel the problem.
As you can see from Song Ge s description above, Maven actually focuses more on package dependency management. Although it can synchronize common code in different projects, it cannot synchronize in both directions(the so-called two-way synchronization is the The updates of common in microservices are automatically synchronized to the common library, and the updates of the common library can also be automatically synchronized to each microservice), Maven is more suitable for the situation where the public code base is relatively stable.
If the public code base is constantly changing and Maven is not particularly convenient, do we have any other solutions?
There must be a plan, otherwise Songge will not be able to do this article.
Here is a program that our team is currently using-Git Subtree.
2.1 Git Subtree
Git Subtree is a solution given by Git to manage subprojects. Before Git Subtree, the official solution was Git Submodule, but since Git 1.5.2, Git added and recommended to use this function to manage subprojects. As long as the Git version installed locally is greater than or equal to 1.5.2, you can use Git Subtree directly.
Although Git Subtree does not have the function of dependency management, it is very handy when dealing with a rapidly replacing public code base, and it can achieve two-way synchronization!
2.2 Specific application
Having said so much, how exactly should this Git Subtree be used? Here Songge will give you a brief introduction.
First of all, suppose I have a project called vmall, vmall is a microservice project, which contains a lot of microservices, but also contains a common code block vmall-common in rapid iteration(note that vmall and vmall-common belong Two different warehouses).
vmall-common I have submitted it on GitHub at https://github.com/lenve/vmal... .
Now I want to reference vmall-common in the vmall project, how do I do it? Just execute the following code in the vmall repository:
git subtree add --prefix = vmall-common https://github.com/lenve/vmall-common.git master --squash
--squash parameter means that historical information is not pulled, but only a commit message is generated. This is an optional parameter and can be omitted. After the execution of this command is completed, in the vmall project, you can see vmall-common, and vmall-common will exist as a normal folder.
At this time, we can develop normally.
Let's say that we modified vmall-common during the development process. At this time, in the vmall warehouse, we can submit vmall-common to its own warehouse through the following command(first submit the changes in vmall to Remote warehouse, then execute the following code):
git subtree push --prefix = vmall-common https://github.com/lenve/vmall-common.git master
If this change is submitted in vmall-common's own repository, it is a normal Git commit command, and I don't need to say more about this.
When the code in vmall-common changes, other microservices can update the code with the following instructions:
git subtree pull --prefix = vmall-common https://github.com/lenve/vmall-common.git master --squash
These three instructions can basically handle most of the daily operations, but it is inconvenient to enter a long address every time. We can give the address an alias:
git remote add -f vmall-common https://github.com/lenve/vmall-common.git
In this way, the three commands introduced at the top 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
Today, I talked to my friends about the organization of the code in the code microservice.
In a nutshell, Maven is suitable for managing a relatively stable public code base, and Git Subtree is suitable for handling rapidly changing public code bases, and supports two-way synchronization! Some details about the use of Git Subtree, such as whether to add the
--squash parameter, and when to add it, Songge will take the time to come back and elaborate with you.
Okay, interested friends can come down and try it ~ If everyone feels rewarded, remember to click to encourage Brother Song ~