Migrating from Monolithic Architecture to Microservices, 8 Key Thoughts, Practices, and Lessons

With the continued popularity of microservice architecture, there are more and more discussions on microservices and monolithic architecture on the Internet. Last year, the community paid more attention to the difference between the two and the advantages and disadvantages of the two. This year, more and more people began to pay attention to how to migrate from a monolithic architecture to microservices. There is no doubt that the idea of ​​microservices is sweeping the entire developer community, and companies like Netflix and Uber are very successful use cases.
However, it should be noted that implementing microservices also requires additional costs. Martin once said that unless you are facing a monolithic application that is too complex to manage, you should never consider using microservices. Most software systems should be built as self-contained monolithic programs. Make sure to focus on the modularity of the monolith itself, rather than trying to separate them into separate services.
Liu Xiang, technical manager of Puyuan Software Product Department, has a lot of practice and thinking on microservice architecture. InfoQ reporters interviewed him on 8 key issues of migrating monolithic applications to microservices, covering the traditional monolithic architecture. Challenges, foreshadowing of implementing microservice architecture, transformation principles, databases, middleware, distributed transactions, risk aversion, etc.
InfoQ: From your observations so far, why are companies migrating from a monolithic to a microservices architecture? What is the biggest problem they have?

Liu Xiang: Most of the enterprises I serve are traditional enterprises. There are many projects with 1 million lines of code. The huge and complex projects make development, testing, maintenance, and operation and maintenance extremely complicated. In terms of elasticity, scalability, and maintainability Also difficult. In addition, the problems encountered by the traditional monolithic architecture are as follows:

1. Difficulty in taking over the team.

Eight years ago, I took over a project with a level of 1 million lines. That experience was a nightmare: it took 3 months to Time to read through the code; every time you modify the code, you will be terrified, and modifying a bug is very likely to bring all kinds of hidden defects.

2. Bloated deployment Every change of function or defect of a

single application leads to redeployment of the entire application. This deployment method has a large impact and high risk, which determines the low deployment frequency, resulting in a large number of functions or defects between the two releases. Making changes increases the probability of errors.

3. Limited flexibility and scalability A

single application, as a strongly coupled whole, cannot scale according to business functions, and can only be extended as a whole. This results in a waste of resources, and at the same time, it is impossible to perform targeted scaling according to the characteristics of different business modules, such as computing-intensive services and IO-intensive services.

4. Obstructing technological innovation The desire of the

team for new technology is self-evident, and the team morale will be reduced due to the continuous focus on the technology stack applied by Jushi; the organization under the monolithic structure usually has a very single technology selection, The technical ability of the team is relatively weak, and the attractiveness of the team is average.

In addition, multiple dimensions such as service level, security requirements, and business supervision need to implement different governance for different services, and it is inevitable to migrate to a microservice architecture.
InfoQ: Microservices have their inherent advantages, but also require higher infrastructure and teams of enterprises. What do you think needs to be done before an enterprise is ready to migrate to a microservices architecture?

Liu Xiang: Before an enterprise migrates to a microservices architecture, the No. 0 principle is to fully understand the business. When a large number of enterprises have a limited number of people who understand the business system due to historical reasons, they try to switch to the microservices architecture, even if they adopt the best technology. , tools, architecture, teams, and ultimately it all falls down (causing endless splits and changes).

Under the premise of fully understanding the business, I believe that the migration to microservices needs to be prepared in the following three dimensions:

1. Repaying technical debts

Automated testing, continuous integration and automated deployment are technologies that must be compensated before large-scale migration to microservice architecture in debt. Under the microservice architecture, the team manages a large number of services, and the complexity and testing difficulty increase exponentially. The use of automated testing can help the team to verify the application quickly and effectively; continuous integration and automated deployment ensure that the team can modify the code faster and easier. With continuous integration and automated deployment, the transition to a microservices architecture can be extremely painful.

