The Real Challenge of Microservices: Service Splitting and Building a Cloud‑Native Platform

Internet systems face demands from several angles: customers expect high app stickiness, good experience and uninterrupted service; business leaders want rapid feature iteration; and system builders aim to meet these needs while minimizing overtime.

Internet systems can be roughly divided into three categories: business systems such as websites and CRM, big‑data product systems, and distributed systems including big‑data engines, schedulers, storage, and messaging middleware.

The author considered unifying these under a data‑center‑style operating system for unified monitoring and governance, noting that many others are already pursuing similar ideas.

While microservice architecture is currently popular, the biggest difficulty lies not in technology but in business service splitting. Different organizations face varying challenges based on their business scenarios and legacy architectures.

Many startups initially focus on getting the business system running and later attempt to refactor, often ending up with outdated monolithic structures that become bottlenecks.

Before adopting microservices, the author spent time understanding the current business system landscape and aligning thoughts with stakeholders rather than designing a technical platform first.

The primary issue encountered was the granularity of service splitting. Splitting too finely creates a proliferation of services, making debugging, log aggregation, and exception handling much harder. The author’s approach is to first add services, then subtract by merging fine‑grained services based on importance, call frequency, and resilience, while avoiding overly coarse granularity that would reduce flexibility and stability.

Clear service relationships and API documentation are essential to reduce communication and maintenance costs. Designing one generic API (e.g., queryGoods ) that can handle diverse queries is preferred over creating a separate API for each requirement, which leads to API bloat and increased complexity.

Performance concerns about a single generic API are unfounded; API count does not directly affect latency because queries are decomposed and distributed on the backend.

The author proposes a plugin‑based microkernel architecture, using SPI to insert business plugins into the service core, making the system more flexible.

During service startup, each service registers its API topology metadata to the cluster, enabling clear visibility of API distribution. Combined with trace IDs, this allows easy tracing of horizontal and vertical call relationships. The author also envisions visualizing component architectures (e.g., Redis, MySQL) via JSON, enabling adjustments through a graphical interface that generates JSON for the cluster manager to automatically pull images, code, and reconfigure execution.

Future plans include extracting rules into a DSL and building a rule‑engine‑driven metadata management platform to achieve serverless, business‑centric development.

After establishing vertical and horizontal service boundaries, the technical capability platform is designed with four key requirements: transparent distributed capabilities, integrated operations monitoring, unified service governance, and unified infrastructure to prevent each system from maintaining its own distributed stack.

The chosen solution is CAAS (Container as a Service) based on Docker and Kubernetes. Docker minimizes differences between testing and production environments, simplifies deployment, and abstracts application‑level management APIs. Docker groups are abstracted as Service interfaces, hiding container details from callers and enabling one‑click deployment with CI integration.

Architecture topology is stored as metadata; the cluster manager can use JSON configurations to deploy, scale, shrink, shut down, or modify services automatically.

Kubernetes is selected as the CAAS platform, with detailed implementation to be covered in future articles.

The author also aims to integrate big‑data systems into the same platform while ensuring resource isolation through multi‑tenant capabilities, preventing resource contention between CPU‑intensive big‑data workloads and business services, and using distributed messaging such as Kafka for inter‑system communication.

Overall, the article shares practical insights and a roadmap for building a cloud‑native, microservice‑based internet system that balances business needs, technical feasibility, and operational efficiency.