Understanding Monolithic and Microservice Architectures: Benefits, Drawbacks, Service Gateway, Registration, and Configuration Center

Part 1 – Introduction

As internet business complexity grows, monolithic services face productivity problems; microservice architecture brings both benefits and challenges that must be investigated before adoption.

Part 2 – Monolithic Architecture

What is a monolith?

Early web applications packaged all functional modules into a single WAR file and ran in one web container.

Advantages include simple IDE support, easy local testing, and straightforward deployment of a single package.

However, these benefits only hold when the application is not complex.

Large, complex applications become cumbersome: any change requires redeploying the whole system, leading to long compile times, lengthy regression testing, and reduced development efficiency.

Updating the technology stack often requires a complete rewrite.

Monolith Pros

Easy development : simple IDE support and debugging.

Easy testing : all functions run in one process.

Easy deployment : deploy a single package.

Horizontal scaling : add a new server node and deploy the same package.

Monolith Cons

High maintenance cost : communication and management overhead increase with team size and feature count.

Long continuous delivery cycles : build and deployment times grow with features.

Long onboarding for new developers : understanding the whole system takes time.

High technology selection cost : changing frameworks requires rewriting the whole system.

Poor scalability : vertical scaling becomes expensive and horizontal scaling is limited because all code runs in one process.

Part 3 – Microservices

What is a microservice?

In a microservice architecture, business logic is split into many small, loosely coupled distributed components, each called a microservice, which performs a specific task and may be called by other services.

Microservice Summary

Small services (size defined by team understanding).

Independent processes (e.g., Tomcat, Node.js).

Lightweight communication (HTTP or TCP, not SOAP).

Business‑oriented capabilities (order service, user service, etc.).

Independent deployment for fast iteration.

No centralized technology stack; each service can choose its own stack.

Microservice Pros

System decomposition : breaks a huge monolith into manageable services.

Divide‑and‑conquer management : each service can have its own dedicated team and technology.

Simplified deployment and scaling : services are deployed independently and can be scaled individually.

Microservice Cons

Size limits on splitting : services should remain small; over‑large services defeat the purpose.

Increased coding complexity : distributed systems introduce RPC or messaging, error handling, and latency concerns.

Data storage challenges : each service may have its own database, making distributed transactions difficult.

Testing complexity : end‑to‑end tests must start all dependent services or use stubs.

Impact of changes : a change in one service may affect multiple others, requiring coordinated deployments.

Network bandwidth impact : inter‑service RPC calls are sensitive to latency and bandwidth.

Part 4 – Microservice Gateway

What is a service gateway?

A service gateway equals routing + filters .

It performs routing, security authentication, rate limiting, logging, data transformation, and more.

Why need a gateway?

Many microservice nodes would otherwise duplicate cross‑cutting concerns (auth, session, logging).

Centralizing these concerns in a gateway reduces code redundancy and complexity.

Gateway Design Options

Solution 1 : each service implements its own auth code – leads to redundancy.

Solution 2 : extract auth into a shared library – increases jar size and upgrade difficulty.

Solution 3 : implement auth in a gateway filter – avoids code duplication and simplifies upgrades.

Gateway Functions

Routing : forwards external requests to appropriate microservices, integrates with service discovery for dynamic routing.

Load balancing : distributes traffic based on instance load, can apply rate limiting or circuit breaking.

Security authentication : validates identity before forwarding requests.

Logging : records request logs for monitoring and troubleshooting.

Data conversion : normalizes different client payloads before passing to services.

Open‑source Gateway Implementations

Zuul (Netflix, Java, Spring Cloud integration)

Tyk (Go, lightweight, fast, supports quotas, authentication)

Kong (Nginx‑based, high performance, plugin ecosystem)

Traefik (modern reverse proxy, auto‑configures with Docker, Kubernetes, etc.)

Ambassador (Envoy‑based, integrates with Istio, Kubernetes ingress)

Part 5 – Service Registration and Discovery

Why need registration?

Microservice providers and consumers must know each other's addresses; a registration center automates this and supports load balancing.

Registration Mechanisms

Self‑registration : services register themselves on startup.

Third‑party registration : a service manager probes running services and updates the registry (e.g., Eureka).

Discovery Modes

Client mode : consumers query the registry and call services directly (may implement their own load balancing).

Proxy mode : consumers call an API gateway, which handles discovery, routing, and load balancing.

Open‑source Service Discovery

Eureka (Netflix, Spring Cloud integration)

Consul (language‑agnostic, external probes)

Etcd (distributed key/value store, often combined with other tools)

Part 6 – Distributed Configuration Center

What is a configuration center?

A centralized system for managing all configuration items, separating configuration from code, supporting real‑time updates, versioning, and high availability.

Why need it?

Static files are hard to modify and require restarts.

Separate environments (test, pre‑prod, prod) need distinct configs.

Configuration files become scattered across modules.

Changes are not traceable.

Features

Centralized management and standard interfaces.

Configuration‑application separation.

Real‑time updates.

High availability.

Open‑source Configuration Centers

Apollo (Ctrip, Spring Boot/Cloud, multi‑language clients)

XDiamond (Taobao Diamond fork, global config store)

QConf (distributed config, real‑time sync)

Disconf (generic component used by many Chinese internet companies)

Part 7 – Summary

The article compares monolithic and microservice structures, outlines the design of microservice gateways, explains service registration/discovery, and introduces distributed configuration centers, while noting further topics such as service monitoring, governance, circuit breaking, and degradation.