Ctrip’s Node.js Platform: Architecture, Deployment, Monitoring, and Public Services

In September 2017 Ctrip launched its Node.js applications, and over the past two years the company has built a comprehensive Node.js platform that supports large‑scale services.

1. Technology Stack – The deployment process follows four steps: Develop, Build, Release, and Publish. Development uses scaffolding and middleware; Build Docker compiles source code (including C++ modules) with caching; Release Docker runs lightweight containers; Publish performs health checks before exposing the service.

Version selection during the Build stage fixes Node.js to one of three LTS versions (v6.10.2, v8.9.4, v10.15.1) to ensure stable compilation environments, with pre‑compiled packages for Windows, macOS, and Linux.

The “front‑loaded build principle” encourages offline compilation of C++ modules, SOA/database configurations, and Babel/TypeScript to avoid runtime builds.

2. Operations & Monitoring – Node.js services run in Docker containers using an Nginx + PM2 cluster model. Key Docker metrics include CPU utilization, throttle count/time, memory RSS, HTTP request volume, and connection resets. PM2 provides per‑worker heartbeats (CPU, memory, network) sent to the CAT monitoring system.

Performance logs capture request latency, transaction duration, and cross‑service call times, while error/alert logs record application exceptions, HTTP errors, and version conflicts. Detailed data logs are added by developers for post‑mortem analysis.

The monitoring model evolved from flat logs to a call‑tree structure that links multiple transactions, facilitating root‑cause analysis.

Log troubleshooting often starts with rising Mem RSS values, indicating possible memory leaks; heapdump snapshots are compared in Chrome to pinpoint leaks, and discrepancies between Docker and heap metrics may reveal off‑heap issues.

3. Public Services – The platform provides SOA clients for Java/.NET/Node.js services, storage services (Ceph, Redis, Kafka), a shared‑memory cache middleware, and disaster‑recovery features such as connection retries, IP refresh, and multi‑IP fallback.

4. Application Scenarios – Data Aggregation (DA) layer reduces front‑end load by consolidating API calls, improving performance by ~20 %. Server‑Side Rendering (SSR) addresses SEO, first‑page latency, and code‑reuse across platforms, delivering ~30 % development efficiency gains and ~20 % performance improvement. Internal tools include build pipelines, Electron‑based GUIs, and static asset publishing.

5. Conclusion – After more than a year, Ctrip operates over 500 Node.js applications, focusing on middleware, performance monitoring, and future framework and engineering improvements to enhance stability and developer productivity.