Qunar Travel Microservice Architecture Practice

Background

Qunar Travel is an online travel platform offering flights, hotels, trains, and other services. Rapidly expanding business complexity and organizational growth prompted a shift from a simple flight‑price comparison system to a full microservice architecture to improve development efficiency, service quality, and operational alignment.

Key drivers for adopting microservices include increasing business complexity, Conway's law‑induced organizational expansion, low development efficiency caused by tightly coupled HTTP/JSON logic, and fragmented service governance that hindered reliable operations.

Current scale: >3,000 active services, >18,000 Dubbo RPC interfaces, >3,500 HTTP domains, >13,000 MQ topics, and a polyglot stack primarily using Java and Node.

Best Practices of Microservice Architecture

1. Service Discovery Patterns

Three discovery modes are described:

Direct mode – clients fetch service lists from a registry and cache locally; suitable for homogeneous internal RPC communication.

Proxy mode – services register to a gateway, hiding endpoints from clients; fits external services but adds an extra hop.

Sidecar mode – a sidecar handles registration and discovery, ideal for multi‑language, multi‑protocol environments.

2. Service Communication Modes

Synchronous programming is simple but inefficient for high‑throughput scenarios; asynchronous communication (e.g., using MQ) reduces resource waste and is preferred for high‑QPS workloads such as search and transaction systems.

Qunar built an internal asynchronous HttpClient wrapper and enhanced Dubbo's async capabilities to improve performance and observability.

3. Protocols

Three main protocols are used: a proprietary protocol for App‑to‑gateway traffic, HTTP for gateway‑to‑Node/Java communication, and Dubbo for most backend Java‑to‑Java RPC.

4. Design Patterns

BASE (availability over strong consistency) and CQRS (command‑query responsibility segregation) are applied where appropriate, especially for heterogeneous data and high‑concurrency scenarios.

Improving Development Efficiency

Qunar evaluated Spring Cloud and its Alibaba extensions (Nacos, Sentinel, Dubbo, RocketMQ) and built a unified "Spring Cloud Qunar" platform that integrates configuration, registration, and governance components.

Two communication modes are supported:

Direct SDK‑based mode.

Sidecar‑based Mesh mode, enabled via a @QunarMesh annotation for both Dubbo and HTTP services.

An IntelliJ IDEA plugin automates service call code generation, documentation lookup, governance parameter injection, code‑style enforcement, CI/CD left‑shift, and coverage reporting, dramatically reducing repetitive manual work.

Service Governance Practices

Standard four‑pillar governance (timeout, retry, circuit‑breaker, rate‑limit) is refined with dynamic quota allocation based on business value, protecting critical traffic while throttling low‑value requests.

A protection mechanism caches provider lists when the registry becomes unstable, preventing mass service outage during partial registry failures.

ServiceMesh Exploration

Background & Technical Selection

Given a multi‑language, multi‑protocol environment, Qunar evaluated Envoy (C++) and Istio but chose MOSN (Go‑based) for data plane and Istio for control plane, extending both with custom components (mcpServer, config/registry services).

Models

Registration model abstracts service‑instance semantics to unify Dubbo and HTTP registration. Configuration model uses custom storage formats converted to Istio XDS via MCP. Routing model relies on application‑environment pairs and trace‑based matching to satisfy most business needs.

Control & Operations

Custom components handle configuration, sidecar deployment, gray‑release, health‑checking, and observability. Performance optimizations include compile‑time collection of Mesh annotations and Unix Domain Socket (UDS) communication to reduce sidecar overhead.

Conclusion

The practice highlights four key takeaways: choose appropriate discovery and communication patterns; adopt proven architectural styles like BASE and CQRS; prioritize development efficiency with tooling and platform integration; and implement robust, business‑aware governance (dynamic limiting, protection mechanisms) while evolving toward ServiceMesh as the next‑generation communication layer.