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

This article introduces the knowledge of "what is the refactoring strategy of Java micro-service architecture". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Implement new features as services

The The Law of Holes says: if you find yourself in trouble, stop digging for yourself. This is a good suggestion when your monolithic application becomes unmanageable. In other words, if you have a large, complex monolithic application, don't implement new functionality by adding code to the monomer. This will make your unit larger and more difficult to manage. Instead, you should implement the new function as a service.

This is a good way to start migrating single applications to a microservice architecture. It reduces the growth rate of monomers, accelerates the development of new features (because it is developed in an entirely new code base), and quickly demonstrates the value of adopting a micro-service architecture.

Integrate new services with monomers

Figure 1 shows the application architecture after the new functionality is implemented as a service. In addition to new services and singletons, the architecture includes two other elements that integrate services into the application:

■ API Gateway: routes requests for new functionality to the new service and routes legacy requests to monomers.

■ integrated glue code: combine services with monomers. It enables the service to access the data owned by the monomer and to invoke the functions implemented by the monomer.

The code that integrates the glue is not a separate component. Instead, it consists of adapters in a single unit and services that use one or more interprocess communication mechanisms.

When to implement the new function as a service

Ideally, you should implement each new feature in the strangler application rather than in a single unit. You will implement new features as new services or as part of existing services. This way you can avoid dealing with a single code base. Unfortunately, not every new feature can be implemented as a service.

Because the essence of micro-service architecture is a set of loosely coupled services organized around business functions. For example, a feature may be too small to be a meaningful service. For example, you may only need to add fields and methods to an existing class. Or the new function may be tightly coupled to the code in the monomer. If you try to implement this kind of functionality as a service, you will usually find that performance is degraded due to too much interprocess communication. You may also encounter data consistency problems. If the new functionality cannot be implemented as a service, the solution is usually to implement the new functionality in a single unit first. After that, you can extract this function and other related functions into your own service.

Implementing new functions in the form of services can speed up the development of these functions. This is a good way to quickly demonstrate the value of a micro-service architecture. It can also reduce the growth rate of monomers. But in the end, you need to use two other strategies to break down the monomer. You need to migrate the functionality from the monomer to the hanger application by extracting the functionality from the monomer to the service. You can also improve development speed by horizontally splitting the monolithic architecture. Let's see how to do this.

two。 Isolate the presentation layer from the backend

One strategy for shrinking single applications is to separate the presentation layer from the business logic and data access layer. A typical enterprise application consists of the following layers:

■ presentation logic layer: it consists of modules that process HTTP requests and generate HTML pages that implement Web UI. In applications with complex user interfaces, the presentation layer usually contains a lot of code.

■ business logic layer: consists of modules that implement business rules that can be complex in enterprise applications.

■ data access logic layer: contains modules that access infrastructure services such as databases and message agents. There is usually a clear boundary between the presentation logic layer and the business and data access logic layer. The business layer has a coarse-grained API, which consists of one or more Facade that encapsulate business logic. This API is a natural seam along which you can divide the monomer into two smaller applications, as shown in figure 2.

One application contains the presentation layer, and the other contains the business and data access logic layer. After segmentation, the presentation logic application makes remote calls to the business logic application.

There are two main benefits of splitting monomer applications in this way. It enables you to develop, deploy, and extend these two applications independently of each other. In particular, it allows presentation-tier developers to quickly iterate through the user interface and easily perform Ahand B tests without having to deploy the back end. Another benefit of this approach is that it exposes a set of remote API of business logic that can be invoked by microservices developed later.

But this strategy is only part of the solution. It is likely that at least one or two final applications are still an unmanageable monomer. You need to use the third strategy to replace the monomer with the service.

3. Extract business capabilities into services

Implementing new functionality as a service and splitting the front-end Web application from the back end will not bring you to the other side of victory. You will still end up doing a lot of development in single code. If you want to significantly improve the architecture of your application and speed up development, you need to split the single application by gradually moving business functions from monoliths to services. When you use this strategy, over time, the number of business functions implemented by the service increases, while the single unit gradually shrinks.

The function you want to extract into the service is to apply a top-down "vertical slice" to the individual. The slice contains the following:

■ implements the inbound adapter for API endpoints.

■ domain logic.

■ outbound adapters, such as database access logic.

■ monolithic database schema.

As shown in figure 3, this code is extracted from a single unit and moved to a stand-alone service. API Gateway routes requests that invoke extracted business functions to the service and routes other requests to monomers. Monomers and services collaborate by integrating glue code. The integrated glue consists of adapters in the service and monomers that use one or more interprocess communication mechanisms.

Extracting services is challenging. You need to determine how to divide the single domain model into two separate domain models, one of which becomes the service domain model. You need to break dependencies such as object references. You may even need to split the categories to move the functionality to the service. By the way, you also need to ReFactor the database.

Extracting services is often time-consuming, especially when the code base of a single unit is chaotic. Therefore, you need to carefully consider the services to be extracted. You should focus on refactoring parts of the application that provide a lot of value. Before you extract the service, ask yourself what are the benefits of doing so.

For example, it is worthwhile to extract a service that implements a function that is critical to the business and is constantly evolving. If there are not many benefits, it is worthless to put effort into extracting services. Later in this section, I will introduce some strategies for determining the scope and timing of service extraction. But first, let's take a more detailed look at some of the challenges we will face when extracting services and how to address them.

The following challenges are encountered when extracting services:

■ disassembles the domain model.

