Matrix Underlying Support Framework: Hot Deployment, Front‑Middle Isolation, and Business Identity Design

The article begins with an overview of the recent shift toward middle‑platform (中台) architectures in large software organizations, emphasizing that the core value of a middle platform lies in accelerating delivery by separating stable core capabilities from front‑end customizations.

It then introduces the Matrix framework, JD.com's PaaS‑style solution that models business domains, abstracts core logic, and isolates high‑frequency personalized services into front‑end packages that can be developed and deployed independently.

Underlying Support Framework – The Matrix framework provides a set of standard protocols and capabilities for front‑end packages. It supports both push‑based and pull‑based hot‑deployment paths, enabling rapid integration of new front‑end functionality without restarting services.

Hot‑Deployment Design Principles – Two deployment chains are described:

Push chain: after a user triggers a push or take‑effect action in the control console, the Matrix SDK receives a change notification from the DUCC store and immediately downloads the new package, performing class loading, initialization, and lifecycle management.

Pull chain: during container scaling or periodic checks, the SDK queries the data center for the latest effective version and pulls the package if needed.

Both chains are illustrated with flow diagrams (omitted here) and the article explains when each is appropriate.

Front‑Middle Isolation Principle – Isolation is achieved by using separate class loaders. The middle platform uses the default ClassLoader, while front‑end packages are loaded by a custom BizClassLoader that extends URLClassLoader . The relevant code is:

protected Class
loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class
c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) { }
            if (c == null) {
                c = findClass(name);
            }
        }
        if (resolve) resolveClass(c);
        return c;
    }
}

The article notes that Matrix deliberately breaks the traditional parent‑delegation model to allow front‑end packages to access middle‑platform classes while keeping middle‑platform code insulated from front‑end implementations.

Business Identity Design Principle – Each front‑end package carries a business identity (BizCode) that the middle platform matches at runtime. Two identification methods are described: manual parser classes defined by the front‑end, and automatic parsers managed centrally by the middle platform (AutoBizCodeParser). The framework generates byte‑code templates for automatic parsing, exemplified by the following snippet:

#{ClassStart}
import java.util.*;
#{Package}
public class #{ClassName} {
    #{MethodInfo}
}
#{ClassEnd}

#{executeStart}
public boolean execute(Map context){
    #{VarInfo}
    return #{Express};
}
#{executeEnd}

Business identity ranking is determined by priority, version, and code, as implemented in the BizCodeSpec.compareTo method:

public int compareTo(BizCodeSpec o) {
    if (o == null) return -1;
    if (this.priority != null && o.priority != null) {
        int ret = o.priority - this.priority;
        if (ret != 0) return ret;
        if (this.versionSpec != null && o.versionSpec != null) {
            ret = this.versionSpec.compareTo(o.versionSpec);
            if (ret == 0) ret = o.bizCode.compareTo(this.bizCode);
            return ret;
        }
        return 0;
    }
    return 0;
}

The article warns of performance risks when identity‑matching logic is heavy and of unhandled Throwable errors that can abort the entire chain.

Best Practices – Recommendations include using distinct package namespaces for front‑end and middle‑platform code, limiting the scope of shared libraries, controlling front‑end package size during large‑scale deployments, and ensuring lightweight identity checks.

In conclusion, the author emphasizes that while middle‑platform and de‑middle‑platform strategies differ, both rely on solid technical foundations such as hot‑deployment, class‑loader isolation, and well‑designed business identity mechanisms to deliver fast, reliable, and maintainable services.