Whether you like microservice or not, now microservice is undoubtedly a topic that programmers can’t get around. Whether you want to change the current architecture into microservice, or you want to go out for an interview for a more advanced position, you need to have a deep understanding of microservice.
When it comes to micro service, many programmers love and hate it. They want to learn micro service, but they don’t know how to start. After learning a little, they can’t find a place to practice it. In a word, I feel that micro service is remote and difficult to control.
The first thing to understand is that there are routines for micro services, and these routines basically solve almost all the important problems faced by the micro service structure.
These routines are the architecture mode of microservice
If we can deeply understand the origin and development of these models, we can understand most of the content of micro services. Fast learning and great practical value.
1. The most basic mode of micro service
This article first talks about the first most basic mode. I think it will take three articles to explain this mode. This is the first one. I plan to write practice in the second part and problems in the second.
I hope you can learn easily.
The basic mode of micro service is as follows:
One service and one database
The above figure is the simplest microservice model.
The mode of one service and one database is the most basic and core mode in microservice architecture. It seems simple, but this mode contains the most basic idea of micro service.
To understand the pattern of one service and one database, we need to ask why we need to develop micro services.
2. Problems of traditional system
When it comes to microservices, the concept corresponding to microservices is called monolithic application. In short, micro service is derived to solve the problem of single system. The structure of single system is as follows:
So what’s wrong with this kind of monomer structure, which leads to the fact that we have to open and close micro services now?
3. The monomer system is too large
The most important reason is that the application system is too large. Because of the huge size of the application system, if it is only a single system, it will cause a variety of problems, which are reflected in the following three aspects:
3.1. The business of the system itself is complex and there are many modules
With the development of the system, more and more business needs. In order to meet these requirements, the whole system has more and more modules. With more and more system modules, fewer and fewer people can understand the whole system, until no one can understand the whole system.
3.2. The code base of the system is very large
The amount of code will also increase with the increase of the system. The huge amount of code will affect the whole development process and lead to high development cost.
- First of all, the amount of code is large and the dependency relationship is complex, so it is very energy consuming for the new developers to configure the development environment.
- Secondly, due to the large amount of code, more memory is needed to load these codes and the corresponding dependencies, so the ide of developers will run very slowly and it will be troublesome to edit the code.
- Thirdly, there is a large amount of code. If you want to compile and package the whole code, you need a lot of memory. Therefore, after the function development is completed, the construction of the system will be very slow, and the whole construction time will be very long.
- Moreover, due to the large amount of code, almost no one can have a more in-depth understanding of the overall code. Even if one of the functions to be changed is too complex, developers will not understand it deeply. And these not in-depth understanding will make developers unable to use the best way to do function development, resulting in hidden bugs.
3.3. The technical team has become very large
Due to more and more functional modules, it needs more and more developers to develop and maintain the system. However, these developers are all faced with the same set of code base, although they can do branches, we can do our own. But once you need to integrate the code and release it online, it’s a nightmare.
All kinds of code conflicts and code loss may occur when online.
Moreover, due to the concern of code loss and conflict, it is necessary to conduct sufficient tests before going online, and these tests need to invest a huge time cost.
However, now we are all talking about agile development. It’s very likely that the follow-up business requirements will come one after another before it’s launched. It’s really fatal.
4. Personalization of business requirements
Another important reason for micro services is the personalization and granulation of business requirements.
With the development of business, whether it is due to market competition or the needs of its own development, it is bound to need the in-depth mining of its own business model and improve the user experience of using the system. Based on these, it is necessary to make every function module of the system deeply.
This will lead to several new problems
4.1. The system function modules may become more and more complex
The functional modules of the system may be continuously divided into more detailed modules, which may be broken into particles. As the functions become more fragmented and granular, it will make it easier for product managers to put forward some very detailed business requirements.
These very detailed requirements are likely to cause frequent functional modification and online requirements. But these inexhaustible fast demand relative to the whole huge system on-line and the developers’ fatigue form the most intense conflict.
4.2. The technical requirements of the functional modules to the system conflict
For example, different function modules, order module and payment module. The order module hopes that the system can process a large number of orders at the same time as much as possible, and even have a certain fault tolerance. If there is a problem, it can cut the order.
But the payment module is not the same, the payment module hopes the system can be as stable as possible, and must have high accuracy requirements, almost no fault tolerance space.
Similarly, in the same payment module (depending on the module division of the system), there may be local account transfer and tripartite channel payment at the same time. Local account transfer may need to be instant, which requires extremely high response time. But for the third-party payment, it can have a certain tolerance of response time.
If the system itself is a single system, it is bound to require developers to make a compromise on the whole system and make a certain trade-off on the conflicting technical requirements. This trade-off is likely to affect the overall experience of the system.
4.3. The requirements of the system module to the server conflict
Due to the intensive cultivation of functions, there will inevitably be different performance requirements.
For example, the order module of the system, individual orders may be frequently accessed, at this time, we need more clusters of the system to handle these large-scale access. However, in the same functional module, there may be some group buying needs of enterprises. They do not need so many server clusters because they do not have so much access.
For another example, user comment screenshots may require a lot of data storage. However, similarly, personalized recommendation for users may require large-scale intensive computing.
In addition to the above, some subsidiary problems caused by the huge system:
4.4. Chain reaction problem of failure
Technically, each module of a single system is coupled together. In the actual operation, it is likely that a fault will lead to the collapse of the whole system.
For example, an unusual XX function has a memory leak, which makes the whole system unavailable.
4.5. Technical locking of the system
Frankly speaking, you have to admit that in programming, no language is perfect, and no database is omnipotent.
For example, Java is not as convenient and efficient as Python in scientific computing. For example, when we need to store very complex object relationships, MySQL and Oracle are not as good as any kind of graphic database.
So,The more complex the system, the higher the probability of requiring different technologies. But because of the complexity of the system, the greater the risk of introducing new technology. Therefore, the use of new technology is very difficult.
At the same time, after the system is huge, if some components, even the language SDK itself, need to be upgraded, it is also a cumbersome and risky thing. Therefore, it is very difficult to upgrade the technical version.
To sum up, for the traditional single application, the technical problems caused by the huge system and the demand conflicts caused by the business development can not be solved by the single system architecture.
So why can’t SOA solve these problems?
5. The problem of SOA
Let’s take a look at the structure of SOA first
You can see that there is an ESB (Enterprise Service Bus) in the SOA architecture. This ESB is dedicated to SOA services and interaction between services. It is a necessary infrastructure for SOA.
Because SOA has the idea of service bus, it is doomed that the services segmented by SOA can not be too detailed, because the more services appear, the service bus will eventually become a bottleneck of the whole system.
The service segmentation scale of SOA is limited, which will bring the following problems:
Segmentation is not detailed enough – as we said, our main problem is that the system is too large and piled up. If our segmentation is not detailed enough, the possible result will be that the system is divided from a very large system into a few very large systems, and the problem is not solved in the end. Apart from that, it may also be because the system has become a different distributed service, and the problems brought about by the introduction of a new distributed system itself.
ESB itself may become a huge and incomparable system monster — as the infrastructure of SOA, ESB itself is complex enough, and it may become a terrible system monster itself due to the development of business. So developers not only need to maintain the original system, but also need to worry about how to maintain and modify the ESB itself.
Therefore, it can be seen that SOA is not enough to solve the problems caused by large single system.
6. Why do you need services
Back to the topic of our micro service. When we know the root of the problem, we need to tackle it.
First of all, since the problem is caused by the huge complexity of the system, then we can refer to the very common solution idea in software: divide and conquer.
No matter how big a system is, if we break it down small enough, we can split a complex large system into many small systems, and then let the decomposed small systems aggregate them into a large complete system by means of providing external services. In the end, it is equivalent to the original complex large system. And this is the most simple idea of micro service.
Therefore, there are two core ideas of micro service
- Split the system into different parts
- These parts should be small enough
In doing so, microservices bring several benefits:
No matter how complex the system is, as long as I can dismantle it, I can simplify the problem, so that I don’t have to fear that the system will become complicated.
As long as the split service is small enough, it can get countless benefits in terms of development, deployment, operation and maintenance that could not be obtained because of the huge system: it may be easier to modify the code, and easier to test and run
The separated services can develop independently and will not restrict each other. When the original system is a single system, due to the technical coupling between modules, it is not free to choose the most suitable technology for the current function module, and it is not free to flexibly arrange the server according to the load of the current function module.
The fault is naturally isolated. We divide the system into services, and each service has its own process or server, so that the failure is isolated from the physical level, so as to avoid an unimportant functional failure leading to the collapse of the whole system. We just need to make the core function robust enough, even if the non core function has a problem, it will not cause too much loss.
Therefore, a huge system, because of its bloated and complex, may have to split itself. According to some guiding principles, if the disassembly is small enough and simple enough, the benefits will be considerable.
7. Why do we need to dismantle the warehouse
The service has been dismantled, and it has gained so much benefit.
“But why does the database have to be disassembled?”——This is actually the most puzzling question for many students who use micro services.
Database splitting is essentially a problem of data sharing. The concept of a service and a library itself is to avoid data sharing as much as possible.
Data sharing will bring the following problems:
7.1. Technical implementation is still possible
Because there is no database splitting, it is likely that a service module that should have been independent must rely on another service module, which conflicts with our original intention of splitting services.
For example, order service and personalized recommendation service may need to access order related data. At this time, if the database is not disassembled, it is likely that the structure of the order table will be modified due to the demand of the order business, and the personalized recommendation service will also be modified.
7.2. Over exposure of underlying data
As for the above example of order service and personalized recommendation service, personalized recommendation probably only needs some user ID, order category and so on. However, because the database is shared, it is likely that all the data in the order table will be open, and many of these data are sensitive data that should be hidden, but now they are exposed.
7.3. Unnecessary data access competition
Because it is the same database, it is bound to cause competitive access to the shared data, and these competitive access will greatly affect the elastic deployment of business modules. For example, the order module is likely to affect the amount of concurrent data it can carry due to some scheduled batch queries of personalized recommendation.
Therefore, it can be seen that the whole microservice architecture must be considered.
8. Leave a tail at the end
Each service corresponds to a database, which is the core and basic mode of microservice
Splitting and decoupling
Generally speaking, most of the time, microservices will try to adopt the mode of one service and one database.
Here, we only talk about why we need to use a service and a database, how to divide the service and the database, and whether there are some practical compromises, which will be carefully analyzed in the next article.
Hello, I’m four ape Wai.
Technical director of a listed company, managing more than 100 technical team members.
I changed from a non computer major graduate to a programmer, working hard and growing up all the way.
I will pass the official account.
Write your own growth story into an article,
Turn boring technical articles into stories.
I set up a reader exchange group, most of which are programmers, talking about technology, work and gossip together. Welcome to add my wechat, pull you into the group