Challenges and Solutions in Service‑Oriented Splitting of Qunar Payment System

After introducing the evolution of Qunar's payment system architecture, this article discusses the challenges encountered during service‑oriented splitting, including development efficiency, interface conventions for Dubbo and HTTP services, concurrency and flow control, security checks, and unified monitoring.

For development efficiency, the article defines strict Dubbo interface contracts (granular interface definition, parameter standards, unified QResponse, business templates, and automatic documentation) and HTTP service conventions (command‑based parameter configuration, validators, and type definitions). Example command definition:

汇率查询接口
20150808
查询本币和目标币种汇率
本币
true
目标币种
true

Concurrency control can be achieved via cache‑based locking using a custom annotation, for example:

@RequestLock(
  lockKeyPrefix = "combdaikoupay:",
  lockKey = "${parentMerchantCode}_${parentTradeNo}",
  lockKeyParamMustExists = true,
  lockKeyExpireSecs = 5,
  lockUsedRetryTimes = 0,
  lockUsedRetryLockIntervalMills = 500,
  lockGotExIgnore = false)

Flow control is handled through QPS limits (node, cluster, interface) and parallel‑request thresholds, while security checks cover interface permissions and signature verification.

Unified monitoring aggregates interface call counts, response times, and error‑code statistics, and documentation is generated automatically from the command and validator metadata.

Managing multiple systems is achieved via templated monitoring for HTTP/Dubbo services, component‑level monitoring (Redis, Mybatis, Lock, QMQ, EventBus, DataSource, JobScheduler), and automated dashboard generation using Python scripts that require only system name and panel configuration.

Database handling topics include table partitioning (time‑based, hash‑based, or hybrid), multi‑database and multi‑instance strategies with a migration example that uses a read‑only replica and user switch before cutting over, and read‑write separation with load‑balancing to better utilize hardware resources.

Asynchronous processing leverages Servlet 3 async to free HTTP threads, QMQ for flexible messaging, and Dubbo for slow service responses. A typical flow: an HTTP request triggers a payment order, enters a polling loop that checks a cache for results, while the backend transaction system drives payment steps via QMQ and writes outcomes back to the cache.

Monitoring and alerting are addressed through a Java monitoring module (configurable metric emission), an offline Python‑based framework (components: metric_manager, graphite_sender, Dbpool, Scheduler), a data‑flow system built on XFlume, Kafka, Storm, HDFS, HBase, Redis, and Hive, and a comprehensive alarm strategy that distinguishes explicit failure alarms (NPE, DB slow query, HTTP 5xx, etc.) from calculated alarms based on deviation from expected values.

In summary, the payment system’s modularization into cash register, transaction, payment, gateway, accounting, core services, and monitoring has markedly improved its ability to handle high‑complexity and high‑concurrency workloads, though further refinements remain necessary.