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

When it comes to micro-services, service split is an unavoidable topic, but micro-services can not be split, it requires a lot of prerequisites.

First of all, at the infrastructure level, there should be a continuous integration platform that makes the functional consistency of services in the process of split, which can not be achieved through human experience, but requires a large number of regression test sets, and continuous split, continuous evolution, continuous integration, so as to ensure that the system is always in a state of verifiable delivery, rather than a period of time. In the end, no one knows whether the feature will have bug in the end, so it will take another month to specifically modify bug.

Secondly, in the access layer, API and UI should be separated, and API is uniformly managed by the API gateway, so that no matter how the back end is split, it can ensure a unified entrance for the front end, and can achieve gray release, routing distribution, and traffic segmentation in the split process, so as to ensure the smooth split. Moreover, for the sake of high performance, authentication and authentication is not recommended for each call among the split micro-services, but a unified authentication and authentication is done at the API gateway. Once entering the gateway, the calls between services are trusted.

Third, for the database, need to be well designed, there should not be a large number of federated queries, but the database as a simple key-value query, complex federated queries through the application layer, or through Elasticsearch. If the coupling between database tables is very serious, in fact, the service can not be split out.

Fourth, we should do the stateless application, only the stateless application can be expanded horizontally, so that the split is meaningful.

So, after meeting the infrastructure premise of service split, which module should we dismantle first and which module should we dismantle later? Under what circumstances should a module be split?

Keep in mind that micro-service split is by no means a great leap forward movement, initiated by the top management, breaking up an application into pieces, which will eventually greatly increase the cost of operation and maintenance, but will not bring benefits.

After meeting the above basic conditions, we have to look at the business changes in order to find the best time to split.

First, there is a need for fast iteration.

Internet products are characterized by fast iteration, which can be decided in a year and a half, the first to dominate the world, the second to be acquired by the first, and the other dead. So rapid online, fast iteration, is the lifeline, and once success is worth 10 billion, so no matter how much operation and maintenance costs, the use of micro-service architecture is worth it.

This is why most of the people who use micro-service architecture are Internet companies, because the benefits are obvious for these enterprises. For many traditional applications, updated every half a year, the operation of the enterprise is relatively stable, the quality of the IT system has no critical impact on the business, in their eyes, the effect of micro-service transformation is not as good as the development of a few more shifts.

Second, a large number of conflicts occur frequently in the submission code.

First of all, the effect of micro services for rapid iteration is to develop independently. If it is a single application, hundreds of people develop a module, and if you use GIT for code management, you will often encounter code submission conflicts.

The same module, you also change, he also changed, hundreds of people simply can not communicate. So when you want to submit a code, you find that there is a conflict with someone else's submission, so because you are the post-submitter, you have the responsibility to merge the code. It is not easy to merge successfully. When you submit it again, you find that there is another conflict. Are you very annoyed? With the larger the team size, the greater the probability of conflict.

So should be divided into different modules, every ten people to maintain a module, that is, a project, first of all, the probability of code conflict is much smaller, and there is a conflict, a group roar, basically the problem is solved.

Each module provides an interface to the outside, and other dependent modules do not need to pay attention to the specific implementation details, but only need to ensure that the interface is correct.

Third, small functions must be accumulated to a larger version before they can be launched, and a general meeting at the director level will be held online.

The effect of microservices for fast iterations is first of all online independence. If there is no split of micro-services, it will be a very painful thing to launch every time. When you modify a small function in one corner, but you do not dare to go online immediately, because the other modules you rely on are only half developed, you have to wait for him, and when he is ready, you do not dare to go online immediately, because another dependent module is also half developed. when all the modules are coupled together and depend on each other, no one can go online independently, but need the director to coordinate each team, hold a meeting, and agree on a time point. No matter big or small function, life or death needs this sky line.

When this mode leads to the launch, the list of requirements for a single launch is very long, so the risk is relatively large. Errors in small functions may lead to abnormal launch of major functions. Such a long function requires a little bit of check, so that it takes a long time to go online and has a wide range of influence. Therefore, this kind of iteration speed is not fast, at most once a month is good.

After the service is split, different modules can be online independently when the interface is stable. In this way, the number of launches increases, the list of requirements for a single launch becomes smaller, you can roll back at any time, the risk becomes smaller, the time becomes shorter, and the impact surface becomes smaller, thus speeding up the iteration speed.

For the part of the interface to be upgraded, ensure the grayscale, add the interface first, rather than change the original interface. When the call monitored in the registry, it is found that the interface is no longer in use, and then delete it.

Microservices also solve the problem of high concurrency. The characteristic of a product of the Internet is to accumulate a large number of users in a short period of time, which is even more important than revenue and profit. If there is no large user base, financing will be a problem.

Therefore, for systems with small concurrency, the driving force of micro-service is poor. If only a small number of users are online, multithreading can solve the problem. At most, it can be stateless, with a load balance deployed in front and multiple copies of a single application.

Fourth, the scale-out process is complex, and the main business and secondary business are coupled.

After the single application is stateless, although it can carry a certain amount of concurrency through the deployment of multiple copies, the resources are very wasted. Because some businesses need to be expanded, such as issuing orders and payments, while others do not need to be expanded, such as registration. If the capacity is expanded together, the resources consumed may be several times that after the split, and the cost may be several hundred million more. Moreover, due to the complex configuration, in the same project, it is often organized like this in the configuration file. This one belongs to this module and the next belongs to another module. When expanding, some marginal businesses also need to review the configuration in detail, otherwise they dare not expand the capacity rashly.

Fifth, the downgrade of fuse depends on if-else.

In high concurrency scenarios, we hope that if a request is not successful, it should not take up resources. It should fail as soon as possible and return as soon as possible. We also hope that when some corners of the business are abnormal, the main business processes will not be affected. This requires a circuit breaker strategy, that is, when A calls B, and B is always abnormal, in order not to affect B to A, you can circuit-break the call to B, that is, A does not call B, but returns temporary fallback data. When B is normal, release the circuit breaker and make a normal call.

Sometimes in order to ensure the core business process, the corner of the business process, such as comments, inventory number, etc., manually set to the degraded state, that is, the default is not called, all the resources are used to greatly promote the order and payment process.

If the core business process and the corner business process are in the same process, we need to use a large number of if-else statements to judge whether to circuit breaker or downgrade according to the issued configuration, which will make the configuration extremely complex and difficult to maintain.

If the core business and corner business are divided into two processes, the standard circuit breaker downgrade strategy can be used. Under certain circumstances, the call to another process can be abandoned and unified maintenance can be carried out.

In short, the process of micro-service splitting should be driven by pain points, and the business really encounters the problems of fast iteration and high concurrency. If it is not split, it will have an impact on the development of the business. Only at this time can the split of micro-services have definite benefits, and the increased operation and maintenance costs are worth it.

(the writer is Liu Chao, chief architect of NetEYun)

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.