Service Code Deconstruction Tool – SWAK

By Zisi, from Xianyu Technology

Introduction

The continuous development of business, the continuous increase of commodity types, and the continuous addition of business requirements make the Xianyu code appear like a "bad sell." The coupling of platform code and business code is difficult to separate, and the code interweaving between businesses lacks disassembly. This is also a common fault in the industry. Xianyu has developed a set of technical frameworks called SWAK to solve such problems. This article explains how SWAK deconstructs the Xianyu code.

SWAK is short for Swiss Army Knife. For those that don't know, a Swiss Army Knife is a small, multi-tool pocket knife suitable for various scenarios. On the Xianyu server side, the SWAK framework is also a small and flexible technical framework suitable for multiple scenarios. The scenarios it uses have the same feature-regular execution between multiple implementations. This article will begin with an example to introduce the concepts in detail.

Multi-Implementation and Regularized Execution

Those familiar with Xianyu app should know that commodities have rich forms of expression in the app, which may be called type A, type B, and type C. Various types can also have their own subtypes. Each type of business logic has certain commonalities, but there are also some differences (for example, on the sharing page, the display logic of the subtitle field is different):

This single implementation is usually written as the following code:

if(typeA) {
    if(typeA1) {
        doSomething1();
    }else if(typeA2) {
        doSomething2();
    }
} else if(typeB) {
    doSomething3();
} else if(typeC) {
    if(typeC) {
        doSomething4();
    }else if(typeC2) {
        doSomething5();
    }
}

Everyone should have written a lot of similar codes. It is understandable to write like this when the logic is simple, but when the logic starts to become complicated, this writing will have more disadvantages:

It is difficult to extract public logic, and code blocks are becoming more bloated.
New types of implementations with more similarities and fewer differences make it harder to reuse the original code.
Each type of code is fused together. Changing the code may affect other types, increasing the risk of launching and the cost of testing regression.
For the new developers, the cost of understanding is high, and it is difficult to get started, which virtually reduces the development efficiency.

According to the object-oriented idea, the way to obtain titles is consistent for all types and should be precipitated into platform logic, while obtaining subtitles can be abstracted into an interface method, while goods of type A, type B, and type C all have their own implementations. The interface method of obtaining subtitles has many implementations.

What is regular execution? In the example above, we have logically separated according to the type of goods, but usually, it is not thorough. For example, the division of the operation team may also be divided according to the type of goods, the category system (such as mobile phones, 3C digital, clothing, books, etc.), or even the region. Then, a good may be subject to the commodity type system, the category system, and the region. If several constraints are inconsistent, conflicts will arise. For example, the subtitle field should show the price from the perspective of type A, and perhaps, it should reveal the publishing house from the perspective of the book category. After all, most people that love reading pay more attention to quality, and publishers are an important criterion to measure quality. Should it show prices, publishers, or show it all? If they are all shown, do you want to show the price first or the publisher first? What if one line is not enough to display everything? No matter which of the display methods above, behind it are rules (known as strategy in the design pattern), and the code is written according to the rules.

The example above is a classic scenario of multiple implementation regularization execution. Similarly, logic (such as ABTest and double write) is also an application scenario that implements regular execution.

Basic Ideas

In the example above, distinguishing by product type or by product category creates conflicts. It doesn't matter the type or category. For the commodity object, it is nothing more than putting different labels on it. For example, a type A book is labeled type A and book. The acquisition subtitle interface method of type A corresponds to one implementation, while the acquisition subtitle interface method of book corresponds to another implementation. When an object is labeled with multiple labels, the implementation corresponding to multiple labels will conflict.

Conflict resolution depends on rules. The two most important parts of rules are priority and reduce policies. The order of execution is determined by priority. Displaying the results of the first implementation, displaying the results of the second implementation, or splicing the results of the two implementations are all reduction strategies. Rules can also contain other components, such as parallel execution mode and exception handling mode.

As stated above, the basic idea of SWAK can be derived:

The label that the analysis object has.
Separate immutable logic and variable logic – Variable logic is abstracted into interfaces.
Variable logic has multiple implementations depending on the label. Each implementation is independent; meaning, each implementation is isolated from the other.
When an object has multiple labels at the same time, priority and reduction policies are used to resolve conflict issues.

It is worth mentioning that the basic idea of SWAK is borrowed from the TMF architecture mid-end by Alibaba. For details about TMF, please refer to the "Trading Platform Architecture Based on TMF Framework" chapter from the book entitled All in Double 11-Alibaba Technology Evolution and Transcendence.

