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

The main content of this article is "how to implement the micro-service model". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to implement the micro-service model"!

First, microservices may be a political issue.

When I first came into contact with microservices, I really had to.

The company had a large-scale system, which was responsible for the main profitable business of the company at that time, which was very important. However, because it is important, it has become the key service object of the product and business team. These people want to spend the business of this system every day, and constantly put forward all kinds of requirements to the technical team.

Not to mention the requirements, but also requires that the technology can be iterated quickly. Once they can't get their needs online in time, product managers complain at various meetings that the technical team is affecting speed and risks letting competitors catch up.

It's hard for the technical team to say, because the system is so huge, it's really difficult to change such a big system. As for the reason, I also said in the last article, I will not repeat it.

For these reasons, we decided to adopt micro-services.

When do I use microservices? When your delivery time is not enough for the product team and the operations team, consider it. In addition, when I worked on other new projects later, the leaders thought that the system was too simple and did not have their own technical features. As a last resort, I took out the micro-service again, and after the leader saw it, his eyes lit up and said it was good.

Therefore, in my experience, sometimes micro-service is essentially a political issue, not a technical one.

Generally speaking, for the landing of micro-services, not particularly large-scale projects, micro-services bring little benefits, but a lot of work.

No matter what the reason, I come into contact with more and more micro-services. In order to make good use of micro-services, I really delve into the architecture of micro-services and sum up some of my experience in the practice of micro-service decomposition.

First of all, if you expect the business to grow rapidly, don't hesitate to consider the split of micro-services in advance.

Second, if you find that you need a lot of heterogeneous technology stacks when designing the architecture, you should also consider micro-services.

Finally, if the company's technical infrastructure is very complete and the corresponding business is designed to be very complex in the first place, don't hesitate to start with micro-services.

Second, migrating to microservices can be rough or gentle.

Looking back, I went on to talk about my first microservice at that time.

As the migration of micro-services is not achieved overnight, but I urgently need the advantages of simple deployment and rapid development of some micro-services. So, as a last resort, I came up with a compromise.

I analyzed some business requirements that need to be implemented, and found that these requirements can be divided into the following two categories:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Some of the requirements themselves are a set of independent marginal businesses.

Some requirements are concentrated on the edge of the core business.

When I thought about it later, I thought it was taken for granted. The business is the same as our technology, if we change the logic of the core business, in case something goes wrong, they will bear great responsibility. But they have to show their own value, and the safest thing is to tamper with the core business.

Knowing this, it will be easy.

For the first type of independent business requirements, I directly designed a set of independent services, which can be remotely interconnected with the existing old systems through the network. In this way, the newly built service is small and easy to maintain. The old system also becomes the service of the new service. In this way, some of the requirements can be iterated quickly.

For the second type of requirements, the requirements at the core edge of the original system, I do so.

First of all, I won the support of the leadership and gave priority to the divestiture of the business modules that were often asked for. In this way, some business modules that do not change frequently are still in the old system. In fact, at these times, the system is not so large, and it can also meet the needs of business changes occasionally put forward by the business.

Then, in the follow-up time, I will slowly take the time to spin off some of the remaining business modules. However, the priority is very low.

In this way, slowly peeling off the cocoon, finally, I found that we have not moved the core business, a set of micro-service system has been built.

Some people may be curious that if you divest yourself like this, there are both old systems and new systems. Will the use of users outside be affected?

Actually, there's a little trick here. It is that I set up an agent before dismantling the micro service. This agent specializes in routing requests from outside users. Each time the service is launched, a micro-adjustment will be made to this set of agents. In this way, users will not be aware of the state behind the coexistence of new and old systems.

However, at this point, I would also like to say that this method is really rather rough, and there is really no way to choose this method.

Later, when I started microservices again, I learned a lot of lessons. The general direction still needs to give priority to the division of clear business modules, and then work out micro-services according to the division of business modules.

Generally speaking, the design of micro-service architecture in the later stage needs to be divided into two periods. In these two periods, I adopted a different approach. Let me talk about it separately.

III. Traditional business division of indigenous steelmaking

After being forced to do microservices for the first time, I started my own research on the architecture of microservices. I know a lot of technical details, and how to divide the business, I admit that I was a little negligent at that time. So, later, when I had a new project, I used the traditional business division method to do micro-services.

The steps are as follows:

Step 1: divide functional modules

In fact, it is good to have a clear division of functional modules, if it is a system from scratch, the business is not yet complex, so it is easy to divide the modules.

If it is an existing large project, you have to look at the source code of the system and figure out the overall business module according to the source code and business documents.

Step 2: the method of combing functional modules

It is not enough to figure out the business module, you also need to make separate services, so you must also determine the relationship between the services. At this time, if it is easy to do from scratch, according to the situation of business division, directly create the corresponding method.

If you split an existing project, it won't be easy. It is necessary to carefully comb the source code, and then clean up the method calls between each module one by one according to the classes and methods of the source code. It's very troublesome.

Step 3: classify the methods

All the methods sorted out are classified at once and divided into two categories: the methods of the functional modules directly to the external users, and the methods that need to be called within the functional modules.

