There are many advantages of microservices. If anyone has not heard of microservice architecture, you can learn about it from here . This article mainly talks about whether it is worth the time to refactor the monolithic architecture into a microservice architecture?
Microservice architecture is an architectural style that focuses on software R&D efficiency, mainly including the realization of more functions per unit time, or the entire continuous delivery process of software from idea to online. In the current Internet environment, rapid business changes have also promoted the popularization of microservice architecture. This structure forces the team to react quickly and implement it quickly. It has been put into operation before the plan expires and has withstood market inspections and tests.
At present, most of the domestic companies are operating systems with a single architecture. It is undeniable that these systems have played an irreplaceable role in the company's development process, ensuring the normal operation of the company and creating a lot of value. However, with the gradual expansion of the system, more and more integrated functions, development efficiency becomes lower and lower, and it takes longer and longer for a function to go from idea to realization. More seriously, due to the entanglement of code modules, many aging architectures or obsolete functions have become obstacles to new functions.
As we all know, with the increase of functions in a single architecture, it is inevitable that the R&D efficiency will decrease: the R&D cycle becomes longer and the R&D resource usage increases. The resulting situation is: new employee training time increases, employees work overtime longer, employees ask for salary increases or change jobs. When this happens, it means that the monolithic architecture can no longer meet the needs of enterprise development. At this time, it is necessary to upgrade the architecture to improve R&D efficiency, such as the microservice architecture.
To illustrate the benefits of microservice architecture, you can use an analogy. We built a space station. To this end, we need to transport people, goods, and equipment to the space station. At this time, launch vehicles are a better choice. Although launch vehicles are expensive, they are launched every few months. Able to meet the demand. With the expansion of the space station, the interval between rocket launches has become shorter, the transportation cost is ridiculously high, and it is increasingly unable to meet the operational needs of the space station. At this time, you can try another way, for example, the space elevator. Of course, the cost of a space elevator is higher than the cost of a flight, but as long as it is completed, the future cost will be reduced a lot.
This metaphor also illustrates the good expectations brought by microservices, and it also illustrates a problem. The implementation of microservices architecture will bring huge investment. Therefore, we need to think about it before building the space elevator, we really need this kind of investment, otherwise it can be a waste.
to be or not to be
When deciding to upgrade from a monolithic architecture to a microservice architecture, first ask yourself the following questions:
- Whether the product or system has been tested by the market
- Do you need more than one team to guarantee product release
- Does the system have high requirements for reliability and scalability
Microservice architecture
What is a microservice architecture? Sam Newman believes it is: "A set of small and autonomous services that are modeled around the business domain and work together with each other."
The services in the microservice architecture are business modules extracted based on business capabilities, developed and deployed independently, but need to cooperate with each other to complete the entire business function. The service is not just a data storage component, it is a database. It's not just a logical function unit, it's a function. Only by including data + logic at the same time, is it a service in the true sense.
Service boundary
In the process of service disassembly, DDD (Domain Driven Design) can be used as a guideline for microservice architecture. Because microservices define services around business functions and define teams based on services, this is exactly the same as DDD's methodology of disassembling business domains into business sub-domains and defining defined contexts, so DDD, as a guideline for microservices, quickly defines various service components. Complete the migration from monolithic architecture to microservice architecture.
Alberto Brandolini proposed the method of identifying service context called "Event Storming". The first step is to identify events that occur in the business domain, that is, our focus is on behavior, not data structure. The advantage of this is that the different services in the system are loosely coupled, and a single service can be autonomous.
Once the service side is defined, the transaction boundary needs to be defined. In the past, our service was in a process with a database behind it, and the transaction could choose a strong consistency transaction, that is, ACID. When the services increase and cooperate with each other, the eventual consistency transaction can be used at this time, which is BASE. Unlike ACID, BASE is more flexible, as long as the data can be kept consistent in the end. This final time range, depending on different business scenarios, may be minutes, hours, days, or even weeks or months.
Ready to work
The vision of the microservice architecture is beautiful. It is a heavy weapon with many advantages and obvious disadvantages. With the increase of services, the difficulty of operation and maintenance increases, and the difficulty of error debugging increases. Therefore, automated construction, configuration, testing, and deployment are required, and tools such as log collection, indicator monitoring, and call chain monitoring are required, which means that DevOps practices are required. The three-step work method to realize DevOps explains the three steps to realize DevOps culture.
In addition to the above-mentioned foundation, it is also necessary to determine how services are integrated and how to call each other in the early stage. It is also necessary to determine the data system, including transaction consistency and data reliability methods. As services increase, many components such as configuration management and service discovery are also required. Refer to the infrastructure work of microservices for the specific basic components required .
These basic services and designs are best defined early in the morning, otherwise, more resources will be needed to improve the architecture later. If it is missing in the early stage and not made up in the later stage, the result will be the failure of the migration of the microservice architecture, and the final system is just a monolithic architecture covered in microservices.
Evolution or revolution?
After defining the service boundary, there is still a problem that needs to be solved: whether to gradually evolve and update the system, or to rebuild the entire system.
The second method is very tempting, and it is more in line with the thinking of most programmers. The system is not good, and it is rebuilt, called refactoring. But in most cases, this approach cannot be allowed, because the market changes rapidly and competition is fierce, and most companies will not stop their business and wait to rebuild a system that can work but has some shortcomings. Therefore, gradually extracting and updating the system is king, and most companies can also accept it. This method is also called strangulation mode.
Transformation
How to gradually transition to the microservice architecture? Let's show it step by step:
[External link image transfer failed. The origin site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-iMdUUCj7-1584889654137)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_0.png)]
The first step is to separate the user view layer from the service layer. The business logic is delegated to the service layer, and the query displayed on the page is supported to be directed to the database. At this stage, we do not modify the database itself.
In the second step, the user view layer is completely separated from the database, relying on the service layer to operate the database.
[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-Iiu0S778-1584889654138)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_2.png)]
The third step is to split the user view layer and the service layer into different services, and create an API layer in the service layer to communicate between the user view layer and the service layer.
The fourth step is to split the database, split different business data into different databases, and split the corresponding business service layer into different services. The user view layer communicates with API components of different business service layers through an API gateway. At this time, you need to pay attention, if the team does not have microservice development experience, you can first extract simple business domain services, because the business is simple and the implementation is simple, so you can practice and accumulate experience.
The last step is to split the user view layer.
[External link image transfer failed. The source site may have an anti-hotlink mechanism. It is recommended to save the image and upload it directly (img-BjwOquVB-1584889654139)(https://www.howardliu.cn/images/microservice/from_monolith_to_microservice_5.png)]
The advantage of the strangulation model is that we can adjust the plan at any time as the business changes, without causing the entire business evolution process to stop.
Success criteria
When we have completed the entire upgrade process, we need to check whether we have achieved the expected results. The purpose of introducing microservices is first to improve the development process, which can be measured by simple indicators:
- Development cycle: the duration from concept to launch
- Development efficiency: functions or user stories completed by teams or individuals within unit time
- System scalability
- Average repair time: the time required to find and troubleshoot
By comparing these characteristic values of the old architecture and the new architecture, the effect of the upgrade process can be evaluated. Of course, these indicators must be monitored during the upgrade process.
most important thing
As a siege lion, we are proud to be able to solve or improve the world around us, and we are obsessed with providing solutions. At the same time, we must also realize that every effort we put in must be rewarded. Refactoring and upgrading that cannot bring any rewards is a waste of time.
Personal homepage: https://www.howardliu.cn
personal blog post: from monolithic architecture to
microservice architecture CSDN homepage: http://blog.csdn.net/liuxinghao
CSDN blog post: from monolithic architecture to microservice architecture