How ZTO’s “掌中通” App Scaled from Monolith to High‑Performance Microservices

1. Project Background

“掌中通” is a one‑stop office platform app for ZTO couriers, designed to improve work efficiency and service quality. It supports the daily operations of over 300,000 couriers, handling 20‑30 million parcels per day with a peak interface call volume of about 160 million per day. The backend integrates numerous internal and external services.

2. Project Process

2.1 From MVC Monolith to Dubbo RPC Services

The initial system used an MVC three‑layer architecture (SSM stack) with Nginx load balancing. As user volume grew, the monolith showed inflexibility, poor reliability, and limited scalability. Incremental refactoring introduced Dubbo RPC services, an API gateway for unified authentication, and isolated batch jobs, consumption systems, and background services.

Internal Titans framework, Apollo configuration center, Cat monitoring, and ELK logging were integrated to enable real‑time configuration, monitoring, and log analysis.

2.2 From All‑in‑One Business Module to Microservice Splitting

The AKF scalability cube model guided the decomposition:

X‑axis (Horizontal Scaling): Clone services and data across multiple instances with load balancing.

Y‑axis (Service/Resource Scaling): Split responsibilities into independent services (microservices) and separate databases.

Z‑axis (Sharding): Partition data by unique request attributes, achieving data sharding and table partitioning.

Microservice design followed five principles:

Single‑responsibility: each service handles one business module.

Loose coupling: services are independent, with versioned contracts.

Lightweight communication: HTTP or RPC instead of heavyweight ESB.

Clear contracts: interfaces are exposed while implementations stay hidden.

Component reuse: shared core modules are extracted as reusable services.

Benefits included high cohesion, low coupling, flexible governance, better scalability, and improved maintainability.

2.3 High‑Concurrency Performance and High‑Availability Guarantees

To handle growing traffic and ensure 100 % courier usage, the team applied:

Concurrent and asynchronous external calls (e.g., RocketMQ for weight scanning and user‑tag pushes).

Extensive caching with Redis and multi‑level CDN.

Circuit‑breaker, rate‑limiting, and fallback using Hystrix, dynamically tuned via Apollo.

Dubbo service governance for manual degradation during emergencies.

3. Conclusion

By iteratively refactoring the system alongside regular releases, the team achieved a smooth transition to a microservice architecture without a disruptive rewrite, solving existing bottlenecks and meeting current and future business demands while planning further enhancements for user experience and cost efficiency.