This is going to start with what I think are the biggest benefits of microservices.
Recently, I heard from several industry and research friends working in TO B Company that their RESEARCH and development team has hundreds of people, but their research and development is always dragging down the business, and the on-line delay is common. Therefore, on the one hand, I feel that there is still a shortage of people and they are hiring a large number of people. On the other hand, I feel that the system architecture is too poor and too old, and the iteration is not moving.
This makes me speechless, because my view in recent years has been that the current technical solutions have been sound enough, information technology has been good enough, all kinds of cloud ecology has been more perfect, and the technical threshold is too low to be unnecessary.
After a detailed understanding, I found that the R&D teams of these companies had been using pure single applications or larger single applications such as SOA when the business was simple and the number of engineers was relatively small, and the system architecture had not been moved.
When the business complexity came up and the number of engineers came up, we began to face dozens of people to change a service, and various codes were tampered with each other. When the codes were merged, there were all kinds of code conflicts. However, the merger was not successful, and it took a lot of effort and a long time. But the trouble is still behind, until QA involved in the test, found that the business logic of various code influence each other, bugs like bamboo shoots after a spring rain were raised, and then began to continue to change the bug to hurt each other, but there is no convergence trend of bugs in a short time. Engineers worked overtime, slept around the clock, and in pain, finally, finally, it was online, but after a long delay. The cherry was red, the banana was green, the girl was a young woman, and the son was a meter tall.
After the technical person in charge of the team to carry out the review, we reached the conclusion that the lack of people.
In fact, the real reason is not lack of people, but, the number of engineers up, but far from reaching the effect of 1+1=2. The scene is a bit like 10 people working together in a family kitchen of just a few square meters, but it’s not necessarily any more efficient than two people working well together.
So the real problem is not evolving a large single application into a microservice architecture at the right time. In my opinion, compared with single applications, the biggest advantage of microservices is that they can change the working situation of the engineer team from “concurrent” to “parallel”, so as to ensure the team’s R&D efficiency with as little loss as possible, and provide the r&d team with the ability to expand horizontally to shorten the R&D cycle.
The average product capacity released per unit time of r&d personnel is called “R&D efficiency”. By this definition, engineers are most productive when they are working on a single application. Don’t need any document to the output interface agreement, do not need of ideas and technical solutions aligned with other engineers, no business code influence each other, also do not need to solve the conflicts of merging code no cross alignment and the service, the construction of the test environment deployment becomes very easy, and on-line process is something every minute. In this case, although the human efficiency is high, but the research and development cycle is too long, the launch of a big function, month for the dimension of scheduling, is any only fast not broken Internet companies can not accept. We added people to the R&D team in order to shorten the R&D cycle as far as possible and split the micro-services on the architecture, so as to minimize the loss of the r&d efficiency of the team. After all, engineers are very expensive. If the ROI of the crowd strategy is not high, the cost of research and production will remain high, which is unbearable for most companies.
Other benefits of microservices listed in the book:
The microservices architecture allows for team autonomy
Microservices itself is a decentralized idea, and once decentralized, there must be regional autonomy. These include: autonomy of technical language, autonomy of technology selection, autonomy of data structure, autonomy of on-line deployment, etc., so that engineers can work in the way they are most familiar with and good at.
Services can scale independently
The book presents the concept of an extended cube, or three-dimensional extensible model:
X-axis expansion: No brain expansion server
Y-axis extension: Services are split by function
Z-axis extension: On the basis of the brainless expansion server, the routing field (such as: userId) is used to decide which instance to go to \
In addition, no matter which dimension is extended, microservices are small enough and cohesive enough that we can select the appropriate hardware to solve the bottlenecks in the system. For example, for computation-intensive services, the number of CPU cores can be increased to improve the parallelism capability. For IO intensive services, we can upgrade the hardware configuration of the storage corresponding to microservices; If a service eats memory, choose a server with a high memory configuration.
Each service is relatively small and easy to maintain
Microservices have less code, allowing engineers to focus and focus on the functional requirements of the business they are responsible for, which is easier to understand and maintain. But there are also two sides of the coin. For example, as an upstream service, the downstream service’s business logic and data structure are transparent to us. As a downstream service, the upstream service is transparent to us in what business scenario it calls us and how it is aggregated and displayed with other data. Also, we don’t know much about our overall system, how many other microservices are like us, and how they work. It’s like a jigsaw puzzle. The more pieces you cut, the harder it is to get the whole piece together. So once our requirement is that we need to have some understanding of the surrounding system to do a complete technical solution and implementation, we want to understand the complete operation mechanism and business logic of the whole system, it will become more difficult.
Can microservices improve performance?
Colleagues seemed to have a lot of arguments about this issue, and in the end, no one could persuade anyone.
My point is: it’s a case-by-case case, but as a general rule, microservices don’t increase performance, they degrade performance slightly.
Some people say that when a microservice is split, according to the microservice specification, the database that the service belongs to is split separately, and then the performance bottleneck is removed, and the average response time of the interface is increased.
But I think the essence of this is that you’re increasing the storage capacity and you’re increasing the performance, so try putting these separate library tables on a physical machine.
When we look at microservices from a different perspective, we are actually going from calling one service to multiple services to complete the business result, from local calls to remote calls.
Can microservices improve system availability?
There’s no doubt that microservices can be more fault-tolerant, but can microservices improve usability?
This is a very tricky problem because there are too many dimensions and the criteria are not very uniform. In the next post, I’ll see if I can shed some light on this, along with some of the drawbacks of microservices, which are mentioned in the book.
Not ended.