Designing Extensible Business Systems with Microkernel Architecture and Dynamic Component Composition

The article discusses how to design business systems that satisfy both speed and quality requirements by focusing on extensible architecture. It starts with an introduction that highlights the challenges of increasing system complexity and technical debt in fast‑paced internet development.

It then introduces the microkernel pattern as a solution. The microkernel separates a small, stable core from extensible plug‑in components, following high cohesion, low coupling, and open‑closed principles. The core defines basic business processes, while each component implements specific functionality and can be customized per scenario.

Key responsibilities of a microkernel are listed:

Process definition

Component definition

Component invocation

An example from an e‑commerce checkout service is provided, showing interface definitions for ReceiverLoader , InventoryChecker , DeliveryLoader , and PayTypeLoader . Different implementations can be combined to satisfy various business scenarios such as physical vs. virtual goods.

interface ReceiverLoader {
    // 根据 userId 加载收货人信息
    Receiver load(Long userId);
}

interface InventoryChecker {
    // 根据商品 SKU 查询库存数据
    InventorySummary check(List<String> skus);
}

interface DeliveryLoader {
    // 返回用户和商品类型对应的可用递送方式
    DeliverySummary load(Long userId, CommodityType commodityType);
}

interface PayTypeLoader {
    // 根据 userId 返回可用的支付方式
    List<PayType> load(Long userId);
}

The article then compares static composition and dynamic composition . Static composition is illustrated with a Spring XML configuration where two beans ( checkoutService and virtualCheckoutService ) share the same implementation class but differ in property values.

Dynamic composition is described as using matcher annotations (e.g., version matcher, equal matcher) or rule‑driven registries to select components at runtime, avoiding hard‑coded conditional logic. A sample dynamic component implementation is shown:

class NewComponent implements Component {
    @Autowired
    private ComponentRegistry registry;

    public boolean canProcess(Request request) {
        return request.getParam1().equals("abc") && request.getParam2().equals("def");
    }

    @PostConstruct
    public void init() { register(); }

    public void register() { registry.register(Component.class, this); }
}

The article then presents a real‑world practice from iQIYI’s membership transaction team. It describes the redesign of the order‑payment service using a core module for the main flow and pluggable handlers (either annotation‑based or configuration‑file based) for specific scenarios. Example annotation‑based handler configuration:

@PayRequestMapping(
    payTypes = {ALIPAY, ALIPAY_V3},
    platformTags = {PlatformTag.H5}
)
@Component
class AliPayH5OrderPayHandler implements OrderCustomizer, GatewayPayRequestCustomizer {
    @Override
    public void customize(Order order, PayContext payContext) { /* ... */ }
    @Override
    public void customize(GatewayPayRequest gatewayPayRequest, PayContext payContext) { /* ... */ }
}

And a JSON‑style file configuration example:

{
  "handlers": [
    {
      "name": "WeChatOrderContract",
      "mapping": {
        "payTypes": [379, 380],
        "platformTags": ["h5", "android"]
      },
      "gatewayPayRequest": {
        "extendParameters": { "isFirstSign": "yes" }
      },
      "resultType": "DIRECT_AND_JSON"
    }
  ]
}

After the redesign, most simple payment scenarios only require adding new configuration, while complex scenarios benefit from clearly defined extension points, dramatically reducing code complexity.

The article introduces the open‑source Navi project, which provides a generic framework for declarative component selection. It shows a simple example with an OrderCreateHandler interface and two implementations ( AndroidV1Handler and AndroidV2Handler ) selected via matcher annotations:

interface OrderCreateHandler {
    void handle(Order order, OrderCreateRequest request);
}

@EqualMatcher(property = "clientType", value = "android")
@VersionMatcher(range = "[1.0.0,2.0.0)")
@Component
class AndroidV1Handler implements OrderCreateHandler { /* ... */ }

@EqualMatcher(property = "clientType", value = "android")
@VersionMatcher(range = "[2.0.0,3.0.0)")
@Component
class AndroidV2Handler implements OrderCreateHandler { /* ... */ }

public class OrderService {
    public OrderCreateResult createOrder(OrderCreateRequest req) {
        OrderCreateHandler handler = selector.select(req, OrderCreateHandler.class);
        if (handler != null) {
            handler.handle(order, req);
        }
    }
}

The article explains built‑in matcher annotations (EqualMatcher, VersionMatcher, ContainMatcher, IntersectMatcher) and how to compose them into custom composite matchers using meta‑annotations.

Finally, the article concludes with a summary emphasizing that extensibility, though less discussed than high availability or concurrency, is crucial for rapid business growth. It notes that designing extensible systems reflects a developer’s architectural skill.

At the end of the document, a recruitment advertisement for senior Java developers at iQIYI is included, but the technical content preceding it provides substantial academic value.