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.
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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Ctrip Technology
Official Ctrip Technology account, sharing and discussing growth.
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.