■ reconstructs the database.

Disassemble domain model

In order to extract services, you need to extract service-related domain models from individual domain models. You need to make big moves to split the domain model. One of the challenges you will face is to eliminate object references that cross service boundaries. A class that remains in a monomer may refer to a class that has been moved to a service, and vice versa. For example, imagine, as shown in figure 4, that you extract Order Service whose Order class references a single Restaurant class. Because a service instance is usually a process, there is no point in letting object references cross service boundaries. You need to eliminate this type of object reference.

A good way to solve this problem is to think in terms of DDD aggregation. Aggregations use primary keys instead of object references to refer to each other. Therefore, you can think of the Order and Restaurant classes as aggregates, as shown in figure 5, replacing the reference to Restaurant in the Order class with the restaurantId field that stores the primary key value.

One problem with replacing an object reference with a primary key is that while this is a small change to the class, it can have a significant impact on the client of the class that you expect the object to reference. Later in this section, I'll show you how to reduce the scope of changes by copying data between services and singletons. For example, Delivery Service can define a Restaurant class, which is a replica of the Restaurant class in a single unit.

Extracting a service is usually much more work than moving the entire class into the service. The greater challenge of splitting the domain model is to extract the functionality embedded in classes with other responsibilities. This problem often occurs in God Class with too many responsibilities. For example, the Order class is one of the God classes in FTGO applications. It implements a variety of business functions, including order management, food delivery management and so on. The Delivery entity implements the delivery management functionality that was previously bundled with other functions in the Order class.

Reconstruct the database

Splitting the domain model involves more than just changing the code. Many classes in the domain model are persisted in the database. Their fields are mapped to a specific database schema. Therefore, when you extract a service from a single unit, you also move the data. You need to move the table from the single database to the service database.

In addition, when you split an entity, you need to split the corresponding database table and move the new table to the service. For example, when extracting delivery management into a service, you need to split the Order entity and extract a Delivery entity. At the database level, you split the ORDERS table and define a new DELIVERY table. Then, move the DELIVERY table to the service.

Copy data to avoid broader changes

As mentioned above, the extraction service requires you to make changes to the single domain model. For example, replace object references with primary keys and split classifications. These types of changes may affect the code base and require you to make extensive changes to the affected parts of the individual units. For example, if you split the Order entity and extract the Delivery entity, you must change each part of the code that references the moved field. Making these changes can be time-consuming and can be a huge barrier to breaking monomers.

A good way to delay and possibly avoid making these expensive changes is to use methods similar to those described in the book Database refactoring. A major obstacle to refactoring a database is to change all clients of the database to use the new schema. The solution proposed in this book is to retain the original mode during the transition period and use triggers to synchronize between the original mode and the new mode. You can then migrate the client from the old mode to the new mode.

We can use a similar approach when extracting services from monomers. For example, when extracting Delivery entities, we leave most of the Order entities unchanged during the transition period. As shown in figure 6, we set the fields related to delivery to read-only and keep the data * * by copying the data from the Delivery Service back to the monomer. Therefore, we just need to find the location in the individual code to update these fields and change them to call the new Delivery Service.

By copying data from Delivery Service to preserve the structure of Order entities, we can significantly reduce the amount of work we need to do immediately. Over time, we can migrate code that uses Order entity fields or ORDERS table columns related to delivery to Delivery Service. More importantly, we may never need to make changes in monomers. If the code is then extracted into the service, the service can access the DeliveryService.

Determine which services to extract and when

As I mentioned, it takes time to disassemble the monomer. It disperses the human resources to implement the new functions. Therefore, you must carefully determine the order in which services are extracted. You need to focus on extracting services that generate revenue. More importantly, you want to constantly demonstrate to the business unit the value of migrating to a micro-service architecture.

In any journey, it is important to know where you are going. A good way to start migrating to microservices is to use time frames to define work. You should spend a short period of time, such as a few weeks, brainstorming to discuss the ideal architecture and define a set of services. This will provide you with a goal. However, it is important to remember that this architecture is not immutable. When you break down the unit and gain experience, you should apply the experience you have gained to adjust the refactoring plan in a timely manner.

Once the goal is set, the next step is to start splitting the monomer structure. Several different strategies can be used to determine the order in which services are extracted.

One strategy is to effectively freeze the development of a single architecture and extract services on demand. You can extract the necessary services and make changes instead of implementing functions or fixing errors in a single unit. One of the advantages of this method is that it forces you to break the monomer. One drawback is that service extraction is driven by short-term demand rather than long-term demand. For example, even if you make small changes to relatively stable parts of the system, you need to extract services. As a result, the amount of work you do may only be a small gain.

Another strategy is a more planned approach, where you can rank application modules according to the expected benefits of extracting application modules. There are several reasons why extraction services are beneficial:

■ accelerated development: if your application's roadmap indicates that a particular part of the application will be heavily developed next year, converting it to a service can speed up development.

■ addresses performance, scalability, or reliability issues: if there is a performance, scalability problem, or unreliability in a particular part of the application, it is valuable to convert it into a service.

■ allows you to extract other services: sometimes extracting one service simplifies the extraction of another service because of the dependencies between modules. You can use these conditions to add refactoring tasks to the to-do list of your application and rank them by expected revenue. The advantage of this approach is that it is more strategic and more in line with business needs. When planning for Sprint, you can determine which is more valuable to implement functions or extract services.

This is the end of the content of "what is the refactoring strategy of Java micro-service architecture". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.