Microservice Practices and Lessons from iQIYI Video Backend Development Team

As systems grow larger and more feature‑rich, teams often encounter problems such as high impact‑cost evaluation for small requirements, lost or out‑of‑date API documentation, constant online issue triage, and difficulty adding new services without bloating existing ones. This article shares the iQIYI video backend team's microservice practice, discussing the challenges faced and the thinking behind the solutions.

What is microservice architecture? It follows the single‑responsibility principle and divide‑and‑conquer idea: a monolithic application is split into multiple services with clear responsibilities, independent deployment, and well‑defined boundaries. Benefits include faster development, clearer system boundaries, better scalability, and easier adaptation to change, while drawbacks involve duplicated work and new distributed‑system challenges.

How to adopt microservices? The process is divided into three parts: service decomposition, framework selection, and the public components that constitute the microservice platform.

1. Service decomposition – No fixed pattern exists; granularity must balance between too coarse (incomplete micro‑service) and too fine (high operational cost). Decomposition should consider business boundaries, service importance, and code reuse. Business‑driven splitting keeps logic cohesive; importance‑driven splitting separates critical services (e.g., video control vs. audit log); reusable logic is extracted into shared services such as a unified gateway.

2. Framework selection – The team evaluated several factors:

Legacy burden – most existing services are Spring MVC or Spring Boot, so Spring Cloud offers low migration cost.

Core requirements – HTTP (Spring Cloud) vs. binary (gRPC); they chose HTTP for higher development efficiency.

Framework maturity – Spring Cloud has rich documentation, community support, and a complete solution (service registry, load balancing, circuit breaking, tracing). Emerging service‑mesh solutions were deemed less mature.

Usage cost – learning curve, deployment overhead, and availability of shared components (e.g., Zipkin‑based tracing, Flume+ES+Kibana logging, Apollo configuration).

The final architecture is built on Spring Cloud, integrated with internal shared components, and deployed on iQIYI's private Docker‑based application engine (QAE).

3. Public components of the microservice framework include:

Service registry & load balancing (Eureka + Ribbon).

Distributed configuration center (Apollo) for centralized, dynamic config.

Unified gateway for routing, access control, and rate limiting.

Swagger for automatic API documentation.

Feign for declarative remote calls.

Hystrix for circuit breaking and fallback.

Containerized deployment (Docker) and cloud‑native practices.

CI/CD integration with QCI for one‑click build and deployment.

Centralized logging (Venus + ES + Kibana) and metrics monitoring (Prometheus, Kibana, Qiyi‑Eye).

Distributed tracing (Spring Cloud Sleuth + Rover).

Health checks and alerting.

Distributed consistency via message‑based eventual consistency.

Distributed rate limiting, locks, and scheduling (Redis, Zookeeper, XXL‑JOB).

Best‑practice summary – The team emphasizes improving efficiency and reducing cost by reusing common components throughout the service lifecycle, ensuring idempotency and retry mechanisms for remote calls, isolating resources to avoid contention, implementing comprehensive monitoring and visualization, and designing for high availability and self‑healing. They plan to keep exploring newer technologies such as service mesh, cloud‑native platforms, and domain‑driven design to further close the DevOps loop.