Shulou(Shulou.com)06/03 Report--

This article focuses on "what is the architecture model of microservices". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the architecture model of micro-services"?

1. The most basic mode of micro-service

This article starts with the first most basic model, which I estimate will take three articles to explain. This is the first article. I plan to write practice in the middle and questions in the second.

I hope you can learn easily.

The most basic model of micro-service is:

One service, one database.

The image above is the simplest micro-service model.

The pattern of serving one database at a time is the most basic and core pattern in the microservice architecture. It looks simple, but this model contains the most basic idea of micro-services.

To figure out the pattern of one service and one database, we first need to ask why we want to do microservices.

two。 Problems with traditional systems

When talking about microservices, the concept corresponding to microservices is called monolithic system (Monolithic application). To put it simply, micro-services are derived to solve the problems of single systems. The structure of the single system is shown below:

So what's wrong with this monomer structure, so that now we have to close the mouth of micro-services?

3. The single system is too big.

One of the most important reasons is that the application system is too large. Because the application system is too large, if it is only a single system, it will give rise to a variety of problems, reflected in the following three aspects:

3.1. The business of the system is complex and there are many modules.

With the development of the system over time, there are more and more business requirements. In order to meet these requirements, there are more and more modules in the whole system. With more and more system modules, there are fewer and 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 huge.

The amount of code will also increase with the increase of the system, the huge amount of code affects the whole development process, which will cause the whole development cost to become very high.

First of all, there is a large amount of code and complex dependencies, so it takes a lot of effort to configure the development environment for new developers.

Second, there is a large amount of code, which requires a lot of memory to load the code and the corresponding dependencies, so the developer's IDE runs very slowly, making it troublesome to edit the code.

Thirdly, the amount of code is large, and if you want to compile and package the whole code, you need a lot of memory, so it will also lead to the completion of functional development, the construction of the system will be very slow, resulting in a very long time to build.

In addition, the amount of code is so large that almost no one can have a deeper understanding of the overall code, even if one of the functions to be changed will be too complex for developers to understand. This lack of in-depth understanding will prevent developers from using the best way to do functional development, resulting in hidden bug.

3.3. The technical team has become very large.

As there are more and more functional modules, more and more developers are needed to develop and maintain the system. However, these developers are all faced with the same set of code base, although we can do branches, we all do their own. But once you need to combine the code and release it online, it's a nightmare.

All kinds of code conflicts and code loss can occur when you go online.

Not only that, because of concerns about code loss and conflicts, it is necessary to conduct a sufficient number of tests before going online, and these tests require a huge time cost.

However, now that we are talking about agile development, it is likely that the follow-up business requirements will follow before we go online, which is simply fatal.

4. Personalization of business requirements

Another important reason for microservice is the personalization and granulation of business requirements.

With the development of business, whether due to market competition or the needs of its own development, it is necessary to deeply mine its own business model and improve users' experience of using the system. Based on this kind of things, it is necessary to do a thorough study of each functional module of the system.

This raises several new questions:

4.1. System function modules may become more and more complex.

The functional modules of the system may be constantly broken into more fragmented modules, so that they may be broken into particles. As the function becomes more fragmented and granular, it will make it easier for product managers to put forward some very detailed business requirements.

These very meticulous requirements are likely to result in frequent functional changes and online requirements. And these endless rapid requirements relative to the overall huge system online and developers on the run formed the most fierce conflict.

4.2. The functional modules have conflicts with the technical requirements of the system.

For example, different functional modules, order module and payment module. The order module hopes that the system can handle a large number of orders as much as possible at the same time, and even have a certain degree of fault tolerance.

But the payment module is different, the payment module wants the system to be as stable as possible, and must have a very high demand for accuracy, almost no room for fault tolerance.

Similarly, in the same payment module (depending on the system module), there may be both local account transfer and tripartite payment, and local account transfer may require immediate and high response time. However, for third-party payment, there can be a certain degree of response time tolerance.

If the system itself is a single system, it is bound to require developers to make certain compromises to the whole system and make certain tradeoffs to the conflicting technical requirements. This trade-off is likely to affect the experience of the system as a whole.

4.3. There is a conflict between the system module's requirements for the server.

Due to the deep cultivation of the function, there are bound to 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 visits. However, in the same functional module, there may be some enterprise group purchase requirements, they do not have so much traffic, they do not need so many server clusters.

For example, screenshots of user comments may require a lot of data storage. However, similarly, personalized recommendations for users may require large-scale intensive computing.

