1 Interview questions
- Why do we need to split the system?
- How to split the system?
- Can I not use dubbo after splitting?
2 Test site analysis
Since the beginning of this section, the distributed system link has been carried out. Many students said that now that the distributed system has become a standard configuration, there is no company that does not ask you about the distributed system. If you don’t know how to distribute things, it’s almost impossible to read this resume, and no one will let you go for an interview.
Why is it actually like this? This is because of the technological development of the entire industry
In the early years, at the beginning of 2010, in the entire IT industry, few people talked about distributed, let alone microservices. Although many large companies such as BAT, because of the complexity of the system, they used distributed architecture and a large number of services. , It's just that most of the microservices are implemented based on a set of frameworks they build.
But it is true that in that era, everyone attached great importance to ssh. Almost most small and medium-sized companies played struts2, spring, and hibernate. Later, they entered the combination of spring mvc, spring, and mybatis. At that time, the technical level of the entire industry was like that. Back then, Oracle was very popular, and Oracle administrators were very popular. Oracle performance optimization was a big killer for IT men. No one even mentions big data. At that time, certification training institutions such as OCP and OCM were not enough.
But it is true that with the development of the times, slowly, many companies have begun to accept the distributed system architecture. This is particularly important for the industry, and it is Ali’s dubbo. To some extent, Ali is here to promote The advancement of industry technology.
It is precisely because of Ali's dubbo that many small and medium-sized companies can split the system into many services based on dubbo. Everyone is responsible for one service. There is no conflict in everyone's code. The service can be autonomous. You can choose any technology. , If you change one service each time you release, then you can launch one service. You don’t need to coordinate and debug together. Each release is hundreds of thousands of lines of code, or even millions of lines of code.
To this day, I am very happy to see that distributed systems have become standard in industry interviews. Any ordinary programmer should master this. In fact, this is the progress of the industry and the technological progress of all IT coders. So now that distributed systems have become standard, the interviewer will of course ask, because many companies now have distributed, micro-service architectures, so of course the interviewer has to investigate you.
If a classmate sees this and says, God, I don’t know what a distributed system is? I don't know what dubbo is? Then you hurry up on Baidu, search for an introduction to dubbo, and go inside to experience it.
Distributed systems, let me explain to you in one sentence. There is really no time to chat. The original system with 200,000 lines of code is now split into 20 small systems, each with 10,000 lines of code. The original code was directly based on spring calls, but now it has been separated. 20 small systems are deployed on different machines, and an rpc call based on dubbo is needed. The interface and the interface communicate through the network to request and respond. That's what it means.
3 Detailed
3.1 Why the system is split
Checked online, the answer is extremely fragmented and complicated, very trivial, and the reasons are huge. But here is an intuitive feeling for everyone:
3.1.1 No split, high maintenance cost
If it is not split, a large system with hundreds of thousands of lines of code, 20 people maintain a code, it would be a tragedy. The code is often changed and it conflicts. Various code conflicts and merging have to be dealt with, which is very time-consuming; often I change my code and you call me, which causes your code to be retested, which is very troublesome; then Every release is a system with hundreds of thousands of lines of code. Everyone has to prepare to go online together. With hundreds of thousands of lines of code going online, there may be a lot of checks and handling of many abnormal problems. It is troublesome and painful; and if I plan to upgrade the technology to the latest spring version, it will not work, because this may cause your code to report errors, and I dare not change the technology at will.
Suppose a system is 200,000 lines of code, of which A has changed 1,000 lines of code in it, but when it is released at this time, the large system of 200,000 lines of code is released together. This means that there may be various changes in the 200,000 code online. 20 people, everyone must wait in front of the computer nervously. After going online, check the log to see if there is any problem with the one they are responsible for.
Little A checked the functions corresponding to the 10,000 lines of code that he was responsible for, and made sure that ok was flashed; unfortunately, when Little A went online, he accidentally modified a certain configuration of the online machine, resulting in another Little B. Some functions corresponding to the 20,000 lines of code that Xiao C is responsible for, something went wrong
Dozens of people are responsible for maintaining a single block application with hundreds of thousands of lines of code. Each time it goes online, prepare for a few weeks, go online -> deploy -> check the functions they are responsible for
Recently, from 2013 to the present, in the five years, before 2013, it was basically the world of BAT. Since 2013, several small giants have begun to develop rapidly, listed, tens of billions of dollars, and valuations are almost Ten billion U.S. dollars; in 2015, in addition to BAT, several small giants in the Internet industry appeared.
BAT work, working for a small giant with a market value of tens of billions of dollars
There is a small giant, now a small giant with a valuation of tens of billions of dollars. When it first started five years ago, dozens of people maintained a single application for its core business.
It is very suitable to maintain the application of a single block in the link from 0 to 1, because at that time, the system was not online, there were no technical challenges, and everyone developed in an orderly manner. ssh + mysql + tomcat, may deploy several machines.
The result was not good. Later, the system went online and the business developed rapidly, with 100,000 users -> 1 million users -> 10 million users -> hundreds of millions of users.
3.1.2 After the split, the world is clean
After the split, the whole world is refreshed. The system with hundreds of thousands of lines of code is split into 20 services, with an average of 10,000 to 20,000 lines of code for each service, and each service is deployed on a separate machine. There are 20 projects, 20 git code repositories, and 20 code farmers. Each person can maintain his own service. It is his own independent code and has nothing to do with others. There are no more code conflicts, cool. Just test my own code every time, cool. It’s fine to publish a small service of my own every time. Technically, you can upgrade as you want, just keep the interface unchanged, cool.
So to put it simply, in one sentence, if it is a medium-to-large project with hundreds of thousands of lines of code, and there are dozens of people in the team, then if the system is not split, the development efficiency is extremely low and there are many problems. But after disassembling the system, everyone will be responsible for a small part of themselves, and they can play and do whatever they want. After the distributed system is split, the development efficiency of large teams of complex systems can be greatly improved.
But at the same time, it should be reminded that after the system is split into distributed systems, a large number of problems faced by distributed systems will follow one after another, so the following problems are around the complex technical challenges brought by distributed systems. Say.
3.2 How to split the system
This question can be said to be big, it can be related to domain-driven model design. If it is small, it is also very small. I don’t want to give you an overly academic argument, because you can’t recite this answer. Let’s just talk about it in the past. . It's still a bit simpler, and everyone knows how to answer it.
The system splits the distributed system, splits it into multiple services, splits it into a microservice architecture, and splits many rounds. An architect was dismantled in the first round, the first round; the team continued to expand, and a certain service was dismantled. At first, one person maintained 10,000 lines of code. Later, the business system became more and more complex. This service is 100,000 lines of code, 5 people; second round, 1 service -> 5 services, each service 20,000 lines of code, each person is responsible for one service
If multiple people maintain a service, <=3 people maintain this service; ideally, dozens of people, one person is responsible for 1 or 2~3 services; the workload of a certain service becomes larger, and the amount of code is increasing The more a certain classmate is responsible for a service, the amount of code has become 100,000 lines, and he is overwhelmed. He is now dismantling it by himself, with 5 services, 1 person supporting, 5 people in charge, and then recruiting people. 2 people, bring it to that classmate, 3 people are responsible for 5 services, of which 2 people are responsible for 2 services each, and 1 person is responsible for 1 service
I personally suggest that there should not be too much code for a service, about 10,000 lines, 20,000 or 30,000 will be dead.
Most systems need to be split in multiple rounds. The first split may be to split the previous multiple modules. For example, split the e-commerce system into an order system, a commodity system, Procurement system, storage system, user system, etc.
However, each system may become more and more complex in the future. For example, the procurement system is divided into a supplier management system, a purchase order management system, and the order system is split into a shopping cart system, a price system, and an order management system. .
It’s really deep, so I’ll give you an example first. You can feel it yourself. The core meaning is to split a round according to the situation. If the system becomes more complicated later, you can continue to split. Just think about it based on the example of your own system.
3.3 Can I not use dubbo after splitting?
Of course, it's okay. The biggest problem is that between the various systems, directly based on spring mvc, they communicate with each other on the pure http interface. What else can be done. But this is definitely a problem, because the http interface communication is very costly to maintain. You have to consider various messy issues such as timeout retry, load balancing, etc. For example, your order system calls the commodity system, and the commodity system is deployed 5. One machine, how do you evenly distribute requests to those five machines? Isn't this load balancing? It's okay if you do it all by yourself, but it's really painful.
So dubbo is blunt, it is a kind of rpc framework, that is, the local is to call the interface, but dubbo will proxy the call request, communicate with the remote machine network, and handle the load balance for you, the service instance is automatically sensed when the service instance goes online and offline, and the timeout is heavy. Tried, wait for the messy questions. Then you don't have to do it yourself, just use dubbo.