In today’s article, we continue to tell the story of Liu of architecture Normal University.
The story is purely fictional. Don’t take your seat according to the number.
Liu has been doing well recently. He often wakes up from a nap and continues to read novels and fish with his mobile phone. Liu is quite satisfied with his current company. Most of the systems are mature and stable, and the number of users is regular. Although the technology of some projects is old, the advantage is that there are no moth technical problems waiting to be solved.
But sometimes big Liu will beat the drum in his heart, the company’s profits are declining, the peak is not there, and he doesn’t know how long the company can last. In addition to occasional worries about job stability, Liu is in a happy mood most of the time. Until he was called by the leader to the office to assign new tasks
Liu’s leader, CTO Lao Li, is not in a good mood these days. The company he worked for was originally a company focusing on traditional business. In order to keep up with the Internet age, the big boss patted his head and set up a technology department to engage in the Internet. Although the company has been known to have touched the net, the company’s profit basically depends on traditional business, and the technical department is only playing an auxiliary role. There is no business initiative and no profit point, but the wages of department employees are not low. Lao Li’s status is general, and he is often stifled by some cold words. In addition, the company’s efficiency has also declined recently, seeing that the technology department is facing the risk of layoffs. Lao Li’s sense of crisis was greatly stimulated.
Lao Li comes from a technical background, but he has been away from front-line coding for nearly ten years. His daily work is actually the concept of management and play. In recent years, the concept of micro service has been very popular. Lao Li has always wanted to make some of these popular things, and then take these new concept technologies to show his two brushes to the big boss who doesn’t understand technology. At the same time, he can also make a reputation in the industry, which is also good for his career development. Taking advantage of the future of the Department, Lao Li thought that this was also a good time to engage in micro services. At the same time, he also thought of Liu who had experience in micro services. So Liu was called into the office
After several hours of discussion, Liu took over the task with a helpless face. The task is as follows:
Transform several core systems in the company that have been running for many years into micro services.
These old systems were originally designed and developed according to the goal of tens of thousands of users. Although there is no problem running now, we should look at the long term. Products and technologies will develop a set of more advanced things, and the goal is that this system will be used by millions of people.
OK, the premise of using microservices appears.
Before coming to this company, Liu worked in a large e-commerce factory for many years and had practice and experience in the application of micro services in e-commerce system. For micro services, Liu has eaten pork, seen pigs running, and been bitten by pigs… Well, yes, he has been bitten more than one or two times. Therefore, Liu is determined to transform the micro service.
Although Liu was helpless, he still had to work for the sake of salary. However, the slot still had to vomit, so after work, big Liu spent a few hours coding out the following pile of heartfelt words.
At the beginning of the text (the following is Liu’s first person):
Recently, my colleagues often talked about micro services with me, and they often expected to transform the existing projects of the company, hoping to transform all projects into micro services. I am often speechless about this and often dissuade these people.
I think some of the people who advised me to transform microservices are simply too obsessed with technology. What’s more, I can even say that some of these people are purely selfish. Is it not to rub the hot spots, add color to your resume and prepare for job hopping and salary increase in the next step? Have you ever thought about the various disadvantages brought by microservices to the company and the resulting cost increase? Others are simply stunned by the overwhelming concept of micro services and brainwashed by various success stories of micro services. These people regard microservices as a panacea. They are simply confused and fall into technology only theory.
To illustrate that microservices are not a panacea, let’s first explain the concept of microservices. At the same time, we also need to explain the advantages and disadvantages of microservices and see when to use microservices and when not to use them.
What is micro service? There are different opinions on the definition of micro service on the Internet, and there is no authoritative definition. However, there is always a unified basic aspect after these complex and misty micro service brainwashing and expositions: that is, micro service is an architecture method that uses the idea of divide and conquer to segment a set of very complex business logic into multiple simple business problems, and uses modular method to realize combination.
Is that still abstract? OK, let’s explain it more deeply and clarify all the advantages and disadvantages of microservice.
First, microservices adopt the idea of divide and conquer, and need to decompose the business logic. After decomposition, multiple corresponding implementation modules are needed to implement the decomposed business problems. The development and maintenance of these modules need cost. If we want to engage in micro services, have we considered the development and maintenance costs?
The above figure shows that from the beginning of the project, the average cost of code development and maintenance of microservices is many per line. With the increase of project scale and system complexity, the average cost of code development and maintenance will slowly decrease and gradually converge to a certain value.
The single project is just the opposite. At the beginning, the average cost of each line of code of the single project is relatively low. With the increase of project scale and system complexity, the cost of code development and maintenance will slowly rise, and the subsequent complexity and development cost may become higher and higher, which has been rushed into the sky.
At this time, people have to be forced to find a more appropriate method to reduce the development and maintenance cost to a level that the project team can afford.
This is the significance of introducing microservices.
But will all projects continue? Will all projects run and expand forever?
Many architects or technicians do architecture and system design at the beginning without considering the actual situation. After the company gives a very urgent task, they do not consider the implementation time and development cost. Is it realistic to start with micro services?
We technicians have seen many technical books advocating microservices and many “success studies” of microservices, but what is their premise? What they say about microservices is all based on a perfect world with only technology, excluding all the noise they think of in the real world. Is this appropriate?
Before we become architects, the first consideration should be input and output. Of course, from a technical point of view, we must consider technical indicators such as scalability and maintainability. However, we also need to make our own balance according to the importance of the current project, profit prospects and available server resources.
Second, another advantage of microservices is flexibility. What do you mean? When we change the business logic, we can add, delete and modify the functions corresponding to the business logic change. The development and deployment cost is very low and can be reduced and increased freely like a spring.
Moreover, the best practice in microservices is that each separated module should have its own database and does not share any database with other microservices. Therefore, the microservice itself believes that the database of each microservice module can be different.
For example, if we develop an e-commerce website into a micro service, it is roughly as follows:
If we make some adjustments to our business logic, for example, we want to add an integration function, then we only need to add another micro service called integration.
This is the convenience of microservices.
However, let’s admit that not every system we do is large enough to be decomposed into more and smaller services. Those are not too complex systems. Why do they need to be flexible? Why do you need to segment the business to create a lot of projects?
In addition, the problem brought about by the flexibility of micro services is that we need to manage many small projects cut by flexibility. We need to develop an easy-to-use automatic management system and build the company’s underlying infrastructure. Excuse me, are you ready to pay these costs?
In this real world, not everything revolves around technology. Of course, technology debt will make us technology practitioners feel particularly troubled and uncomfortable. However, if we use advanced concepts and advanced architectures that we may not need, it will also make us feel painful.
If we control our technological desire, do we also control part of our technological debt from ourselves? This is a place that architects should think about and one of the reasons why we should not abuse microservices.
Third, microservices start with distributed. I admit that distributed has various advantages, but the problems caused by distributed and the various technical solutions that need to be introduced also have their own problems.
For example, distributed transactions. Before introducing microservices, as architects, we must consider whether cross service transactions may occur in the future. Brother, we all know how difficult distributed transactions are.
According to the microservice standard, the communication between services should adopt a simple restful protocol as far as possible. Then, according to this specification, if we adopt the micro service architecture, each of our projects should be made into rest services. Rest services are stateless. Now, if there are cross service transactions that rely heavily on state in the business, think about what you will face:
Do you want to consider the distributed lock scheme? After distributed interlocking, deadlock occurs. What is your tracking strategy? If there are competing resources, resulting in inconsistent service status, how can you recover quickly? Data corruption, do you have a way?
what? You told me that there are many mature distributed transaction solutions on the market? Don’t deceive yourself. We are all engaged in technology. Excuse me, are you talking about two-stage submission (2pc)? Well, everyone knows the pitiful performance of 2pc.
Well, what about three-phase submission (3pc)? Its inconsistency once kept us awake all night.
What about TCC or saga? Sorry, the business tightly coupled messages and notifications added by the final consistency will be like a 24-hour nightmare and may be the last straw to crush you.
Martin Sr., an advocate of microservices, also said that microservices introduced the issue of final consistency.
For the simple transaction problem of the original single project, it is a frowning difficult problem in microservices. All microservice developers need to consider how to detect data inconsistency before developing microservice code. Otherwise, you will regret it.
So, will distributed transactions necessarily appear in microservices? At present, it is almost inevitable. In order to solve these problems, microservice implementation often needs to be accompanied by the implementation of a set of call chains built on stateless services.
Are we necessary for these additional development costs? Is it required for all projects? no This is what our architects need to consider and where we need to be cautious and compromise.
Fourth, microservices cooperate with each other through network communication to provide services. This will lead to a dependency problem, that is, microservices are very dependent on the health of the underlying network.
If there is a problem between network communication, the overall external service quality will be reduced to an extremely unacceptable level.
Moreover, network communication will naturally bring delay. Originally, we had a good single project. Everyone communicated with each other internally, and the delay was basically negligible.
Now, we are separated. We have to say hello to each other from a distance. The delay is often tens of milliseconds or hundreds of milliseconds. These delays, we also need to take into account, must go through strict testing.
In addition, various fault-tolerant schemes after network communication problems must also be considered and improved. All the above are comprehensive considerations that a qualified architect must make before the introduction of microservices.
Other: there are various problems with the introduction of microservices, including:
Additional complexity introduced
As I said above, microservices will bring all kinds of cost increases and introduce all kinds of technical problems. These will eventually lead to the further improvement of the overall system complexity. When the complexity increases, in order to ensure the stability of the system, we need the reliability of the overall technical team, the reliability of technicians and the reliability of the overall technical facilities. Before introducing microservices, please ask yourself, do you have any of these companies? Do you have these teams, these facilities, these resources?
The cost of distribution itself
Distributed itself requires a complete set of technical systems and facilities to support the overall distributed construction. For example, in the past, a single project only needed one project, and it would be good to go online manually. Now, there may be dozens or hundreds of projects. If all these projects are done manually, they will completely drive the team crazy. Therefore, it is necessary to automate the overall release and deployment. Here is only what is needed for release and deployment. Maintenance has not been discussed. In the words of Liu Huaqiang in conquest, “do you have this strength?”
Devops team required to maintain and monitor microservices
Microservices themselves need to be maintained and monitored to ensure stable and reliable operation. In the best practice of microservices, Devops is highly recommended. I don’t mention the high requirements for personnel level required by Devops for the time being. I’ll just talk about the work attitude and sense of responsibility required by Devops itself. What’s the construction of my own O & M team like? Who doesn’t know what to do when O & M is busy all day? With the average level of overall operation and maintenance and the requirements of development level, how much does it cost to build this team? Is the company willing to invest?
Experience required by microservices themselves
Microservice itself is very complex. From the design division of modules, architects must be very experienced in architecture design and DDD domain driven design corresponding to microservice itself, and be able to divide the corresponding modules appropriately. Otherwise, once the design is completed, it happens that some tightly coupled services are simply decoupled into different services, then the consequences will be disastrous for the whole technical team and even the whole project team. At the same time, for the development, maintenance, operation, guarantee and operation and maintenance of micro services, the members of the technical team need to have rich professional experience, be able to quickly find, locate and solve problems that may arise at any time. If the technical problems cannot be solved in time, the experience of the overall system can be imagined. However, given the current economic environment and the current composition of the company’s technical personnel, are you sure you can have these highly experienced personnel to engage in micro services?
Link test method
As mentioned above, in order to quickly track and locate deadlocks or share resources, microservices need a reliable call chain implementation. Then, this leads to a new question: how do we conduct full link testing? Do we still have to develop a set of appropriate full link test tools? How long does it take to develop the full link test tool and how much manpower is needed? Does the level of testers also need to be guaranteed?
Microservice log explosion
Microservices have multiple nodes. These nodes need many unique logs for their own safe operation and maintenance. With the increase of micro services, there are more and more logs. How do you save them? How? How to delete? Should all these be taken into account?
These problems mentioned above do not deny microservices.
I just hit people who advised me to do micro services when I’m fine. For those who don’t think about anything and talk about micro services, I think they are both stupid and bad.
Regardless of the current situation, I advise you to take it easy to talk about micro services.
After writing, Liu felt a sullen breath in his chest. After his mouth addiction, he was happy. Now what Liu is most worried about is that these words must not be seen by the leaders
Liu’s story is over. I’ll talk a little more. Microservices must be advanced, but it’s already 2021. I don’t need to introduce the advantages of microservices to you anymore. It’s too vulgar.
I hope you can understand that it is not a new technology, and the hot concept is suitable for your own team and project. To be a qualified architect and technical director, we should first follow the kiss and YAGNI principles.
All technicians should always be rational. What we have to do is to choose the correct and applicable technology rather than our favorite technology. Please don’t be a technical madman who does simple things into complexity.
Hello, I’m four apes.
He is the technical director of a listed company and manages more than 100 technical teams.
I changed from a non computer major graduate to a programmer. I worked hard and grew all the way.
I will write my own growth story into an article and a boring technical article into a story.
Welcome to my official account, and I can get the dry cargo learning materials such as algorithm and high concurrency.
I set up a reader exchange group, most of which are programmers. They talk about technology, work and gossip together. Welcome to wechat and join us.