What Are Microservices? Core Concepts, Challenges, and Popular Solutions

What Is a Microservice?

Microservices are a software‑architecture style that splits a large application into a set of small, autonomous, loosely‑coupled services, each responsible for a specific business capability. They can be developed, deployed, and scaled independently, improving flexibility, scalability, and maintainability.

The typical evolution path is Monolithic → Service‑oriented → Microservices.

Why Microservices Introduce New Challenges

Adopting microservices adds complexity in several dimensions:

System complexity grows as many services must communicate, be deployed, monitored, and maintained.

Network and serialization overhead increase latency and can become performance bottlenecks.

Data consistency and distributed transaction management become harder because each service owns its own data store.

Deployment and operations require sophisticated pipelines, health‑checks, and fault‑tolerance mechanisms.

Team coordination costs rise; each service often has a dedicated team, demanding clear communication channels.

Service governance (registration, discovery, load‑balancing, monitoring, fault handling) becomes more complex.

Distributed‑system concerns such as network partitions, consistency, and resilience must be addressed.

Therefore, microservices should be chosen only when the benefits outweigh these costs.

Popular Open‑Source Microservice Solutions

The three mainstream stacks are:

Dubbo – a high‑performance, lightweight Java RPC framework originally from Alibaba, supporting multiple protocols (TCP, HTTP, Redis) and serialization formats (JSON, Hessian, Protobuf). It relies on external components like ZooKeeper or Apollo for service governance.

Spring Cloud Netflix – a collection of Netflix OSS projects (Eureka, Ribbon, Hystrix, Zuul, etc.) integrated with Spring Cloud. Netflix stopped maintaining many of these components after 2018, so the stack is in maintenance mode.

Spring Cloud Alibaba – a Spring Cloud sub‑project that integrates Alibaba’s ecosystem (Nacos, Sentinel, RocketMQ, etc.). It provides a complete set of components for service registration, configuration, traffic control, and monitoring.

Key differences (as shown in the original table) include governance features, supported registries, load‑balancing strategies, RPC mechanisms, circuit‑breaker implementations, configuration centers, API‑gateway options, distributed‑transaction support, rate‑limiting, tracing tools, mesh capabilities, community activity, and maturity.

Microservice Core Components

Typical components and common implementations:

Service Registry : Eureka, Consul, ZooKeeper, Nacos – manage service address metadata for discovery.

Configuration Center : Spring Cloud Config (Git/SVN), Nacos Config, Apollo, etc. – centralize configuration CRUD.

Remote Call : RESTful APIs (Feign, RestTemplate) or RPC frameworks (Dubbo, gRPC).

API Gateway : Zuul, Spring Cloud Gateway, Kong, APISIX – route, load‑balance, secure, and monitor inbound traffic.

Load Balancing : Algorithms such as Round‑Robin, Weighted Round‑Robin, Random, Weighted Random, Least Connection, and Hash.

Circuit Breaker / Fallback : Hystrix (deprecated), Resilience4j, Sentinel – prevent cascading failures.

Rate Limiting : Sentinel (token‑bucket sliding‑window), custom rules via configuration.

Tracing : Zipkin, Jaeger, SkyWalking, Pinpoint – visualize request flows across services.

Distributed Transaction : Seata (AT, TCC, SAGA, XA modes) – coordinate multi‑service data consistency.

Monitoring & Alerting : Prometheus + Grafana for metrics; ELK (Elasticsearch, Logstash, Kibana) for log aggregation.

Service Registry Deep Dive

A registry stores service instances and enables service discovery and service registration. Typical functions:

Service Registration : Instances publish host, port, and metadata on startup.

Service Discovery : Clients query the registry to obtain healthy instances.

Load Balancing : Clients can round‑robin or apply other algorithms based on the instance list.

Failure Recovery : Registries monitor health and remove dead instances.

Governance : Dynamic scaling, routing, and gray releases are driven by registry data.

Spring Cloud can integrate with Eureka, Consul, ZooKeeper, Nacos, and etcd.

Eureka vs. ZooKeeper vs. Nacos

Developer : Netflix (Eureka), Apache Foundation (ZooKeeper), Alibaba (Nacos).

CAP Model : Eureka – AP; ZooKeeper – CP; Nacos – supports both AP and CP.

Features : Eureka focuses on registration/discovery; ZooKeeper provides coordination, configuration, and locks; Nacos adds configuration management and service management.

Protocol : HTTP for Eureka and Nacos, TCP for ZooKeeper.

Self‑Protection : Supported by Eureka and Nacos, not by ZooKeeper.

Eureka Implementation Details

When a service starts, it registers itself via a REST call; the server stores the info in memory. Clients cache the registry locally and refresh it periodically. Heartbeats (renewals) keep the instance marked as healthy; missing heartbeats trigger self‑protection mode to avoid mass deregistration.

Configuration Center Overview

