Node.js Engineering Practices at Ctrip: From Zero to One, Best Practices and Operations

Author : Pan Feifei, Senior R&D Manager at Trip.com, sharing experiences from the 2019 Ctrip Technology Summit.

The article introduces how Ctrip adopts a Node.js technology stack from zero to production, covering two main user‑facing directions (Data Aggregation services and Server‑Side Rendering) and internal desktop tools built with Electron.

1. Node.js Engineering

Ctrip has established a comprehensive engineering workflow consisting of five stages: development, build, test, release, and operations.

1.1 Development

Three types of scaffolds are provided—Web Application, DA Service, and Desktop Tools—each with standardized Docker logging and pre‑configured middleware. Differences such as UI layers for desktop tools or health‑reporting for DA services are handled by the scaffolds.

1.2 Core Middleware

The platform includes more than 20 middleware components, notably:

Storage Service (Ceph client) for long‑term static assets.

Business Service (SOA Client/Service) for DA scenarios, focusing on read performance, fault tolerance, stability, and response time.

Monitoring Service offering tracing, metrics, and logging.

Common Service (configuration center, ABTest client, data access layer).

Cache Service (Redis client and shared memory).

1.3 Build

To control costs, Ctrip maintains two stable Node.js Docker images. Dependency installation is accelerated by pre‑compiling native C++ modules for Windows, Linux, and macOS. Dependency scanning detects version conflicts and security issues early in the build pipeline.

1.4 Test

Testing includes unit, integration, stress, and automated UI tests (Puppeteer). Every code change triggers the automated test suite to ensure quality.

1.5 Release

Releases are unified across Ctrip Cloud and public clouds, abstracting environment differences. An integrated one‑click release bundles framework, static assets, and configuration. Private npm packages are tightly coupled with Git for traceability, permission control, and rollback.

1.6 Operations

Operations focus on three monitoring dimensions:

Tracing – request‑level data such as headers, status, latency, and call chains.

Logging – event‑level records, including errors.

Metrics – aggregated data like CPU, memory, HTTP traffic, and connection resets.

Key operational practices include using flame graphs for rapid troubleshooting, heartbeat reporting from each worker to the CAT data center, and detailed performance, error, and data logs for post‑mortem analysis.

2. Node.js Best Practices

2.1 Deployment Model

Node.js services run in Docker containers behind Nginx and are managed by PM2 in cluster mode.

2.2 Issue 1 – Multi‑Process Communication

Version 1 used an IPC‑based master‑slave model, which suffered from data size limits, latency, and master single‑point failure. Version 2 switched to shared memory, allowing lightweight, fast data sharing across processes.

2.3 Issue 2 – Monitoring Content

Nginx monitors host‑level metrics (CPU, memory, HTTP traffic, connection resets). Application‑level metrics are collected via PM2 clusters, including heartbeat (CPU, memory, network), performance timings, error/alert information, and detailed data logs.

2.4 Issue 3 – Full‑Link Tracing

Full‑link tracing captures end‑to‑end request flows. Initial implementation used the domain module; the current approach leverages async_hooks to propagate context via executionAsyncId and triggerAsyncId, enabling precise request correlation.

3. Summary

Node.js engineering must be continuously refined to match business needs.

Design robust operational metrics combining tracing, logging, and metrics.

Monitor post‑deployment indicators to prevent memory leaks.

Identify stack‑specific challenges and address them with targeted solutions.

Choose the right technology rather than blindly following trends.

For the full PPT, reply “nodejs” to the Ctrip Technology Center WeChat public account.