Evolution of the Membership Testing Environment: From Manual Setup to Cloud‑Native Platform
To cope with over 100 million members, the membership testing environment progressed from manually configured VMs, through scripted Jenkins deployments, to a cloud‑native platform that centralizes resource allocation, automates routing and service registration, and provides one‑click diagnostics, dramatically lowering maintenance costs and achieving over 99 % stable deployment success.
Background : The membership business serves hundreds of millions of users. As the number of members exceeds 100 million, the testing environment becomes increasingly complex, with hundreds of basic services spread across dozens of domains. Core challenges include a large number of applications, intricate inter‑service call relationships, and routing‑based service discovery, all of which raise maintenance and debugging costs.
Key Characteristics :
Hundreds of basic services under many domains, leading to high maintenance cost.
Complex call dependencies between services, making joint debugging expensive.
Service discovery relies on routing and service registration, increasing locating difficulty.
Problems Encountered During Testing :
Inconsistent and personalized configuration for each application.
Shared test environments depend on various private servers, resulting in poor stability.
Unmanaged routing configuration makes fault isolation time‑consuming.
Unstable test‑infrastructure improvements lead to low effectiveness.
Stage 1 – Manual Phase : Fixed virtual machines were allocated for testing. Applications were manually packaged and deployed on these VMs. Port conflicts were avoided by maintaining a wiki of machines, applications, and ports. Problems included divergent dependency versions, manual nginx configuration, high operational effort, and the need for skilled personnel.
Stage 2 – Script Phase : Jenkins was introduced to automate deployment. Application metadata (code path, dependencies, build commands, start scripts) was stored in a MySQL database. A front‑end page allowed selection of application, branch, and target machine. Scripts handled dependency installation, server initialization, and application startup, providing version‑consistent, centralized management and reducing manual effort.
Stage 3 – Platform Phase (Cloud‑Native) : With the shift to micro‑services, containers, and cloud‑native architectures, a dedicated testing‑environment platform was built. The platform offers unified resource allocation, baseline environment deployment, centralized application management, and one‑click environment provisioning. It now supports hundreds of applications, hundreds of daily deployments, and achieves >99 % stable deployment success.
Key Business Pain Points Addressed :
Integrated test environments by domain, providing stable, CI, and business‑testing environments.
Dynamic routing management using nginx, with templates and Guardro integration to update upstreams automatically.
Registration‑center (Eureka‑plus) enhancements for automatic service registration and synchronization.
Intelligent environment issue locating by integrating SkyWalking and full‑link tracing (Rover/Atlas) to provide one‑click problem diagnosis.
Future Outlook : The testing environment will continue evolving from virtualization → containerization → cloud‑native, with further migration to cloud‑native platforms, aiming to reduce costs, improve efficiency, and maintain cutting‑edge capabilities.
iQIYI Technical Product Team
The technical product team of iQIYI
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.