Whether you like microservices or not, microservices are undoubtedly a topic that programmers can't get around. Whether you want to change your current architecture to microservices, or you're going out to interview for a more advanced position, you need a deep understanding of microservices.
When it comes to microservices, many programmers love it and hate it. They don't know how to start when they want to learn microservices. After learning a little, they can't find a place to practice. In short, it feels that microservices are out of reach and difficult to control.
The first thing to understand is that microservices have routines, and these routines basically solve almost all the important problems facing the microservice structure.
These routines are the architectural patterns of microservices themselves
If we can understand the ins and outs of these patterns, we can understand most of the microservices. Quick learning and great practical value.
1. The most basic pattern of microservices
This article will first talk about the first and most basic mode. I estimate that this mode will take three articles to explain thoroughly. This is the first article. I plan to write the practice in the middle part and the problem in the next part.
Hope everyone can learn easily.
The most basic pattern of microservices is:
One service one database
The above picture is the simplest microservice pattern.
One service, one database model is the most basic and core model in the microservice architecture. It looks simple, but this pattern contains the most basic ideas of microservices.
To figure out the pattern of one service and one database, we first need to ask why we want to engage in microservices.
2. Problems with traditional systems
When talking about microservices, the concept corresponding to microservices is called a monolithic application. Simply put, microservices are derived to solve the problem of monolithic systems. The structure of the single system is as follows:
So what's wrong with this monolithic structure, so now everyone has to talk about microservices?
3. Monolithic systems are too big
The first and foremost reason is that the application system is too large. And because the application system is too large, if it is only a single system, it will cause various problems, which are reflected in the following three aspects:
3.1. The system itself has complex business and many modules
As the system develops over time, there are more and more business requirements. In order to meet these demands, the whole system has more and more modules. The more and more modules of the system, the fewer people who can understand the whole system, until finally 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 affects the entire development process, which will cause the entire development cost to become very high.
- First of all, the amount of code is large and the dependencies are complex, so it is very labor-intensive for new developers to configure the development environment.
- Secondly, the amount of code is large, and more memory is required to load these codes and corresponding dependencies, so it will cause the developer's IDE to run very slowly, making it very troublesome to edit the code.
- Third, the amount of code is large. If the entire code is to be compiled and packaged, it will require a lot of memory, so it will also cause the construction of the system to be very slow after the function development is completed, resulting in a very long time for the entire construction.
- Furthermore, the amount of code is large, and almost no one can have a relatively in-depth understanding of the overall code. Even if one of the functions to be changed may be too complicated, developers will not understand it deeply. And these lack of in-depth understanding will prevent developers from using the best way to develop features, resulting in hidden bugs.
3.3. The technical team has become very large
Due to the increasing number of functional modules, more and more developers are required to develop and maintain this system. However, these developers are all facing the same set of code bases, although branching can be done, everyone can do it differently. But once you need to combine the code and release it online, it is a nightmare.
Various code conflicts and loss of code may occur when going online.
Not only that, due to concerns about code loss and conflict, it is necessary to conduct a sufficient number of tests before going live, and these tests require a huge time cost.
However, now that we are talking about agile development, it is very likely that the follow-up business needs will follow one after another before the launch, which is simply fatal.
4. Personalization for business needs
Another important reason for microservices is the personalization and granularity of business requirements.
With the development of the business, whether it is due to market competition or the needs of its own development, it is bound to need to deeply mine its own business model and improve the various experiences of users using the system. And based on these kinds of things, it is bound to make every functional module of the system deeply and thoroughly.
This raises several new questions:
4.1. System function modules may become more and more complex
System function modules may be continuously broken down into more finely divided modules, which may be broken into particles. And because 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 result in frequent functional modifications and online requirements. And these endless fast demands have formed the most intense conflict with the overall huge system launch and the exhaustion of developers.
4.2. There is a conflict between the technical requirements of the functional module for the system
For example, different functional modules, order modules and payment modules. The order module hopes that the system can process a large number of orders at the same time as much as possible, and even has a certain degree of fault tolerance.
However, the payment module is different. The payment module hopes that the system can be as stable as possible, and must have extremely high accuracy requirements, and there is almost no room for fault tolerance.
Similarly, in the same payment module (depending on the system module division), there may be local account transfer and three-party channel payment at the same time, and local account transfer may need to be immediate and require extremely high response time. But for third-party payment, there can be a certain tolerance for response time.
If the system itself is a single system, it is bound to require developers to make certain compromises for the entire system and make certain trade-offs for conflicting technical requirements. And this trade-off is likely to affect the overall experience of the system.
4.3. The system module has conflicting requirements for the server
Due to the intensive cultivation of functions, different performance requirements are bound to appear.
For example, in the order module of the system, individual orders may be accessed frequently. At this time, more clusters of the system are required to handle these large-scale accesses. However, in the same functional module, there may still be some corporate group buying needs. They do not have such a large number of visits, so they do not need so many server clusters.
For another example, screenshots of user comments may require a large amount of data storage. However, in the same way, personalized recommendations for users may require large-scale intensive computation.
In addition to the above, there are some subsidiary problems caused by the problems caused by the huge system:
4.4. The chain reaction problem of failure
Monolithic systems Technically, the various modules are coupled together. In actual operation, it is very likely that a fault will cause the entire system to crash.
For example, a XX function that is not commonly used has a memory leak, causing the entire system to be unavailable.
4.5. The technical locking problem of the system
Frankly, you have to admit that in programming, no language is perfect, and no database is perfect.
For example, Java is not as convenient and efficient as Python for scientific computing. For example, when we need to store very complex object relationships, MySQL and Oracle are not as good as any kind of graph database.
So, the more complex the system, the higher the probability that different technologies will be required . However, due to the complexity of the system, the risk of introducing new technologies is greater. Therefore, the use of new technologies is very difficult.
At the same time, after the system is huge, if some components or even the language SDK itself needs to be upgraded, it is a cumbersome and risky thing, so it is also very difficult to upgrade the technical version.
To sum up, for traditional monolithic applications, the technical problems caused by the huge system and the conflicting requirements caused by business development... can not be solved by the architectural idea of the monolithic system alone.
So why can't SOA solve these problems?
5. Problems with SOA
Let's first take a look at the structure of SOA
You can see that there is an ESB (Enterprise Service Bus) in the SOA architecture. This ESB is dedicated to the interaction between services and services for SOA, and is an essential technical infrastructure for SOA.
Just because SOA has the idea of service bus, it is destined that the service segmented by SOA cannot be too fine, because the more services appear, the service bus will eventually become a bottleneck of the overall system.
SOA's service segmentation scale itself is limited, and this limitation will bring the following problems:
-
Not segmented enough - We said that our main source of problems is that the system is too large and piled up. If our segmentation is not fine enough, then the possible result will be that a large system is divided into a few large systems. In the end, the problem is not solved. It may also be because the system has become different. distributed services, and introduced the problems brought by the new distributed system itself.
-
ESB itself may become a huge system monster - ESB, as the infrastructure of SOA, itself is already complex enough, it is likely that due to the development of business, it has become a terrifying system monster itself. Thus, 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 the way of thinking and architecture implementation of SOA is not enough to solve the problems caused by the huge monolithic system.
6. WHY SERVICES
Back to the topic of our microservices. We know the root causes of the problems, and we need to address them.
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 overcome.
No matter how big a system is, if we disassemble it small enough, we can split a large complex system into many small systems, and then let the small systems that are decomposed can re-aggregate them by providing services to the outside world. As a result, it becomes a large and complete system, which is equivalent to the original complex large system. And this is the most simple idea of microservices.
Therefore, there are two core ideas of microservices:
- Split the system into different parts
- the parts are small enough
Microservices do this with several benefits:
-
No matter how complicated the system is, as long as I can dismantle and know how to dismantle it, I can simplify the problem, so I don't have to worry about the system becoming complicated.
-
As long as the split services are small enough, no matter in terms of development, deployment, operation and maintenance, you can get countless benefits that were previously unavailable due to the huge system: modifying the code may become easier, and testing and running also become easier... …
-
The split services can develop independently and will not restrict each other. It turned out that when the system was a single system, due to the technical coupling between modules, it was impossible to freely choose the technology most suitable for the current functional module, nor to arrange the server flexibly according to the load of the current functional module.
-
Faults are 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, thus preventing an unimportant functional failure from causing the entire system to crash. We only need to make the core functions robust enough, and even if there are problems with non-core functions, it will not cause too much loss.
Therefore, a huge system, due to its bloat and complexity, may have to split itself. And these splits, according to some guiding principles, are small enough and simple enough to be disassembled, then the benefits brought by the dismantling are considerable.
7. Why do you need to dismantle the library?
The service has been dismantled and has received so much benefit.
"But why does the database have to be dismantled?" - This is actually the most confusing question for many students who use microservices.
Database splitting or not splitting is essentially a problem of data sharing. The concept of a service and a library itself is actually to avoid data sharing to the greatest extent possible.
Data sharing brings the following problems:
7.1. Technical implementations may still be coupled
Because the database is not split, it is very likely that a service module that should be independent must depend on another service module, which conflicts with our original intention of splitting services.
For example, order services and personalized recommendation services are likely to require access to order-related data. At this time, if the database is not dismantled, it is very likely that the modification of the order table structure due to the business requirements of the order will force the personalized recommendation service to be modified accordingly.
7.2. Overexposure of underlying data
Or the example of the above order service and personalized recommendation service. Personalized recommendation may only require some things such as user id, order category, etc., but since the database is shared, it is likely to open all the data of the order table, and these A lot of data is considered sensitive data and should be hidden, but now it is exposed.
7.3. Unnecessary data access contention
Because it is the same database, this will inevitably lead to competing access to shared data, and these competing accesses will greatly affect the flexible deployment of business modules. For example, the order module may be affected by the amount of concurrent data that it can carry due to some periodic batch queries of personalized recommendations.
Therefore, it can be seen that the sub-library must be considered into the entire architecture of the microservice.
8. Leave a tail at the end
Each service corresponds to a database, which is the core and most basic mode of microservices. It embodies the core idea of microservices:
Splitting and Decoupling
Generally speaking, most of the time, microservices will try to use a model of one service and one database.
Here we only talk about why we should use one service and one database, and how to divide services and databases, and whether they still have some practical compromises, which will be carefully analyzed in the next article.
Hello, I am Siyuanwai, the technical director of a listed company, and I manage a technical team of more than 100 people.
I went from a non-computer graduate to a programmer, working hard and growing all the way.
I will write my own growth story into articles, boring technical articles into stories.
Welcome to my public number: Four Apes