Evolution of CTrip's Microservice Framework: From Self‑Developed Service Framework to CDubbo and Service Mesh

This article details CTrip's journey from its early .Net‑based ESB architecture through a self‑developed Java microservice framework to the current CDubbo platform, covering registration, monitoring, dynamic configuration, protocol compatibility, performance gains, extensibility, and future Service Mesh integration.

Ctrip Technology
Ctrip Technology
Ctrip Technology
Evolution of CTrip's Microservice Framework: From Self‑Developed Service Framework to CDubbo and Service Mesh

Author: Haiyang, a CTrip technology expert interested in microservices, concurrent programming, and performance tuning.

CTrip began exploring microservices during its .Net era, later transitioning to Java, first building a self‑developed microservice framework and then adopting a high‑performance Dubbo implementation. The company now pursues Service Mesh to achieve full framework standardization and cloud‑native capabilities.

1. Past – Self‑Developed Service Framework

In the .Net era, CTrip used an ESB bus which suffered from single‑point failures that could cripple the entire network. Moving to a registry‑based SOA architecture distributed service calls and mitigated these failures.

While the current Java‑based framework is largely self‑developed, it faces challenges compared to open‑source high‑performance solutions.

2. Present – CDubgo Service Framework

CDubbo (C for CTrip governance, Dubbo for the Alibaba SDK) has evolved over two years, reaching nearly ten thousand service instances.

2.1 Registration & Discovery

Supports health‑check extensions, customizable heartbeat, and push‑pull subscription to ensure client‑side consistency and custom routing strategies.

2.2 Monitoring – CAT

Provides distributed tracing, aggregated reports, QPS, latency (including 99th percentile), and exception stack traces for rapid issue analysis.

2.3 Metrics

Dashboard aggregates global request volume, error counts, thread‑pool stats, and allows custom alarm rules based on data‑center, protocol, or serialization format.

2.4 Dynamic Configuration

Enables hot‑reload of configuration to avoid full redeployments, supports per‑method timeout overrides, and provides a visual UI for safe changes.

2.5 SOA Protocol Compatibility

CDubbo accepts SOA requests via Tomcat, reuses existing serializers, and maintains Dubbo internal routing, allowing both protocols to run without code changes.

2.6 Testing Platform

Utilizes the open‑source coreStone tool and Dubbo 2.7.3 metadata to provide a Postman‑like client supporting direct, local, and protobuf calls.

2.7 Dubbo 2.7.3 Upgrade

99% of CTrip services now run on Dubbo 2.7.3 with zero production incidents; remaining incompatibilities were caught at compile time.

2.8 Threadless

Threadless removes unnecessary client‑side threads, allowing shared thread pools and reducing thread count by 60‑70% under high QPS.

2.9 CDubbo Service System

Supports both Dubbo (TCP) and SOA (HTTP) protocols, works for internal and external gateways, and unifies configuration.

2.10 Performance

Dubbo protocol latency dropped from ~1 ms to ~0.3 ms; under 3‑4× traffic spikes, client error rate remained zero, and long‑connection multiplexing improved resilience.

2.11 Extensibility

Framework decouples business logic, allowing teams to extend routers, load‑balancers, and even transport layers to meet specific needs.

2.12 Ecosystem

Leverages open‑source Dubbo admin, Dubbo‑go, and other components to reduce learning and development costs.

2.13 Dubbo Protocol Issues

Challenges include poor gateway friendliness, lack of mobile SDKs, and potential interference when multiple services extend the same AOP cluster.

3. Future – Service Mesh

Standardization reduces R&D and learning costs; process decoupling enables independent middleware upgrades (e.g., Envoy); cloud‑native protocols like gRPC offer cross‑language support but require POJO‑compatible designs.

3.1 Service Mesh SDK

Considers a standardized SDK to bridge control‑plane (Istio) and data‑plane (Envoy/Sofa‑Mosn) components.

3.2 Existing Protocol Limitations

SOA's HTTP‑1.1 text protocol incurs high connection costs; Dubbo is not gateway‑friendly and has cross‑language challenges.

3.3 New Protocol

Explores gRPC as a cloud‑native standard while preserving POJO compatibility to avoid massive code rewrites.

3.4 Summary

Partial SDK standardization has been achieved; CTrip will continue accelerating its cloud‑native journey with faster, more stable, and standardized solutions.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendCloud NativeMicroservicesDubboService Mesh
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.