2. New architectural design principles

With a microservice architecture, application delivery is highly complex. The architectural design principles need to focus on functions and performance under the original monolithic architecture to MVP (minimum usable product), failure-oriented design (embracing failure, not preventing failure), lenient entry and strict exit (lend in and strict with requests) out, the external response should be strictly standardized), rather spend one point on the machine, not one second on the labor (automatic and self-help, complex and repetitive things are handed over to the platform tools, allowing programmers to do more valuable things), everything The design principles such as resources are changed to form a design style with progressive optimization of the architecture.

3. Team Change

The book "Exploring the Duality Between Product and Organizational Architectures" gives a very interesting point of view. The degree of coupling of the organization is proportional to the modularity of the system. That is, the higher the degree of organizational coupling, the higher the degree of product coupling; the lower the degree of organizational coupling, the lower the degree of product coupling. The microservice architecture essentially emphasizes the loosely coupled architecture, so before the microservice architecture migration, it is necessary for us to fine-tune the organization (do not change, it will have a great impact on the organization) to ensure that an independent, small team delivers a microservice, At the same time, the small team is the Owner of the microservice (in addition to being responsible for development, it is also responsible for testing and operation and maintenance). This will greatly provide a sense of responsibility for the team and accelerate the autonomy and delivery capabilities of microservices.
InfoQ: What rules do you think you can follow during the entire architectural transformation process?

Liu Xiang: The industry has summarized a lot of principles for microservice architecture transformation, including: splitting based on business, adopting automation culture, decentralization, independent deployment of services, complete autonomy of services, isolation failure, progressive splitting, avoiding large-scale Principles such as transforming the original code, these principles are believed to be relatively clear to those who pay attention to the microservice architecture. Combined with our specific practice, we provide some experience summaries during the actual microservice transformation:

1. Separating the database first, then the service Whether the

data model can be completely separated determines whether the boundary functions of the microservice are completely delineated. We have seen too many cases of multiple refactorings and rework caused by direct separation from services;

2. Adopt the "Strangler Mode"

For legacy systems that cannot be modified, it is recommended to adopt the strangler mode: adding new functions outside the legacy system to form microservices instead of directly modifying the original system and gradually replacing the old system;

3. Establish a unified log specification

Standardize the log system of the entire system rather than microservices. The use of a standard log format is very convenient for subsequent log aggregation and retrieval, and it is convenient to analyze, monitor, and view the system from an overall perspective;

4. Choose a mature framework

to do two uncontrollable things at the same time (micro Service transformation, the impact of new technologies) are destined to have a low probability of project success, do not reinvent the wheel yourself, try to choose mature open source technology frameworks on the market for support, such as Spring Boot, Spring Cloud, Netflix, WildFly Swarm, Docker, Kubernetes and other frameworks; of

course, there are many detailed specifications, such as the principle of separation of front and back ends, the use of the principle of globally unique serial number to achieve full-link transaction tracking, how to perform service document management and service test Mock, etc.
InfoQ: Are there any adjustments to the database that should be made?

Liu Xiang: This topic is very meaningful. In the transformation of microservices, the first thing you need to do is to split the database model. After the boundaries of the data model are clearly defined, it is easy to demarcate the boundaries of services. The strongly recommended principle in our practice is that one microservice corresponds to one library. Of course, as the scale of microservices grows, read-write separation can be done in a targeted manner; if the data in a single table is huge, it can be solved by sub-tables.
InfoQ: How to solve distributed transaction consistency?

Liu Xiang: Under the microservice architecture, complete transactions run across multiple systems, and transaction consistency is a very challenging topic. According to CAP theory, a choice must be made between Availability (Avaliablitity) and Consistency (Consistency). We believe that availability should be selected under the microservice architecture, and then the eventual consistency of data should be guaranteed. In our practice, we have summarized three modes: reliable event mode, business compensation mode, and TCC mode.

