How to break down monolithic applications into microservices? 【 the 】

How to Design a Beautiful Web API? , now read more than 2400, friends do not miss oh!

Golden Nuggets: How to design a beautiful Web API?

Following yesterday’s post: How to break down monolithic applications into microservices? [Top], today let’s take a look at the solutions of various specific dismantling scenarios:

• Scenario 1: Foreign key reference relationships of database tables

If there is a data reference relationship between two functional modules in a single application, how can we eliminate this foreign key reference relationship when dismantling microservices? First, stop foreign key references; Then, the RESTful HTTP API is used to retrieve the original foreign key association information. As shown in the figure below, the records in the Payment database table refer to Order by foreign key before the transformation. The code level usually uses the object relational mapping (ORM) framework to establish the association of data objects. After the transformation, the code level cannot use the ORM framework to do the association. The primary key value of the Order is stored in the records of the Payment database table, in addition to the key attribute information of the Order, which avoids frequent cross-process calls and improves the overall efficiency performance of the system.

The picture below is the situation before the transformation:

The picture below is the situation after transformation:

• Scenario 2: Sharing static data relationships

If two functional modules in a singleton application share static data with each other, how do we eliminate this sharing when dismantling microservices? Static data is usually stored in a database, such as a commodity category code. If this static data needs to be updated, we need to release the system frequently, which can lead to multiple service outages.

To avoid this problem, we could also make multiple copies of the static data, one for each service, but maintaining consistency across multiple copies of the data is a problem. Alternatively, we can store this static data in a configuration file for each service, making it easier to update the data. The unified configuration center, a required component of the microservices architecture, allows us to manage this static data for the convenience of maintenance updates.

• Scenario 3: Sharing basic data relationships

If two functional modules in a monolithic application share some kind of basic data, how can we eliminate this sharing relationship when dismantling microservices? Multiple services share some kind of basic data, such as user data, logistics company data, etc., so we need to refine a special domain model for this kind of data, encapsulate it into micro services, and then access these shared basic data through this service. The advantage of servitization is that each side is only dependent on the service contract, and both sides are free to adopt specific technologies and solutions. As long as the service contract is not changed, upgrades to each other are not affected.

The picture below is the situation before the transformation:

The picture below is the situation after transformation:

• Scenario 4: Sharing database tables

If two functional modules in a monolithic application share a data table, how do we eliminate this sharing relationship when dismantling microservices? The data referenced by multiple services are combined and stored in a database table, and the code level realizes polymorphism with the help of ORM framework. In this case, we need to separate out the data concerned by each service and store them in different tables.

The picture below is the situation before the transformation:

The picture below is the situation after transformation:

• Scenario 5: Sharing a database

How do we split the database in the process of dismantling microservices? The safest solution is to refactor the database in stages. Data is the most valuable resource, so don’t try to do it all at once.

The picture below is the situation before the transformation:

• The first step is to disassemble a database into two databases according to the business context, but the application is still a single application, and the application can access two databases at the same time through multi-data source related technologies, as shown in the figure below:

• The second step is to disassemble the single application into microservices. Each microservice has its own independent database, as shown in the figure below:

• The principle of priority of old module micro-service transformation

Isolate bounded contexts from monolithic applications as candidates for stripping microservices, and then start refactoring each functional module in turn. So how do you decide which modules should be spun off as microservices first? From the perspective of module stripping difficulty, we can follow the principle of easy first, then difficult, and gradually accumulate reconstruction experience, which is suitable for teams with less experience in micro-service construction. From the perspective of demand change frequency, the modules with frequent changes should be stripped first, and the overall benefits will be greater. This is a good judgment criterion for teams with relatively tight human resources. In terms of resource consumption type, computing or memory-intensive modules are preferentially stripped to improve resource utilization efficiency during elastic scaling, which is most obvious for large-scale system scenarios. From the perspective of service boundary granularity, the coarser the better the stripping. Which rules should be followed to arrange the transformation sequence of microservices, which should be analyzed according to the specific situation of each team.

In the process of supporting different systems to implement microservice transformation, the above priority principle has been adopted, and the reason for the existence of priority is the lack of resources. The transformation of micro services is not an overnight thing. The process will last for a long time, maybe several years, and different issues need to be considered at different stages. The core principle is to carry out the work in an orderly manner according to the pace that suits you, and pursue speed appropriately while ensuring the stability of online business.

• Whether the micro service transformation is over the judgment criteria

So when is the microservices transformation complete? The judgment criterion is that all bounded contexts in the old system are stripped into micro-services, and the anti-corruption layer can be abolished. Or the remaining monomer application is relatively stable and no longer changes, and the reconstructed input-output ratio is no longer cost-effective; Or the legacy single application associated business has been withdrawn from the market, the system offline.

• New challenges and solutions for microservices architecture

When monolithic applications are broken down into multiple microservices, what was once within one transaction boundary now spans multiple transaction boundaries. How do we ensure transaction consistency? Here are some distributed transaction mechanisms:

• Try again for consistency: Queue each step and try again to ensure that the execution succeeds and the status is consistent.
• Undo all operations: Compensates the transaction mechanism by starting a new transaction to undo the previous operation after the failure of the original transaction. If the compensation transaction also fails, the system needs to provide the ability to run the compensation transaction again either manually or automatically.
• Distributed transactions: a global transaction manager is used to coordinate the successful execution of transactions. For short-term transactions, two-phase Commit is commonly used. The first Phase is a voting Phase, in which the participants of the distributed transaction tell the transaction manager whether the local transaction can be successfully executed. If the transaction manager collects YES for all votes, the commit transaction execution begins.

Distributed transaction mechanism itself is not too complicated, we refer to some open source products in the industry since the developed a set of distributed transaction framework, combined with micro service framework, and application developers only need to implement specific interfaces in accordance with the provisions of the framework, through some annotations can initiate a distributed transaction, the details can refer to GTS ali’s global transaction services.

When monolithic applications are disassembled into multiple microservices, the previously centralized data is also stored separately, and report generation will encounter new challenges. In single application scenarios, there is usually a secondary library for generating reports. Data is synchronized from the primary library and is used only for read operations such as query, preventing report generation from affecting the read and write efficiency of the primary library. In the case of microservices, we will retrieve data through service calls, design batch interfaces suitable for report statistics, and increase caching to improve data retrieval efficiency.

• Data extraction: Retrieving the data needed for the report through service calls, which can be very heavy and has aN API designed specifically for the report. To compensate, we can separate the data extractor from the business database to the report database.
• Event-driven data extraction: Based on the event-driven microservices architecture, we can develop event-specific subscribers who are responsible for synchronizing data to the report database, thus decoupling the underlying database system.

Microservices transformation is a long-term process that will encounter a variety of problems, and methodology can help us better solve these problems and reduce risks. Welcome to discuss any problems encountered in the process of micro-service transformation!

Today, first share here, if you think it is valuable, please move your hands and point to “👍”, so that more partners can see, I will be more motivated to insist on sharing. In addition, I will share my experience in career planning, job interview, skill improvement and influence building in the future. Pay attention to this column or the public account “IT Veteran brother”, enabling program life!