Microservice Splitting Strategies: Perspectives and Practices

Microservices are a conceptual paradigm without a precise definition or boundaries, similar to design principles, so any division strategy is context‑dependent and should be used as a reference rather than an absolute standard.

Pose 1 – Expert Hu Zhong's Simple Vertical and Horizontal Split

Vertical split : Divide by business domain; tightly related business functions stay together, while relatively independent functions become separate services.

Horizontal split : Divide by common, independent functionalities that are used by multiple services and have independent resources.

Pose 2 – Comprehensive Dimensions (Business Need, Maintenance Cost, Team Organization, Scalability, Release Frequency)

Consider business independence and professionalism, avoid defining service boundaries by team to prevent “land‑grab” conflicts; keep maintenance cost (people, resources, time) lower than before splitting; ensure each service is owned by a relatively independent team; improve system scalability by separating services with different scalability requirements (e.g., full‑text search); and apply an 80/20 principle to isolate frequently changing parts for independent deployment.

Pose 3 – Senior Architect Li Yunhua's Multi‑Facet Split

Based on business logic : Group responsibilities with the same business scope into a single service.

Based on stability : Separate stable, rarely‑changed modules from unstable, frequently‑changed ones (e.g., logging, monitoring).

Based on reliability : Cluster high‑reliability core modules together and low‑reliability non‑core modules together, reducing the risk of a single failure affecting the whole system.

Based on performance : Isolate high‑performance demanding modules (e.g., search, flash‑sale) into dedicated services.

Pose Summary

All approaches prioritize business logic first.

Stability, reliability, functional independence, and scalability are viewed similarly across methods.

Splitting should be multi‑choice, not a single rule; analysis must be flexible and context‑specific.

Side Note – Dealing with Conflicts and Team Size

Different granularity choices (e.g., 3 services vs. 6 services) depend on team size; a rule of three developers per service is suggested as a stable baseline, though it may vary over a project's lifecycle.

Original source: https://www.cnblogs.com/jackyfei/p/10856427.html