Step 4: module mapping service, method mapping API

When the methods are sorted out and the classification is finished, it is time to map the functional modules to services, which is essential. The mapping of functional modules to services is often very rough at the beginning, that is, a functional module and services are mapped one-to-one.

However, in my experience, such a simple mapping is almost impossible. There are always various landing problems that force you to adjust.

Well, we made the assumption of one-to-one mapping between the business module and the service, and we combed through the method calls of the business module. Then do an one-to-one mapping between these method calls and the API method of the service. Of course, this method is also very rough, and there are almost always problems that need to be adjusted.

Step 5: make adjustments according to the actual situation.

Finally, we began to fine-tune the mapping between business modules and services based on our above assumptions, mainly for the following reasons:

1. Too much network interaction after split leads to performance degradation

When we split the service, the frequent method calls between some business modules were mapped to the services, which became frequent network interactions.

We certainly can't allow it to be called so frequently. There are two ways to deal with this situation: 1. Change the interaction between services to batch processing; 2. Just don't dismantle the service at all.

It's okay to change the service to batch processing. Once you decide not to dismantle it, it will affect the previously designed mapping relationship.

two。 Blocking that may be caused by synchronous calls

There are also times when it doesn't hurt to call synchronization locally in the past. Because everyone is in the same process, dealing with events can be ignored.

However, now that the family is separated, it has become a network call between services, and that has come. Network synchronous calls must consider fault tolerance and blocking, so synchronous calls have to be dealt with in two aspects: 1. Set timeout; 2. Deal with it asynchronously.

If some synchronous methods become asynchronous, the mapping between the API of the service and the previous method may need to be adjusted.

For example, a method has to correspond to two asynchronous API: one is to access and the other is to get a response.

3. The original data consistency may have to be reconsidered

After dividing services, the worst thing to do is data consistency, which is often unavoidable. Therefore, there will be a set of patterns in the micro-service system to solve this problem. Let's put it in a future article.

4. It turns out that some core business classes may be closely related to most businesses.

A set of complex business system, there must be some core business. In a code implementation, it is often a business class with a lot of fields.

For example, the order in the e-commerce system, this is a very core business category. It will be used in many businesses. For this category, they have a technical term called God class.

The God class itself is linked to too much business, and when you divide the service, you realize that I am almost done with the split step, and suddenly I can't even make a friend because of a God class.

There are too many fields of God class, which are needed by many businesses.

So, it really prevents a lot of businesses from being split up. At this point, I haven't carefully grasped the essence of domain-driven design, so I can't help it. I can only take these God classes out and turn them into a micro-service.

But this is really ugly.

First of all, this is purely a local law micro-service, which has no business at all.

Second, since there is no business, there will be no direction and no restrictions. At that time, anyone who wants to add the API to access the data will add it at will.

Finally, the micro-services corresponding to these God classes will be accessed by many micro-service modules, and it is under great pressure to build some clusters for this, and the loss outweighs the gain.

IV. Domain-driven tools for solving difficult problems with a different way of thinking

In fact, along the way, I really did not encounter too many problems using the traditional business division. It is the God class that hits me badly, and I always try to find a way to solve it.

When I look at domain-driven design, I understand that this thing is just a different way of thinking. There is nothing special about domain-driven design, but

It introduces the concept of a subdomain and a bounded context.

These two concepts are the two most helpful to me in breaking up microservices.

In fact, the sub-domain itself is the traditional technology before, that is, to split the business module. However, it also introduces the idea that technical terms with the same name between different subdomains may not be the same thing.

And this is how I solve the need for God class splitting. How did you solve it? It is realized with the concept of "boundary context".

Subdomains and bounded contexts sound fantastic, but they are actually the services corresponding to traditional business modules and business modules. It's just that the bounding context makes it clear that the service contains the code for the implementation, which they collectively refer to as the bounded context.

In the idea of domain-driven design, the terminology of the same name may actually be different between each subdomain. This corresponds to the implementation, which splits the original God class into different classes in different subdomains, and the classes in each subdomain contain some fields from the previous God class. such as,

The order category in the original e-commerce system may have included the user, the goods ordered, the user address, the amount, and so on.

But in the payment sub-domain, corresponding to the payment limit context, there is also an order class, which only requires two fields: user and amount.

In the logistics subdomain, corresponding to the logistics boundary context, there is also an order class, which may only need two fields: commodity and user address.

So, through this idea, the problem that God classes hinder the splitting of micro-services is solved.

However, there is still a problem in implementation. Because we are a system for users, the display information that users see may still correspond to all the field information contained in the original God class.

For example, e-commerce system, for users, order information contains a lot of other information: goods, amount (payment sub-domain), user address (logistics sub-domain).

At this time, in fact, micro-services have their own API gateway, so it is necessary to aggregate the data of micro-services into orders seen by users through the micro-service gateway.

At the same time, through the API gateway, the order seen by the user will be converted into the order information needed between the various micro-services, which will continue to flow. And this is another model, which will be discussed in detail in future articles.

At this point, I believe you have a deeper understanding of "how to implement the micro-service model". 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.