Reflections on Software Service Architecture: From Three‑Tier to Microservices and High Concurrency

After postponing for a long time, the author finally writes a blog to share personal reflections on software service architecture.

Three‑Tier Architecture

Since university, the three‑tier model has been taught and widely used in projects. It works well for small, simple applications because it enables rapid iteration. However, as projects grow, the monolithic three‑tier structure becomes a liability: high cohesion and high coupling cause maintenance headaches, namespace conflicts, and difficulty scaling development teams. The natural solution is to split the system into services, i.e., adopt microservices, which also eases team management.

Microservice Architecture

Microservice granularity can be fine‑grained or coarse‑grained. In fine‑grained designs (Figure 1), services are very small and cross‑database calls are prohibited, forcing the business‑logic layer to orchestrate many RPC/REST calls, which hampers rapid development. In coarse‑grained designs (Figure 2), each service exposes a broader interface, cross‑database access is allowed, and services are high‑cohesion, low‑coupling, enabling independent teams to develop features like order processing without waiting for other services.

Microservices also improve resource utilization, reducing infrastructure costs.

High Concurrency

When concurrency grows, the optimization path is similar for both three‑tier and microservice systems: read/write separation → caching → sharding (using middleware such as Sharding‑JDBC, Macat, Atlas, etc.).

Refactoring for High Concurrency

The author presents a simple refactoring example: a project with two packages, Product and Membership . The ProductController currently depends on UserService from the Membership package. By enforcing a rule that packages cannot depend on each other, the needed user‑related logic is moved into the Product package, allowing the Product package to be packaged as an independent JAR for service extraction without affecting future sharding.

When business complexity increases, even a coarse‑grained architecture may encounter issues, such as multiple services modifying the same inventory data. In such cases, a finer‑grained design with well‑defined domain boundaries (as advocated by DDD) becomes necessary.

Source: http://www.cnblogs.com/DKSL/p/9225178.html

Copyright notice: Content is sourced from the internet; rights belong to the original author. We will remove it if any infringement is reported.