How We Refactored a 670k‑Line, 46‑Module Ticket System to Slash Deployment Time

Background

Alibaba Group’s customer‑service ticket system, originally built as a micro‑service platform for internal use, was commercialized for external customers. After two years of iteration the codebase ballooned to 670,000 lines across 46 modules, turning a clean architecture into a tangled monolith.

Problems Encountered

Huge codebase and high development/operations cost; difficulty locating bugs.

Fat JAR files loading many unused components, causing long start‑up times.

Redundant, lengthy request chains consuming resources.

Excessive configuration files increasing migration and deployment effort.

Business logic for different commercial scenarios tightly coupled in the core code.

Value of Refactoring

Simplify development and operations by redesigning a clean, highly cohesive, low‑coupling codebase.

Boost developer productivity – code‑review time dropped dramatically and deployment time fell from 25‑30 minutes to under 3 minutes.

Reduce resource consumption – better query performance, fewer middle‑wares, and lower memory usage.

Improve system stability with a clear, short call‑graph.

Provide a clear layered architecture that eases future extensions.

Decouple commercial scenarios (e‑commerce, DingTalk, etc.) via extension points.

Technical Solution

The refactor introduced a six‑layer architecture:

Overall Code Architecture – a three‑tier design (service, manager, dao) sufficient for the ticket domain.

Adapter Layer – maps old HSF interfaces to new ones without business logic.

Business Capability Layer (service) – exposes 18 fine‑grained MTOP interfaces, OpenAPI endpoints, and e‑commerce‑specific APIs.

Domain Capability Layer (manager) – splits the ticket domain into ~30 sub‑domains, each providing core abilities reusable across services.

Data Synchronization – redesigns asynchronous pipelines (e.g., ES sync for case and task data).

External Service Hub – consolidates calls to third‑party services, removes result wrappers, and adds unified logging.

DAO Layer – replaces a custom ORM with MyBatis, adding enhanced query utilities.

Key code examples include the abstract BaseActivity class, concrete CaseCreateActivity, and the extension‑point framework ( MonoExtPoint, BiExtPoint, TriExtPoint) that enables plug‑in implementations for different business scenes.

Comprehensive Effect Analysis

Code reduction came from high cohesion in domain capabilities, removal of dead switches, duplicated logic, and migration to MyBatis.

Fat‑JAR shrinkage resulted from pruning unused Maven dependencies and eliminating heavy client libraries.

Deployment & start‑up speed improved due to smaller artifacts, removal of heavyweight code‑platform clients, and fewer Spring bean registrations.

Configuration simplification was achieved by deleting unused Nacos entries and moving stable settings into code.

Release Plan

Switch all message topics to the new ones.

Validate traffic‑exposed interfaces via monitoring tools.

Gradual canary rollout: start with a few pods in beta, then increase until full coverage.

Push all exception logs to DingTalk for real‑time alerting.

During gray release, run new and old code side‑by‑side; if results diverge, fallback to the old implementation and raise an alarm.

Thoughts on Code Quality

The author stresses that excessive if‑else, redundant try‑catch, and scattered logging obscure core logic. Linear, readable code, consistent indentation, and lightweight frameworks are essential for maintainability, especially in data‑intensive B2B systems.

Future Planning

The next step is to evolve the ticket system’s extension mechanism toward low‑code, lightweight, and richer tooling, further reducing customization cost and improving extensibility.