Configuration centers store key‑value pairs such as DB URLs, ports, and log levels. They enable dynamic updates without restarting services, reducing operational overhead for large fleets.

Spring Cloud supports several config stores:

Spring Cloud Config (Git, SVN)

ZooKeeper

Consul

Etcd

Apollo (Ctrip)

Nacos

Nacos Configuration Mechanics

Configuration is persisted in an embedded Derby DB or external MySQL.

Clients register their config metadata on startup, receiving a version number.

Clients pull config via API; the server returns the value for the requested key.

Clients can register listeners; when a config changes, the server pushes the update (implemented as long‑polling).

HTTP vs. RPC

HTTP is an application‑layer protocol focusing on request/response semantics, typically using text‑based payloads (JSON, XML). RPC abstracts remote method invocation, allowing binary protocols (e.g., Protobuf) and tighter coupling to method signatures.

Feign vs. Dubbo

Feign : Declarative HTTP client, integrates with Ribbon for client‑side load balancing, can use Hystrix for fallback.

Dubbo : Full‑stack RPC framework offering service registration, discovery, load balancing, fault tolerance, and a rich ecosystem (e.g., Sentinel for flow control).

They are not mutually exclusive; Dubbo can use HTTP transport, and Feign can call RPC services via adapters.

Feign Details

Feign uses annotations to define interfaces. Example:

@FeignClient(name = "example", url = "https://api.example.com")
public interface ExampleService {
    @GetMapping("/endpoint")
    String getEndpointData();
}

Features include declarative APIs, Ribbon‑based load balancing, and optional Hystrix circuit breaking.

First‑Call Latency in Feign

The initial call is slow because Ribbon lazily loads the service list and builds connection pools. Pre‑warming the client (e.g., a harmless call at startup) mitigates this delay.

Feign Authentication Propagation

Implement a RequestInterceptor to add an Authorization header:

@Configuration
public class FeignClientConfig {
    @Bean
    public RequestInterceptor requestInterceptor() {
        return template -> template.header("Authorization", "Bearer " + getToken());
    }
    private String getToken() { return "your_token"; }
}

Load‑Balancing Algorithms

Round Robin

Weighted Round Robin

Random

Weighted Random

Least Connection

Hash (e.g., based on client IP)

Service Resilience

Common patterns:

Circuit Breaker – stops calls to a failing service after a threshold (Hystrix, Resilience4j, Sentinel).

Fallback – provides a default response when the primary call fails.

Rate Limiting – limits request QPS (Sentinel’s sliding‑window algorithm).

Bulkhead / Thread‑Pool Isolation – isolates resources per downstream service.

Hystrix Mechanisms

Circuit breaking based on error rate or latency.

Fallback methods (example code shown).

Request caching.

Request collapsing (batching).

Real‑time metrics.

Thread‑pool isolation.

Sentinel Rate Limiting

Define a resource (e.g., a URL) and configure a QPS rule:

FlowRule rule = new FlowRule();
rule.setResource("/api/user");
rule.setCount(20);
rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
FlowRuleManager.loadRules(Collections.singletonList(rule));

Sentinel supports cluster‑wide limiting via a Token Server/Client model.

API Gateway Essentials

An API gateway acts as a unified entry point, handling routing, load balancing, security, caching, protocol conversion, and API versioning.

Spring Cloud options include:

Netflix Zuul (deprecated)

Spring Cloud Gateway (reactive, recommended)

Kong (Nginx‑based, cloud‑native)

APISIX (Lua/Nginx, plugin‑rich)

Distributed Tracing

Popular tracing back‑ends compatible with Spring Cloud Sleuth:

Zipkin

Jaeger

SkyWalking

Pinpoint

They collect span data to visualize request flows, identify latency hotspots, and aid debugging.

Distributed Transaction with Seata

Seata supports four transaction modes:

AT – automatic transaction (default).

TCC – Try‑Confirm‑Cancel with explicit compensation.

SAGA – event‑driven long‑running transactions.

XA – two‑phase commit using database XA support.

Its architecture consists of a Transaction Coordinator, Transaction Manager, and Resource Manager. The two‑phase commit flow includes a prepare (pre‑commit) stage followed by a commit or rollback stage based on participant responses.

Monitoring & Logging

Metrics are scraped by Prometheus and visualized in Grafana dashboards. Logs are collected via the ELK stack (Elasticsearch, Logstash, Kibana) or alternatives such as Fluentd, Graylog, Loki, or cloud‑provider services.

References:

《重新定义SpringCloud实战》

《SpringCloud Alibaba微服务实战与原理》

Dubbo official site: https://cn.dubbo.apache.org/

Spring Cloud Netflix docs: https://cloud.spring.io/spring-cloud-netflix/reference/html/

Prometheus guide: https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu

Grafana: https://grafana.com/

Sentinel docs: https://sentinelguard.io/zh-cn/

Elastic Stack: https://www.elastic.co/elastic-stack

Seata docs: https://seata.io/