Technical Overview of JD's Open Platform: High‑Performance API Gateway and Reliable Messaging Service

JD's Open Platform (Jingmai) serves as a multi‑terminal, open‑architecture platform for JD merchants, providing both mobile and desktop operational capabilities and allowing ISVs to deliver diverse applications.

The high‑performance API gateway is built to expose internal services (order, product, merchant centers) via the Jingdong Service Framework (JSF) and OAuth2‑protected HTTP JSON interfaces, handling massive 618‑day traffic with layered request interception, defense checks (degradation, rate limiting, caching), and dynamic service routing.

To avoid the performance bottleneck of database‑based metadata reads, the gateway adopts a ZooKeeper‑based unified configuration with multi‑level caching (ZooKeeper, memory, local file) that supports instant synchronization on data changes and automatic disaster recovery when ZooKeeper or the network fails.

The TCP gateway establishes full‑duplex long‑connection sessions using Netty. Each TCP connection is wrapped in a Session object stored in a Container, enabling micro‑service‑style calls and simplifying connection‑oriented programming.

Because mobile clients often experience network jitter, the platform implements a heartbeat‑based session liveness check (5‑minute interval) and a reconnection strategy that reuses previous Session IDs when possible, while also handling cases where reconnection lands on a different server.

To reduce payload size compared with JSON, the TCP gateway uses Protocol Buffers (Protobuf) for data exchange, supporting Java, Objective‑C, and C++ and enabling PC, iOS, and Android clients to communicate efficiently.

Multi‑dimensional flow control is achieved with a token‑bucket algorithm implemented via Guava RateLimiter, combined with a ZooKeeper‑distributed configuration that allows dynamic adjustment of rate limits without restarting services. Per‑method concurrency limits are enforced using JDK Semaphores.

The platform also provides a highly reliable message service. Instead of polling, it pushes real‑time notifications through an asynchronous, fully decoupled pipeline built on Netty, ElasticSearch, and HBase, supporting both “half‑push half‑pull” (notification + client pull) and “half‑push half‑query” (notification only, content fetched on demand) models.

Message confirmation is handled by assigning a unique sequence number (seq) to each outbound notification and storing it in a cache; if the client does not acknowledge within a 10‑second timeout, the message is automatically retransmitted.

For iOS, the legacy socket‑based APNs integration was replaced with a Netty‑powered HTTP/2 push service that supports both synchronous and asynchronous delivery, maintains long‑lived connections via IdleStateHandler, and gracefully handles channel inactivity and reconnection.

In summary, the evolution of JD’s open platform highlights the importance of service governance and ecosystem‑level architecture, enabling continuous improvement of operational capabilities across massive traffic spikes.