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

Micro service is the most popular application architecture technology at present. Together with CCS and DevOps, it is called the three Musketeers of the cloud era. It can help us resolve the pressure of product iteration caused by the rapid development of business, so that we can freely choose the technology stack that is most suitable for the team, so that the system can carry the access of a large number of Internet users, so that we can more easily operate and maintain large-scale Internet systems. In recent years, with the efforts of manufacturers, communities and users, the theories and products related to micro-services are becoming more and more mature. Micro-service development and governance suites in different languages (such as Spring Cloud/Dubbo, etc.) make it very easy and fast for us to build micro-services from scratch, so can we enter the micro-service era in an all-round way?

It takes time for the evolution of micro services to mature, and it also takes time for us to master this new technology. In addition, there are a large number of monolithic applications running in the computer room, which need to be maintained and upgraded. It is impossible for us to put aside history and fight easily at any time. These monolithic applications are also responsible for the company's core business, all over again, shock restructuring is not desirable, the investment cycle is long, the risk is completely uncontrollable. We must learn the skills of changing tires while driving, promote the transformation of micro-services without affecting the existing network business, let the old system coruscate new vitality, and continue to support the development of the business in the next decade. This article will discuss with you the experience and methods related to the transformation of micro-services, so that you can embrace micro-services more easily!

1. Three-step evolution strategy of changing tire while driving

How to evolve from monolithic applications to microservices? These monolithic applications have existed for a long time, after such a long time of tinkering, the volume is relatively large, especially after several waves of human handover and maintenance, the business logic has become extremely complex. At the same time, they all provide services online, the possibility of overturning and reconstruction is very small, the investment of shock reconstruction is long, the risk is not easy to control, and it will also affect the continuity of business external services. From the perspective of reality, the most feasible architectural optimization solution is the gradual transformation of micro-services. according to the industry best practices and personal experience, the evolution strategy mainly includes three key steps:

Build all new features into microservices to curb the growth of monolithic applications

Build an anti-corruption layer between micro-services and monolithic applications to prevent old systems from corrupting new systems

Gradually disintegrate monolithic applications from the outside to the inside according to a specific priority.

1.1 New Micro Service

Usually, the technologies used in monolithic applications are relatively old, and colleagues who maintain these systems lack the opportunity to learn and practice current mainstream technologies, so they are unable to keep up with the development of mainstream technologies and lack competitiveness in promotion, salary increase and job-hopping, which affects personal value. With the increasing scale of the system, updating and upgrading and operation and maintenance are becoming more and more difficult, each release has to work overtime and fear, gradually can not meet the needs of the rapid development of business. Under the monolithic architecture, the team can not take advantage of different technology stacks to solve problems in different scenarios, and even if the problem is solved, it will get half the result with twice the effort.

When we realize the need to transform monolithic applications into microservices, we usually think that transformation is to knock down monolithic applications into microservices, which is the most direct, but also the most difficult and risky. At the beginning of the transformation, we are also relatively unfamiliar with the related technologies of micro-services, coupled with the difficulty of disassembling the monolithic application itself, the superposition of double difficulties will often lead to the failure or delay of the transformation.

The most reliable strategy is to stop adding new features to monolithic applications, and all new features are built into microservices to curb the continued growth of monolithic applications. New features are usually not too complex, and it is easier to create new micro-services than to separate them from monolithic applications, making the team more familiar with mastering the micro-service technology stack, from small-scale military training to full deployment. The common micro-service architecture is shown in the following figure, which mainly consists of the following essential components:

Registration center, which provides registration, discovery and status monitoring functions for microservices

Configuration center, decoupling code and configuration, managing configuration data of each microservice through a unified remote configuration center, supporting dynamic modification and immediate effect, etc.

Governance center, relying on registry and configuration center, providing service degradation, service breaker, flow control, grayscale management and other functions

The API gateway aggregates each micro-service together to provide services. The gateway itself provides cross-sectional functions such as security authentication, service routing, flow control, metering and billing.

1.2 build an anti-corruption layer

The new features are all built into microservices, but the old features are still in monolithic applications, and many businesses still need new and old systems to cooperate with each other, so microservices and monolithic applications still interact with each other. However, the protocols used by the new and old systems may be different. For example, micro-services developed by Spring Cloud framework are mainly served by RESTful HTTP API, while micro-services developed by Dubbo framework are served by Dubbo protocol, while monolithic applications may be served in the form of Web Service, EJB T3, non-standard HTTP API and so on. In addition to different protocols, new and old systems may have different definitions of domain models, including names and attributes, how to reconcile the differences between micro-services and monolithic applications?

Perhaps the most practical approach is to build an anti-corruption layer between microservices and monolithic applications. Through the anti-corruption layer to complete the docking integration of the new and old systems, we can avoid the interference of the old system domain model to the new system, keep each other in a loosely coupled state, and prevent the decay of the old system from spreading to the new system. The anti-corruption layer can also encapsulate monolithic applications so that they can serve as RESTful HTTP API like micro-services. The anti-corruption layer supports two-way communication, focusing on the integration of new and old systems, protocol adaptation and model conversion. According to this function, we can divide the anti-corruption layer into three modules:

Facade (Facade), classical design pattern, as the facade of all service interfaces of old systems, simplifies the complexity of interfacing between old and new systems

Adapter (Adapter), the classic design pattern, provides the required service entity to the new system, and is responsible for the protocol adaptation of request and reply.