In addition to the above, there are some ancillary problems caused by the problems caused by the large system:

4.4. Chain reaction problem of failure

Technically, each module of the single system is coupled together. In the actual operation, it is likely that a failure will lead to the collapse of the whole system.

For example, a memory leak occurred in an uncommonly used XX feature, causing the entire system to become completely unavailable.

4.5. The problem of technical locking of the system

Frankly, 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 to do scientific computing. For example, when we need to store very complex object relationships, MySQL and Oracle are not as good as any kind of graphical database.

Therefore, the more complex the system, the higher the probability that different technologies are needed. However, because of the complexity of the system, the greater the risk of introducing new technologies. 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, need to be upgraded, it is also a tedious 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 demand conflicts caused by business development. All of them can not be solved by the architecture of single system alone.

So why can't SOA solve these problems?

5. The problem of SOA

Let's first look at the structure of SOA.

You can see that there is an ESB (Enterprise Service bus) in the SOA architecture. This ESB is the interaction between services and services dedicated to SOA, and is a necessary technical infrastructure for SOA.

Because SOA has the idea of service bus, it is doomed that the service split by SOA can not be too detailed, because the more services appear, the service bus will eventually become the bottleneck of the whole system.

The scale of SOA's service sharding is itself limited, which leads to the following problems:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The slicing is not detailed enough-as we said, the root of our main problem is that the system is too large and stacked together. If we don't split it carefully enough, the possible result will be that it will be split from a very large system into a few also very large systems, without solving the problem in the end, or because the system has become a different distributed service, and the problems caused by the new distributed system itself have been introduced.

ESB itself may become a huge system monster-ESB, as the infrastructure of SOA, is complex enough, probably because of the development of the business, it has also become a scary system monster. As a result, developers not only need to maintain the original system, but also need to worry about how to maintain and modify 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 single system.

6. Why do you need services?

Back to the topic of our microservices. Now that we know the root of the problems, we need to start to solve them.

First of all, since the problem is caused by the complexity of the system, we can refer to the common solution idea in the software: divide and conquer.

No matter how large a system is, if we split it small enough, we can split a complex large system into many small systems, and then let the decomposed small system through the means of providing services to the outside world. reassemble them into a large and complete system, which, as a result, is equivalent to the original complex 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.

Microservices do this with several benefits:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

No matter how many complex systems, as long as I can disassemble and disassemble, I can simplify the problem, so that I don't have to worry about the system becoming complex.

As long as the split service is small enough, you can get countless benefits that could not be obtained because of the size of the system in terms of development, deployment, and operation and maintenance: it may be easier to modify the code, and it may be easier to test and run.

The split 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 impossible to freely choose the technology that is most suitable for the current functional modules. nor can we flexibly arrange the server according to the load of the current functional module.

The fault is isolated naturally. We cut the system into services, each with its own process or server, so that the failure is isolated from the physical level, thus avoiding an unimportant functional failure that leads to the collapse of the whole system. We just need to make the core functions robust enough, even if there is a problem with the non-core functions, it will not cause much loss.

Therefore, a huge system, because of its own bloated and complex, may have to split itself. And these splits, according to some guiding principles, the disassembly is small enough and simple enough, 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 gained so much benefit.

"but why does the database have to be dismantled?"-this is actually the most puzzling question for many students who use micro-services.

Whether the database is split or not is essentially a matter of data sharing. The concept of a service and a library itself is to avoid data sharing as much as possible.

Data sharing brings the following problems:

7.1. Technical implementation is still possible to couple.

Because there is no split database, it is possible that a service module that should be independent must rely on another service module, which conflicts with our original intention to split the service.

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 likely that the personalized recommendation service will also be modified due to the modification of the order table structure caused by the order business requirements.

7.2. Excessive exposure of underlying data

Or the above example of order service and personalized recommendation service, personalized recommendation is likely to just need some user id, order categories and so on, but because the database is shared, it is likely that all the data in the order table is open, and many of these data are sensitive data that should be hidden, but now they have been exposed.

7.3. Unnecessary data access competition

Because it is the same database, it is bound to result in competitive access to shared data, which will greatly affect the flexible deployment of business modules. For example, the order module is likely to be affected by the amount of concurrent data it can carry due to some regular batch queries of personalized recommendation.

So, as you can see, sub-libraries have to be taken into account in the entire architecture of microservices.

At this point, I believe you have a deeper understanding of "what is the architecture model of micro-services". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.