Youzan's Microservice Evolution and Best Practices with Spring Boot

In 2014 Youzan built all business functions (transactions, products, UMP, payments, etc.) as a single PHP monolith (v1.0). Rapid growth soon exposed limitations of this architecture.

From 2015 to 2016 the company began splitting services and moving to Java, using an internally improved Dubbox framework and the cross‑language Nova framework (v2.0). By 2017 the architecture further evolved toward microservices, adopting community‑provided components (v3.0).

Problems identified included increasing system complexity and fragility, high development and testing costs, merge conflicts, difficulty scaling horizontally, and lack of standardized environments.

The architectural goals were defined as:

Define system boundaries using Domain‑Driven Design (bounded contexts).

Split the system to enable parallel work and improve efficiency.

Establish collaboration principles and mechanisms between split parts.

Integrate the parts into a cohesive whole that meets system objectives.

Design dimensions were described as high‑level (service interaction structure), mid‑level (domain module division), and low‑level (code, data, table structures, technology choices).

To address the challenges, Youzan chose Spring Boot because it dramatically improves developer productivity, simplifies configuration, coding, testing, local debugging, and deployment with an embedded container, and offers a powerful SPI mechanism for custom auto‑configuration.

Key solutions implemented :

Created a Youzan BOM and youzan-boot-parent to unify version management and eliminate duplicate configuration across projects.

Standardized four environments (development, testing, pre‑release, production).

Restricted API JAR contents to avoid unnecessary dependencies and prevent version conflicts.

Extended Spring Boot with custom starters (e.g., youzan-boot-dependencies, nova-spring-boot-starter, mybatis-spring-boot-starter, etc.) to simplify component usage.

Example usage of the Nova framework requires only the @EnableNova annotation.

Health‑check standardization was introduced; a typical curl request and JSON response are shown below:

curl http://127.0.0.1:8080/health

{
  "status": "UP",
  "diskSpace": {"status": "UP", "total": 249779191808, "free": 61591195648, "threshold": 10485760},
  "redis": {"status": "UP", "version": "3.0.3"},
  "db": {"status": "UP", "database": "MySQL", "hello": 1},
  "refreshScope": {"status": "UP"},
  "hystrix": {"status": "UP"}
}

For resilience, the article advocates circuit‑breaker design (e.g., Hystrix) to protect callers, prevent cascading failures, enable fail‑fast, provide fallbacks, and allow real‑time monitoring and dynamic configuration.

Hystrix implementation principles include wrapping external calls in HystrixCommand, setting timeouts, using isolated thread pools, recording metrics, triggering circuit breaking based on error percentages, executing fallback logic, and supporting live configuration changes.

API documentation is generated automatically from tests using spring-restdocs, ensuring docs stay up‑to‑date with code changes.

Contract testing (Spring Cloud Contract) is recommended to keep service providers aware of consumer usage patterns and reduce breaking changes.

Continuous integration is emphasized as essential for maintaining quality, with benefits such as automated testing, metrics collection, dynamic log level adjustment, centralized configuration (Spring Cloud Config/Consul), service discovery, API gateway (Zuul), and distributed tracing (Zipkin).

Overall, the microservice best‑practice suite improves development efficiency, operational stability, and scalability for large‑scale internet applications.