The converter (Translator) is responsible for the conversion of new and old system domain models in requests and replies.

Because the architecture of monolithic applications is relatively simple, they seldom consider the design related to system integration at the beginning of their design. Usually, different services under an application have their own entrances. Facade is to solve this problem, unifying the external service format of monolithic applications, providing RESTful HTTP API services like micro services, standardizing the protocol types of interfaces, URL naming and message format, and so on. If the old system is not part of our maintenance, then the anti-corruption layer needs to include a Facade module through which the micro-service docks the old system. If the old system is also maintained by ourselves, it is recommended that the Facade module be built inside the monolithic application, and the micro-service should be docked with the old system through the Adapter module.

1.3 Application of encirclement and suppression

Build micro-services around the old system to curb the continuous growth of the old system, and then gradually peel off the micro-services from the old system, and finally complete the strangling of monolithic applications. Good micro-service design also follows the principle of high cohesion and low coupling, encapsulating closely related behaviors into a micro-service, thus reducing the scope of requirements changes. As long as the service contract does not change, the upgrade of a single micro-service will not affect other services, so fewer services can be released to meet business needs quickly and reduce the risk of deploying multiple micro-services at the same time. Before stripping microservices from monolithic applications, let's take a look at the types of boundaries between functional modules:

Technology boundary: the system is divided according to the different technology stack to form the boundary of two components. They use very different technologies and require different skills for developers. The industry calls this architecture the onion architecture, which has a lot of horizontal layering, which is not conducive to transformation into micro-services.

Regional boundaries: according to the geographical distribution of the organization, it is relatively easy to transform into micro-services.

Business boundary: divided by business type, it is most suitable to be the boundary type of micro-service.

Domain-driven design (DDD) theory puts forward the concept of bounded context (Bounded Context), which is an effective tool for us to clarify service boundaries, and we can use it to peel off micro-services from monolithic applications. Therefore, the micro-service transformation of monolithic applications, or new micro-services, we can not do without the support of business experts, through them to determine the division of bounded context, so as to design good micro-services.

two。 The isolation gateway takes over the interaction between new and old systems

In the previous section, we already know that the anti-corruption layer needs to be built in the process of micro-service transformation, so what form will the anti-corruption layer exist in the actual project? Usually, we design the anti-corruption layer as an isolation gateway, which runs as a separate process, and implements functional modules such as Facade, Adapter and Translator inside the isolation gateway. The isolation gateway does not need to be built from scratch. We can expand it on the basis of open source middleware such as Nginx, Kong and Zuul. They all support extended customization modes such as plug-ins or filters, and it is easy for us to achieve the functions needed by the anti-corruption layer.

Through the anti-corruption layer (isolated gateway) micro-services can communicate normally with monolithic applications while maintaining loose coupling with each other, monolithic applications can be modified without breaking bones, and micro-services can evolve independently using the latest technology. however, under this solution, these legacy monolithic applications can not enjoy the benefits of cloud native. Is there a way for these legacy systems to enjoy new features such as service discovery, flow control, service breaker, service degradation, and so on?

Service Mesh, the next generation micro-service architecture, can bring us a more perfect solution. It encapsulates the functional modules such as service governance that were previously intruded into the application through the micro-service development framework (such as Spring Boot, etc.) into Sidecar, deployed in pairs with the application, and exists as an independent process, so that it can be loosely coupled with the application and the architecture is more flexible. It can support independent upgrade deployment of infrastructure related to micro-service governance and can also support multiple languages. If the function of the isolation gateway is extended on the basis of Sidecar, the legacy monolithic applications can also be more integrated into the micro-service architecture.

3. The method of disassembling Micro-Service by monolithic Application

In this section, we will sort out some common scenarios and scenarios for stripping microservices from monolithic applications. Before we talk about specific cases, it is necessary to take a look at the experience summary of industry best practices, which mainly includes the following basic steps:

Identifying the contextual boundaries of a business segment is a key step in dismantling monolithic applications. Micro-services are divided and organized according to business. Before disassembling them, it is necessary to sort out the business functions provided by a single application, such as user management, commodity display, payment management and logistics management. The functional blocks divided according to the vertical direction can be transformed into micro-services. During the specific operation, most programming languages provide NameSpace features, which we can use to gather the same context-sensitive code together in the process of refactoring, and then disassemble it from the whole project to form a micro-service.

Clarify the dependence between business functional modules, reduce the dependency as much as possible, and start from the modules with frequent changes and high input-output ratio, which can gradually alleviate the schedule pressure of daily development. After combing the dependencies, the redundant dependencies will be eliminated, and the remaining dependencies will be transformed from function calls within the process to RESTful HTTP API calls between processes.

Disassemble data, including data access layer and database tables, etc. In addition to the code, the data is also disassembled, the data access layer is scattered into different namespaces, and the foreign key dependencies between database tables need to be cleaned up.

From the beginning of the business, to the code, and finally to the data, this is the key to the above three steps. Business is the source of all code and data, object-oriented design (OOD) and domain-driven design (DDD) are professional skills for micro-service design, and the premise of making good use of these two skills is to have a deep understanding of the business. In the (next) article, we will take a look at the specific disassembly scenarios, please look forward to!

Originality is not easy, please click "like" with your fingers. In the follow-up, I will continue to share the experience of career planning, job interviews, skills improvement, influence building, etc., pay attention to "IT veterans", empower the process of life!

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.