Monolithic vs Microservice Architecture: Pros, Cons, Service Gateway, Registration, and Configuration Center

In the early days of web development most applications were built as a single monolithic package (often a WAR file) that ran inside one web container. This approach is simple to develop, test, deploy and scale horizontally when the application is small.

Easy development: IDEs fully support a single project.

Easy testing: all functionality runs in one process.

Easy deployment: just copy the built package to a server.

Horizontal scaling: add another node and deploy the same package.

However, as business complexity grows, monoliths become heavy, compilation and test cycles lengthen, and any change requires redeploying the whole system. Updating the technology stack often forces a complete rewrite.

Microservice architecture splits the application into many small, loosely‑coupled services, each running in its own process (e.g., a Spring Boot jar or a Node.js instance). Typical characteristics include:

Each service implements a specific business capability (order, user, product, etc.).

Services are independently deployable and can be written in different languages.

Communication is lightweight (HTTP or TCP) rather than SOAP.

Advantages of microservices:

Decomposes complexity, making each service easier to understand.

Allows independent teams to own services and choose technologies.

Supports independent deployment and faster iteration.

Enables independent scaling of hot services.

Disadvantages include increased operational complexity, the need for service discovery, handling distributed transactions, testing whole‑system behavior, and higher network latency.

Microservice Gateway

A service gateway (API gateway) provides routing, filtering, authentication, logging, data transformation, load balancing, and security for all incoming requests. It centralizes cross‑cutting concerns so individual services stay lightweight.

Typical implementation patterns for a feature like permission checking:

Each service implements its own permission logic (code duplication).

Extract permission logic into a shared library and let services depend on it.

Implement permission checking in a gateway filter: 权限校验 .

Using the gateway solves redundancy, reduces jar size, and allows changes without redeploying all services.

Service Registration and Discovery

In a microservice cluster, services act as providers and consumers. Providers register their address with a service registry (e.g., Eureka, Consul, Etcd) so consumers can discover them dynamically. Two registration models exist:

Self‑registration: each service registers itself on startup.

Third‑party registration: a service manager monitors running instances and updates the registry.

Consumers can query the registry directly (client‑side discovery) or go through the gateway (server‑side discovery).

Distributed Configuration Center

Traditional static configuration files suffer from environment coupling, scattered files, lack of real‑time updates, and no audit trail. A configuration center centralizes all parameters, separates configuration from code, supports real‑time push, versioning, and high availability.

Popular open‑source solutions include Apollo, XDiamond, QConf, and Disconf, each offering language‑agnostic clients and integration with Spring Cloud.

Conclusion

The article summarizes the trade‑offs between monolithic and microservice structures, introduces essential components such as service gateways, registration/discovery mechanisms, and configuration centers, and points out further topics like service monitoring, governance, circuit breaking, and degradation.