Evolution and Cloud‑Native Architecture of Ctrip’s Microservice Products

Author Bio : CH3CHO, senior R&D manager at Ctrip, leads development of middleware products such as microservices and gateways, focusing on cloud‑native and microservice technologies.

Development Timeline : Ctrip’s microservice products began in 2013 with a .Net‑based framework built on ServiceStack (CServiceStack). In 2014 a Java counterpart, Baiji, and the first service registry were released, later evolving to the fourth generation. In 2017 Ctrip adopted Dubbo, creating the CDubbo framework (now at Dubbo 2.7.7). By 2020 the company started exploring Service Mesh solutions, which are now in production.

Product Complexity : Four main factors make the ecosystem complex – three different microservice frameworks run concurrently, both HTTP and Dubbo protocols are used, a fully self‑built infrastructure (registry and config center) is maintained, and there are over 8,000 services with more than 100,000 instances.

Key Challenges : Maintaining multiple similar middleware products consumes large effort; SDK‑based integration makes version upgrades difficult and creates long‑tail version problems; and limited language SDK support restricts usage for niche languages.

Cloud‑Native Architecture Design : To avoid a disruptive rewrite, Ctrip chose a “small steps, fast moves” strategy—ensuring full backward compatibility while enabling gradual migration. The design keeps the existing registry/config data authoritative, uses a custom SOA Operator to push that data into Kubernetes (K8s) as CRDs, and allows both HTTP and Dubbo traffic to be handled by Istio/Envoy sidecars. Zone‑level data convergence is preserved to reduce cross‑zone synchronization, and the architecture favors open‑source reuse (Istio, Envoy) over full in‑house development.

Service Mesh Details : Istio and Envoy provide the data plane; the SOA Operator translates registry/config models into K8s CRDs and synchronizes them back, enabling language‑agnostic access without SDKs. HTTP works smoothly, but Dubbo presents challenges: metadata location, serialization overhead, and custom protocols. Ctrip adopted Dubbo 3’s Triple protocol (HTTP/2‑based gRPC) with a wrapper that serializes POJOs to protobuf, adding a custom serializer to mitigate memory and GC pressure.

Future Trends : To improve usability for developers and operators, tighter integration between business needs and low‑level control data is required. Community projects such as Dubbo Mesh and OpenSergo are pursuing similar goals, aiming for a unified cloud‑native microservice governance standard and broader ecosystem coverage.