Like again, form a habit, wechat search【I have fried fish in my headAbsorb the essence of fried fish. Recently, I am keen to share go language, microservice architecture and all kinds of strange system design. If you have any suggestions or questions, please feel free to exchange and feedback.
Microservice, these three words are sweeping the current Internet software industry, especially in recent years after the cloud native burst out, it seems that everyone has a wider use and understanding of microservice, mouth is a variety of question marks, with a strong curiosity.
Coincidentally, a friend of mine, Li Yu, often encountered the following conversations in the early days of internal micro services (when each business group started)
- Zhang SanWhy dismantle the current code?
- carpBecause! @）&@！）！ &）@！ &！ The reason for that.
- Zhang SanWhat is the dimension of the “micro service” to be split?
- carpCommon general basis! @#*@！ #&！ （@&！ @) @.
- Zhang SanIt seems that you are not right to say that. I think the dimensions of splitting each business group are different?
- carpWell, each business group has its own opinions, which will not be exactly the same.
- Zhang San：。。。 So what is the splitting dimension of micro services?
Why do you want to dismantle it
Why does Zhang San have this question? In fact, it is because the R & D department hopes to split and transform from the original large monomer and large warehouse to the micro service system. Its original large monomer warehouse structure is like monorepo
However, there are a lot of problems in monorepo
- The volume of a single repo is too large: causes git to be unable to pull directly. When you set it up and then pull it, you can still make a cup of coffee when the network speed is slow. In addition, when the performance of the developer is poor, the IDE will compare cards and the code will run slowly.
- A single repo has a common function / SDK: in the code warehouse, there must be public dependencies. Therefore, when solving code conflicts, if conflict characters are left behind and not involved in dynamic language, it will run normally. But in fact, after going online, it affected other businesses. It was terrible. I was forced to hold the accident every minute.
- Unclear responsibility / boundary of single repo module: in the actual software development, dozens of business groups are involved in the development of a large repo at the same time. Without strong control of the boundary, it is often gradually blurred. Even if you can manage yourself in the design, you may not be able to 100% prevent others from blurring your boundary.
- A single repo contains all the source code: when the company’s source code is leaked, the whole repo will be leaked, which is quite stimulating and educational. Because although it is open and collaborative, you also have permission to view the business code that does not belong to your group.
Of course, is monorepo totally impractical? In fact, foreign companies such as Google, Facebook and twitter are using monorepo, and have made certain profits.
In fact, monorepo needs a lot of tools to support it. If it’s just a repo with multiple modules, it can’t be done well or even set fire to itself. It’s better to open it early, at least to ensure the relative independence of business line services.
What does it look like
After Zhang San understood the reasons for the split, he came up with the second question, which is the dimension of “micro service” to split services?
Zhang San’s internal knowledge of this area is in a vague stage, so we need to have an in-depth understanding to facilitate the subsequent team consensus and methodology establishment. Of course, 100000 reasons have emerged.
Big unit becomes independent service
The most common way of splitting is to split the services according to the business modules. For example, the business modules mentioned above have very clear design boundaries. In this case, it is OK to split the services directly
After the splitting, a new problem will be encountered, that is, Zhang San asked the third question, “does the splitting dimension of each business group seem to be different?”.
In the actual implementation process, SM and RD will meet together to discuss / standardize the service division of the first version. In the continuous and rapid iteration, the Rd on the front line will always split the new service.
Even if the architect does it by himself, under the relatively complex business model, what different architects divide may not be completely consistent. Therefore, no matter what the situation is, you will find that the dimensions of splitting each business group are more or less different. After all, people’s thoughts are different. One thousand people have one thousand Hamlets, so Zhang San’s doubts are correct Often.
As shown in the figure below, the core is to define a fish, which can evolve into various strange fish in the eyes of different people
Big database to independent database
In the early large cell fast iteration, a large database often contained all the business databases (even the database accounts were not divided), which would bring all kinds of problems.
For example, one day, some strange values appear in the database of the business module you are responsible for. You may have to go to all kinds of code and binlog to check. What’s more, after being attacked by the network, the database configuration is obtained, the springboard is dragged directly, and the whole thing is taken off. That’s terrible.
Therefore, in the common application design, when the application connects to the database, it will specify the connection specific domain name (for example: eddycjy user) to facilitate future migration. And each business service is given independent database read-only permission for soft isolation. After the business volume comes up, the business database will be hard isolated, and specific RDS instances will be allocated, so that they will not affect each other.
Environmental isolation, independence
After service splitting, most of them will be deployed independently to isolate the environment between them without interference or influence
For example, in cloud native, it is common to deploy and publish a business service as a service in kubernetes, and then expand and shrink the pod according to the actual resources and scheduling, so that there will be no direct interference to the resources, and there is a unified entrance management for external / internal calls.
The pain of separation
Business interface aggregation
In the process of service splitting, there are always pains. For example, when the service needs to obtain the information of “project” and “housing supply”, who will aggregate the information of these two services. Should BFF aggregate
Or a new glue service should be written to aggregate the information of “projects” and “housing resources” to ensure their aggregation and reduce the burden of BFF
Or in the case of more and more orders of magnitude, do you want to doubt whether there is a problem with the splitting of these two services, and whether “project” and “housing supply” should be one under the current business model
Obviously, in carp’s experience, he has seen all three types. Different people always choose different solutions under different ideas and business models. There is really no absolutely accurate criterion.
If we divide for a long time, we will get together
With the advancement of service-oriented process, there are two common situations
- When we first came into service: there is no service. Occasionally, there is a new small business. It can tear down several micro services and threatens to rebuild the remaining business. It can’t be persuaded back.
- With the continuous development of business: fast iteration, more and more services, duration compression, multiple Rd cross back several business services, a little bit incompetent, found that the demolition seems to be a bit of a problem, from the latest situation, it seems that some services should be combined.
- Stable business phases：。。。 There seems to be some problems in this area before, and it’s too difficult to expand. It shouldn’t be demolished like this. Who transferred me? Who is my upstream and downstream.
Most of the cases are the second and the third party, but in practice, it is not likely to merge services. Most Rd will choose to swallow it in their hearts, because the extension of construction period and the impact caused by service changes can not be directly estimated (and there are historical codes, and the personnel may have left for many years). Even the service topology can only view the service calls within a certain period of time, not all of them, so the upstream and downstream cannot be 100% determined. Therefore, on the whole, the disadvantages outweigh the advantages.
In terms of solution, it is more important to control the partition variables in the next new service planning (because we have more mature experience).
It’s really no longer possible for a new aggregation service to aggregate multiple original services, or to separate the old from the new by means of version number. They even made up their minds to move, start new services, restructure and move one by one, and continue to “thoroughly” solve the historical burden and complete the transformation.
Splitting criteria
Zhang San has spoken again. I understand what you said. Internal microservices have been developed for several years. As a person with rich R & D experience, can he release a set of criteria for microservice splitting? Otherwise, everyone will have to go through it again. What can we do? Is there any basic criteria to abide by? Now DDD is so hot, can DDD make the core consistent?
Zhang San definitely wants to split all business groups according to the core principles of splitting, so that you can have me and I can have you. There is a shadow everywhere, and the core does not deviate, so as to establish a perfect methodology
This suggestion turns right to Google’s “how to split micro services”. There are a lot of guidance materials on the Internet. It is suggested to cultivate consensus within the team first. After all, it is unscientific for everyone to compare the long string of “microservice splitting criteria” when dismantling services. More engineers will carry out the most reasonable dismantling according to their own experience.
The criterion, the core a you think, is not necessarily correct in the eyes of others. He may think it is B. therefore, the most important thing is to reach a consensus in the business unit and business team, integrate the idea of splitting into each Rd idea, and make a long-term joint analysis of the current situation of splitting, and let everyone basically agree.
At the same time, let the whole company do it according to one criterion. In the case of service splitting, which can not be controlled by tools and processes, it is a false proposition in itself. It will be more a compromise between people, and it will basically become a “guidance” document that few people see.
summary
In the micro service, the separation of services can always make people savor so carefully. This paper is not specific about a few knowledge points, but more about the “conflict points” or “contradiction points” in the process of service development. Different people always have different understanding, hoping to bring some thinking to you.
In addition, when reading the relevant guidelines on micro services, it is more recommended to look at the experience sharing of splitting after enterprise practice. Otherwise, it is meaningless to simply look at the “guidelines”, which depends on the specific company / team situation and business model.
Recommended reading
Monorepo：
- Why Google Stores Billions of Lines of Code in a Single Repository
- Monorepos: Please don’t!
- Why might a project/company use a monorepo?
Microservices：
- Nginx Refactoring a Monolith into Microservices
My official account