Accordingly, using the SWAK framework will bring the following benefits:

The code logic is clear, variable, and immutable at a glance.
Code reuse becomes high.
Variable logic is isolated based on tags. The implementation of a single tag does not affect the implementation of other tags, reducing development and testing costs. No matter according to type or category, the corresponding development and testing students only need to pay attention to the corresponding logic.
The new developers can understand and get started quickly.

How It Works

The SWAK framework is more inclined to analyze the execution logic of an object with a certain number of labels under different implementation methods than the way to scan and load implementation classes according to labels during the operation period. On the one hand, caching can reduce the response time significantly. On the other hand, it is also convenient to find and troubleshoot problems during development. The overall implementation principle can be divided into two parts: registration and execution. The basic process is listed below:

During the registration process, the SWAK framework will scan files (multiple implementation interfaces, reduction policies, and conflict priorities are configured with Java annotations or XML files. The following code example describes how multiple implementation interfaces and their implementation classes are configured.) The scanned results are all registered in the local cache. During execution, the SWAK framework will look for its required conflict priority configuration and reduction policies from the local cache, which helps reduce the response time. In addition, the use of a unified local cache is helpful for visual presentation. Developers can see and analyze the execution process of the program intuitively. Product managers can also see which function points can be expanded, where priorities need to be updated, and even help estimate and schedule requirements intuitively. The use of a unified local cache also provides the possibility for visualized configuration. Combined with the Alibaba Internal Diamond or Switch Framework (lightweight switch and dynamic configuration items management framework), conflict priorities can be updated without updating codes and only pushing configurations, providing convenience for development and testing.

/**
 * A simple demo is used here to demonstrate the basic configuration. The actual business is far more complicated than demo.
 */
@SwakInterface(desc="obtain subtitle") // Use annotations to declare that this is a multi-implementation interface.
public interface SubtitleFetcher {
    @SwakMethod
    String fetchSubtitle();
}

@SwakTag(tags = {"tagA"}) // Use SwakTag to bind tagA
@Component
public class TagASubtitleFetcher implements SubtitleFetcher {
    @Override
    public String fetchSubtitle() {
        return "I am TagA";
    }
}

@Component
@SwakTag(tags = {"tagB"}) // Use SwakTag to bind tagB
public class TagBSubtitleFetcher implements SubtitleFetcher {
    @Override
    public String fetchSubtitle() {
        return "I am TagB";
    }
}

Xianyu server applications are basically based on the Spring framework. We required SWAK to be 100% compatible with the Spring framework at the beginning of the design to facilitate the use of the SWAK framework on server applications. The final implementation version does this. Whether it is the bean of the business or the bean introduced by the SWAK framework itself, it is completely hosted by the Spring container. The framework also uses cglib to proxy a series of processes in the execution process in the figure above, which is completely executed by the framework and is completely transparent and unaware to the development students. It is used as a common single-implemented interface, as shown in the following code block.

@Autowired 
private SubtitleFetcher subtitleFetcher;
    
    //Omit a large section of code ........
   String subtitle = subtitleFetcher.fetchSubtile();
    //Omit a large section of code .......

Application in Xianyu

The SWAK framework has been applied to some processes of product release and editing. We are actively extending the SWAK framework to more processes. The following figure shows the transformation plan of the core functions of the commodity domain based on the SWAK framework. After the upgrade and transformation based on SWAK, the core functions of the Xianyu commodity domain are isolated according to business. Each business development student only needs to relate to the development of their corresponding business. Its general logic and business isolation are fully guaranteed by the first and second layers based on the SWAK framework. Code quality and development efficiency will be improved significantly.

Summary

SWAK, a multi-implementation regularized execution framework developed by Xianyu, can solve the problems of serious separation of platform code and business code coupling and the lack of disassembly of code interleaving between businesses. SWAK 100% is compatible with Spring, which is easy to use and get started. As its derived name suggests, the SWAK framework works like a Swiss Army Knife. It can be applied to a variety of small and convenient scenes. SWAK is still evolving, and the features and functions are still being enriched. Similarly, there are many interesting and creative attempts in the Xianyu app.

Community

Service Code Deconstruction Tool – SWAK

Introduction

Multi-Implementation and Regularized Execution

Basic Ideas

How It Works

Application in Xianyu

Summary

Read previous post:

Read next post:

XianYu Tech

You may also like

Comments

XianYu Tech

Related Products

DevOps Solution

EMAS Superapp

Web App Service

Web Hosting Solution