Microservice System Classification, Evolution, and Governance Practices

1. System Classification and Evolution

1.1 System Classification

Based on functionality, the systems can be divided into three categories:

Interface service systems provide external APIs such as JD's custom RPC framework (JSF), HTTP interfaces, and Hessian interfaces. Write interfaces must ensure idempotency and anti‑scraping measures, while read interfaces are naturally idempotent.

Web page systems serve user‑facing pages; data displayed on a page may originate from multiple sources, requiring decisions on data merging and consistency.

Task systems include statistics, data synchronization, etc. They need to consider whether tasks are hot‑standby or cold‑standby, distributed scheduling, resource allocation, and computational accuracy.

1.2 System Evolution

The architecture has evolved from early monolithic systems to the current microservice‑oriented architecture, bringing new challenges in service governance such as network latency, distributed transactions, and asynchronous messaging.

2. Purpose of the Review

Before major sales events like 618 and Double‑11, a comprehensive review of all systems is conducted to identify weak points. By focusing on the most critical (golden) functions and applying the 80/20 principle, resources can be concentrated on the most impactful areas, while less critical components may be handled via throttling or degradation.

3. How to Conduct the Review

The review proceeds from a high‑level view of system functions to a detailed analysis of each core function’s workflow, pinpointing strong and weak dependencies. Strong dependencies require disaster‑recovery plans; weak dependencies can be degraded gracefully.

3.1 Interface Service Systems

Identify all provided service interfaces and mark the golden ones. Golden interfaces must remain available; ensure this through multi‑zone Redis clusters, redundant deployments, and other high‑availability measures.

3.2 Web Page Systems

Critical pages such as the homepage, category listings, navigation, and ad slots must never be empty. Each area should have multi‑level caching and fallback data to guarantee content display.

3.3 Task Systems

Task systems require distributed workers without single points of failure. Solutions may involve Zookeeper‑based scheduling, custom implementations, or open‑source frameworks like Elastic‑Job.

All three system types have already been micro‑service‑ified; the review therefore focuses on communication dependencies, distinguishing strong from weak dependencies.

3.4 Core Function Process Review

After identifying golden functions, map their end‑to‑end processes, marking key nodes. Strong dependencies (highlighted in deep yellow) must have disaster‑recovery plans; weak dependencies (light green) can be degraded.

4. Summary

The article presented system classification, architectural evolution, and process mapping with the ultimate goal of uncovering golden functions and golden processes, and distinguishing strong from weak dependencies. By ensuring strong dependencies have robust disaster‑recovery solutions, the organization can confidently handle system evolution and large‑scale events such as 618 and Double‑11.