Redesigning JD's Java Service Framework (JSF) for a Cloud‑Native Microservice Platform

JSF, a Java‑based RPC framework widely used within JD, is encountering scalability and flexibility issues due to the explosive growth of microservices, containerization, mixed deployment scenarios, and the need for componentization and external empowerment.

The main problems identified are: an increasing number of dependent services and instances slowing startup; soft load‑balancing challenges; complex cross‑application call relationships and poor observability; mixed deployments requiring multiple registries; scattered service metadata increasing communication cost; lack of cross‑language support; insufficient traffic‑control mechanisms; and rigid security and upgrade processes.

Despite these challenges, JSF still supports tens of thousands of service interfaces, hundreds of thousands of JVM instances, and peaks of nearly four trillion calls during major sales events, demonstrating its robustness.

To address the issues, JD proposes a “microservice platform” organized into four layers:

Infrastructure Layer: Built on JDOS, JD’s container‑orchestration platform, providing a stable foundation for all JSF components.

Service Framework Layer: Includes the JSF SDK, the upcoming ContainerMesh service mesh, and the JSF Registry for service discovery, along with a new security system.

System Extension Layer: Offers advanced capabilities such as a microservice call graph for observability, flow‑control mechanisms, a configuration center supporting multiple formats, and enhanced monitoring integrated with UMP.

Application Layer: Introduces a “Service Marketplace” that centralizes service knowledge, enables search, provides a knowledge base, handles permission and quality tracking, visualizes call relationships, assesses resource usage, and supports interactive feedback.

The call‑graph subsystem provides source analysis, entry analysis, path analysis, latency analysis, bottleneck detection, and dependency analysis, helping to tame the “microservice explosion” and improve observability.

Flow‑control enhancements aim to support version‑aware traffic control, gray‑release and rollback, dynamic configuration, graceful service deprecation, forced degradation, and automated cleanup of unused interfaces.

The configuration center stores over 460 GB of key‑value, JSON, and properties data, offering a RESTful API for cross‑language, cross‑platform dynamic configuration.

Monitoring will be upgraded in partnership with the UMP team to provide fine‑grained, second‑level metrics.

Planned improvements to the JSF SDK include adding probes at encoding/decoding stages, exposing extension points for serialization and routing, developing a new TCP‑based protocol with handshake and security features, providing service‑related annotations, and allowing custom service attributes to enable logical grouping and coordinated lifecycle management.

To overcome language‑library limitations, JD is developing its own service mesh (ContainerMesh) that decouples business logic from communication and governance, enabling seamless multi‑language interaction while remaining compatible with existing JSF services.

JSF Registry, JD’s self‑built multi‑data‑center, cross‑WAN service discovery system, now reliably supports nearly 30 000 JVM instances and 3 000 000 service registrations.

The new security model assigns each service a globally unique UUID, enabling certificate management, key management, authentication, and fine‑grained authorization, with namespace and security‑level controls to balance flexibility and protection.