Deep Dive into JD.com Microservice Component Platform and Its Cloud‑Native Architecture

JD's microservice component platform is the underlying architecture platform for service calls, message notifications, operation management, knowledge sharing, collaboration, and service evaluation/diagnosis for all JD Group businesses.

This article invites JD microservice component platform technical experts to deeply analyze the platform.

First, the underlying architecture platform consists of three core communication technologies: JSFRPC calls, JMQ messaging service, and a service mesh, supporting both synchronous calls and asynchronous notifications, or a mix of both.

It is compatible with various popular communication protocols, supports cross‑language usage, and is suitable for online and offline scenarios, handling almost all backend communication traffic for JD, ensuring efficient and stable operations.

JD Technology Salon, organized by the Enterprise Informatization Department and JD University, shares cutting‑edge technology results and hot topics monthly, building a tech exchange platform, resource sharing, and solving work pain points.

This article is based on the sharing content, edited to deliver key points.

JD Microservice Platform Overview

In IDE tools, a microservice design plugin based on DDD theory provides PowerDesigner‑like functions, automatically checking designs against DDD principles for “supervised design”.

It also offers code generation by scanning code and comparing it with the design to ensure consistency, aiming to end the lack of tool support in microservice design and improve overall design quality.

Through a custom tag mechanism, interfaces and applications can be defined with multi‑dimensional tags such as component type, permission, department, system capability, business layer, and business ability, bringing the jsf system closer to business scenarios and enabling personalized operations previously impossible.

JD currently has over 30,000 microservices; a service evaluation mechanism ranks services for two purposes: service grading and improvement.

Service grading is used during resource allocation for events like 618 and Double 11, allocating resources based on service level to address resource scarcity.

Improvement uses high‑ranked services as best‑practice examples, while low‑ranked services receive remediation suggestions to raise overall quality.

Currently jsf is based on a Java stack delivered as an SDK, with two major issues: 1) poor cross‑language support as new tech areas (AI, blockchain, IoT) use languages like Python, Go, C++; 2) transparent upgrades are difficult because SDK binding impacts business.

Additionally, jsf lacks good support for gRPC, circuit breaking, fault injection, etc. By adopting service‑mesh technology, RPC communication and service governance are decoupled from business logic, both at compile time and runtime, fully compatible with existing Jsf services.

JD's service mesh, called “ContainerMesh”, has three parts: the infrastructure layer (defines, assembles, prepares environment, and publishes applications; the first phase focuses on JDOS), the data plane (handles protocol codec, serialization, and service governance such as circuit breaking, fault injection, traffic splitting), and the control plane (receives user configuration, passes it to the data plane to execute actions like error injection for fast failure).

The data plane's Envoy takes over local service traffic within a pod (e.g., via iptables), queries the control plane (Jpilot) for target service instance information (IP/port) to know how to access it.

The control plane Jpilot obtains the service list from the jsf registry, waits for Envoy queries; Envoy communicates with the jsf registry for service registration and heartbeat.

JD currently has over 30,000 microservices with complex dependencies, leading to a “microservice explosion”.

JD's distributed tracing system (CallGraph) follows Google Dapper principles, providing zero‑intrusion delivery and cross‑network call‑stack analysis, allowing a macro view of business relationships and a micro view of call‑chain details, offering comprehensive profiling to solve observability problems after the microservice explosion.

JD already has JOS, Jingmai, and Kepler systems based on API‑gateway technology serving external customers such as merchants and Toutiao.

These products share a powerful API gateway; the microservice platform plans to launch its own API‑gateway framework to better support these products.

The platform aims to become a “self‑evolving” system with three evolution aspects: (1) service knowledge evolution to improve precision and purity; (2) service quality evolution to raise overall level; (3) component evolution to foster more and better components for external enablement.

The platform will provide a suite of ecosystem toolchains to improve developer efficiency for distributed applications, focusing on distributed transactions, distributed locks, and online debugging.

Jsf's current technical route forces developers into an all‑or‑nothing heavy stack.

In contrast, the open‑source Spring Cloud (with Netflix plugins) leverages Spring Boot to provide a lightweight, plugin‑based approach where developers can pick specific plugins such as Eureka for service discovery and Hystrix for circuit breaking.

The microservice platform intends to use Spring Boot to refactor jsf into a plugin‑based usage, increasing flexibility in technology selection. In the sharing session, Mr. Zhang discussed several hot questions.

Q: How to reduce dependencies between microservices? A: Over‑dependence indicates design issues; it is strongly recommended to study Domain‑Driven Design (DDD), which systematically describes domain modeling concepts such as aggregates, aggregate roots, bounded contexts, services, and repositories. Proper DDD leads to services that are highly cohesive internally and loosely coupled externally.

It can be said that services designed with DDD are “highly cohesive inside, loosely coupled outside”.

As business scales, dependency problems may reappear; continuously refining domain models according to DDD keeps conceptual consistency with business, preventing excessive dependencies.

Q: Design considerations for new systems adopting microservices. A: It is recommended to first adopt a “big‑stone” (monolith) approach for rapid launch. Do not start with microservices unless the team has experienced developers. Rapid development and launch are primary concerns.

The domain model establishment and evolution need time; after fully understanding the problem domain, transitioning to microservices is acceptable.

Q: In microservice architecture, should services be unified across endpoints, and how to handle transactions when multiple services compose a business function? A: Frontends may add a backend‑for‑frontend layer to shield underlying services, centralizing logic, applying uniform controls (e.g., timeouts), and aggregating services, especially when jsf’s cross‑language support is weak. However, this layer can become a performance bottleneck; consider removing some services from it and let frontends call underlying services directly, provided SLA requirements are met through technical communication.

Q: How to decide if a system should be split into microservices and what dimensions to prioritize? A: Consider (1) whether the team has suitable microservice talent; (2) whether the business domain model is fully mastered. Advantages of microservices over monoliths include clear service boundaries, single responsibility, loose coupling, independent development/deployment/maintenance, high cohesion, easy extensibility, and freedom to choose the best technology stack per problem.

Q: When service count grows large across departments, how to manage complexity, find needed services, and document effectively? A: Large scale leads to “microservice explosion”. JD's CallGraph system provides zero‑intrusion tracing to view macro and micro call relationships, solving observability issues. The “service marketplace” offers search across all JD services with advanced filters, acting as centralized documentation.

JD Technology ∣ Follow the tech public account

Long press, recognize QR code, and follow