QCon Technical Sharing: Alibaba Pandora Microservice Framework, 51 Credit Card Monitoring Platform, JD Akimed Service Platform, and Saga Distributed Transaction Solutions

The first session introduces Alibaba's "Pandora" service isolation framework, born from the need to manage numerous middleware dependencies in a monolithic Java ecosystem. It explains the evolution from all‑in‑one jars to API‑based microservices, the resulting dependency conflicts, and how Pandora uses a custom classloader to isolate middleware classes.

Problems with Pandora include cumbersome local development, extra JVM parameters, version mismatches, and project bootstrapping difficulties. The "Pandora boot" solution provides a Spring‑Boot‑like starter that generates a complete project skeleton, supplies lightweight middleware SDK stubs for compilation, and launches a custom classloader via PandoraBootstrap.run(args) to manage isolated loading at runtime.

The second session covers the 51 Credit Card microservice monitoring platform. It details the split between log pulling and event pushing servers, transformation of collected data into Prometheus‑compatible metrics, and storage separation using Cassandra for time‑series data and Elasticsearch for logs. Optimizations such as bitmap‑based metric keys and Druid pre‑aggregation are also described, along with intelligent alert diagnostics that retrieve surrounding logs and trace information.

The third session presents JD's Akimed microservice platform, featuring the JSF service framework for discovery and RPC (similar to Dubbo) and the ContainerMesh service mesh built on Istio. It explains how ContainerMesh abstracts registration, health checks, traffic control, and fault tolerance, enabling services to focus solely on business logic. Additional concepts include a unified call graph, an "Application Marketplace" for service cataloguing, and a "Capability Map" that visualises business flows across microservices.

The final session discusses a saga‑based distributed transaction solution implemented in the ServiceComb library. It outlines the saga pattern of forward events and compensating undo events, emphasizes that rollback must be coded manually, and highlights isolation via distributed locks. An example saga flow is shown: 1 saga start -> order create -> inventory deduct -> saga end Key references to academic papers on distributed sagas are provided.