Why Microservices Matter: Core Principles, Benefits, and Architecture Explained

Hello, Microservices

Below you will see the core principles of mainstream microservice frameworks, including service discovery, gateway, configuration center, monitoring, and other components, with simple introductions to their functions and architectures.

What is Microservices

Martin Fowler, the "father" of microservices, describes microservices as an architectural style that splits a single application into a set of small, independently running services that communicate via lightweight mechanisms (usually HTTP RESTful APIs). Each service is built around a specific business capability and can be deployed independently, using the language and tools best suited to its context.

While there is no precise definition of this architectural style, it advocates dividing an application into small, cohesive services that run in independent processes, communicate via lightweight protocols, and can be deployed independently.

Key points from Fowler’s description:

Small, focused services

Independent processes

Lightweight communication (HTTP/REST)

Independent deployment

Technology‑agnostic per service

Small Service

A small service has no strict standard but must be limited in scope.

Independent Process

Each service runs in its own process, e.g., one on tomcat and another on jetty, allowing horizontal scaling.

Communication

Modern microservices favor lightweight communication (smart endpoints and dumb pipes) rather than heavyweight protocols like ESB or SOAP.

Deployment

Both business logic and deployment are independent, which changes traditional development workflows and introduces operational responsibilities.

Management

Microservices enable teams to choose their own technology stacks, reducing coupling and development costs compared to monolithic SOA services.

Pros and Cons of Microservices

Advantages include:

Highly cohesive, small codebases that focus on a single business function.

Simplified development and higher efficiency.

Small teams (2‑5 developers) can own a service.

Loose coupling and independent lifecycle.

Polyglot development (different languages per service).

Easy third‑party integration and CI/CD pipelines (Jenkins, Hudson, Bamboo).

Easy for a single developer to understand, modify, and maintain.

Business logic is separated from UI concerns.

Each service can have its own storage.

Overall, microservices reduce system complexity for large applications.

Drawbacks include data consistency challenges, testing complexity, and operational overhead in distributed environments.

Which Organizations Should Use Microservices?

Organizations that can benefit from microservices typically have communication structures that align with Conway’s Law: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway (1967)

Adopting microservices often requires cross‑functional teams (product, planning, development, operations) that expose functionality via APIs.

Microservice Technical Architecture

Below is a typical technology stack used by many companies.

Service Discovery

Three common approaches:

DNS‑based discovery – services are accessed via a domain name without built‑in load balancing.

Client‑side discovery with a registry (e.g., Spring Cloud) – services register themselves and clients poll the registry, providing built‑in load balancing.

External load balancer combined with client‑side discovery – improves on the first two methods but adds operational cost.

Gateway

What is a microservice gateway?

Analogous to a building’s security guard: it routes external requests to internal services.

Gateway functions

Reverse routing – hide internal services from external callers.

Security authentication – protect against malicious traffic.

Rate limiting and circuit breaking – prevent overload.

Logging and monitoring – capture request details.

Canary releases and blue‑green deployments – enable safe rollouts.

Zuul architecture

The core of Zuul is a servlet that passes all requests through a zuul servlet to a zuulFilter Runner, which dispatches to three filter types:

Pre‑routing filter – custom Java logic before routing.

Routing filter – determines the target microservice.

Post‑routing filter – handles logging and auditing after the response.

Configuration Center

Traditional configuration files embedded in code cause management problems. A configuration center centralizes configuration, supports versioning, and allows dynamic updates.

Popular open‑source solutions include Baidu Config, Disconf, Spring Cloud Config, and Ctrip’s Apollo (highly regarded).

Communication Methods

Two main remote‑call styles:

RPC : strong coupling, binary protocol (TCP), high performance, uses IDL such as Thrift or Protobuf.

REST : loose coupling, text‑based (HTTP/JSON), easier for multi‑language clients.

Monitoring and Alerting

Effective monitoring covers five layers: log monitoring, metrics, health checks, tracing, and alerting.

Monitoring architecture

Each service runs an agent that forwards logs to an ELK stack, metrics to InfluxDB, and events to a message queue for decoupling. Tools like Nagios can poll agents for health checks.

Tracing (APM)

Common tracing systems include Pinpoint, SkyWalking, Zipkin, and CAT. They instrument Java applications (e.g., Zipkin uses the Brave library) to collect spans and build distributed call graphs.

Circuit Breaking, Isolation, Rate Limiting, Degradation

Under high load, companies use Hystrix to implement:

Circuit breaking – automatically stop failing calls.

Isolation – prevent a failing service from affecting others.

Rate limiting – cap request volume.

Degradation – fallback to simpler functionality when thresholds are exceeded.

Hystrix workflow: a command checks the circuit, executes the call, and on failure or resource exhaustion triggers a fallback.

Containers and Orchestration Engines

Containers provide lightweight, isolated runtime environments compared to virtual machines. Docker is the most common container platform.

Container orchestration

Orchestration engines manage container lifecycles across clusters. Examples:

Apache Mesos – master/slave architecture with frameworks for resource allocation.

Kubernetes – widely adopted, with nodes running kubelet, pods containing containers, and kube-proxy handling networking and load balancing.

Service Mesh (to be updated)

Future content will cover service mesh concepts.

References

Martin Fowler’s description of microservices.

Conway’s Law and its impact on system design.

Tracing tools: Zipkin, Pinpoint, SkyWalking, CAT.