Reliable event mode: The reliable event mode belongs to the event-driven architecture. When something important happens, such as updating a business entity, the microservice will publish an event to the message broker, and the message broker will push the event to the microservice that subscribes to the event. When the event's microservice accepts this event, it can complete its own business and may trigger more event publications.

Business compensation mode: The compensation mode uses an additional coordination service to coordinate each work service that needs to ensure consistency. The coordination service calls each work service in sequence, and if a work service fails to call, it cancels all previously completed work services. Require work services that need to guarantee consistency to provide compensation operations.

TCC mode: A complete TCC business consists of a main business service and several slave business services. The main business service initiates and completes the entire business activity. The TCC mode requires the slave service to provide three interfaces Try (responsible for resource checking), Confirm (true Execute the business), Cancel (release the resources reserved in the Try phase).

For a detailed introduction of the three modes, please refer to my colleague Tian Xiangyang's micro-classroom article:

Data Consistency Guarantee under Microservice Architecture (1): http://dwz.cn/3TVFHs

Data Consistency Guarantee under Microservice Architecture (2): http://dwz.cn/3TVFHs ://dwz.cn/3TVHBW

Data Consistency Guarantee under Microservice Architecture (3): http://dwz.cn/3TVJaB
InfoQ: Does the middleware need to be adjusted or re-planned for many new middleware?

Liu Xiang: For the existing middleware, use the popular word "dual mode" by Gartner. For example, middleware such as MySQL and Redis are suitable to appear independently as microservices; for large Oracle, DB2 databases or products such as Queue, they are not suitable as independent products. Microservices emerge and can work in an integrated fashion.

The microservice architecture needs to provide integration with new middleware platforms, such as IaaS platforms, PaaS platforms, etc. Of course, within the microservice framework, there are a large number of new middleware products, such as etcd, motan, resteasy, ELK, etc.

For the use of middleware, we have always maintained a principle: put business logic in the service, and try to keep the middleware as simple as possible.
InfoQ: During the entire transformation process, how do you think risks should be avoided to ensure a smooth transition?

Liu Xiang: Microservice architecture migration is full of challenges both in business and technology. From the perspective of avoiding risks, I would like to give you two suggestions:

1. Pay attention to the construction of the operation platform.

Before implementing the microservice transformation, it is recommended to build an operation support platform. The platform provides at least the compilation, integration, packaging, deployment and configuration of microservices. If you have the ability, it is recommended to use the PaaS platform to solve the whole life cycle management of microservices from development to operation, and provide heterogeneous environment management, container resource isolation and interoperability, service scaling drift, service upgrade and rollback, service fuse and Downgrade, service registration and discovery. The platform helps developers solve more technical problems, and developers focus on the splitting of business functions.

2. Start with the pilot and gradually

promote the business application classification of the enterprise, starting with the peripheral application pilot; after the experience is rich, the current migration and large-scale transformation of the core application will be carried out.
InfoQ: Based on your practical experience, share what you think are the key points in the process of migrating from a monolithic architecture to a microservices architecture?

Liu Xiang: Combining our own microservice experience, we can summarize three key points in the migration process:

1. For the business system, reorganize the conceptual model + data model, and segment loosely coupled and highly cohesive microservices to ensure The project team is doing the right thing;

2. Formulate microservice development specifications (including technical architecture, Spring Boot+Motan+etcd+RESTEasy+Elasticsearch+Docker+Kubernetes is our technical architecture selection), and ensure that the project team does things correctly according to the unified development specification (technical architecture);

3. After the microservice is split, the biggest challenges come from operation and maintenance, monitoring, and fault handling. If the team has no experience in microservice operation, it will not be able to locate and reply quickly after the fault, and it will be under greater business pressure. The microservice operation platform or management platform (see the first part of question 7 for specific functions) is extremely important to the team, and the supporting design needs to keep up with it in time to support the operation and management of microservices.