Understanding Microservices: Architecture, Service Publishing, Registration, and Stability Practices

Table of Contents

What is a microservice

What a microservice looks like

Prerequisites for service‑orientation

Service publishing and referencing

Service registration and discovery

Remote communication between services

How the registration center guarantees stability

How service consumers guarantee stability

How service providers guarantee stability

What Is a Microservice

Moving from monolithic to microservice applications mainly reduces coupling; splitting modules into independently deployable services constitutes a microservice.

Splitting creates several essential needs:

Reliable remote‑procedure‑call communication.

Comprehensive service governance for complex resource scheduling.

Mechanisms to prevent cascading failures (service avalanche).

Integration with containerization and DevOps to lower operational costs.

What a Microservice Looks Like

In a typical web architecture, microservices sit in the middle layer, encompassing RPC frameworks, registration centers, configuration centers, monitoring, governance, and scheduling components.

Core modules usually include:

Service registration and discovery

RPC remote calls

Routing and load balancing

Service monitoring

Service governance

Prerequisites for Service‑Orientation

Simply adding a microservice framework does not make a service truly "micro"; the service must be sufficiently fine‑grained and single‑purpose, with clear boundaries based on business needs.

Service‑orientation also involves application splitting and data splitting. Data splitting introduces concerns such as distributed IDs, table optimization, data migration, SQL refactoring, sharding, and consistency.

After understanding the overall architecture, a complete microservice request involves three basic functions:

Service publishing and referencing

Service registration and discovery

Service remote communication

Service Publishing and Referencing

Publishing a service requires defining its interface name, parameters, and return types. Common publishing/reference methods are:

RESTful API / declarative RESTful API

XML configuration

IDL (e.g., Thrift, gRPC)

Example interface definition (Java):

@exa(id = "xxx")
public interface testApi {
    @PostMapping(value = "/soatest/{id}")
    String getResponse(@PathVariable(value = "id") final Integer index, @RequestParam(value = "str") final String Data);
}

Implementation:

public class testApiImpl implements testApi {
    @Override
    String getResponse(final Integer index, final String Data) {
        return "ok";
    }
}

Declarative RESTful API

Uses HTTP/HTTPS; performance is modest. The service defines and implements the interface, then publishes via a framework such as RestEasy. Clients can also use Feign, which relies on a Spring MVC controller on the server side.

XML

Private RPC protocols (e.g., Dubbo, Motan) often use XML to describe interfaces. The server exposes interfaces via server.xml , and clients reference them via client.xml . This approach is more invasive to business code.

IDL

Interface Definition Language enables cross‑language calls. gRPC uses Protobuf; after writing a .proto file, language‑specific plugins generate client and server code. Large proto files can be hard to maintain, and backward compatibility may be limited.

Tips

When an interface changes, notify consumers. Prefer adding new interfaces or versioning existing ones to avoid breaking existing callers.

Service Registration and Discovery

Consumers need to locate service instances. DNS is insufficient due to maintenance overhead, lack of client‑side load balancing, and inability to discover services at the port level.

A registration center solves this problem. The process:

Service registers itself and sends heartbeats.

Clients subscribe to the service, cache the node list locally, and select an instance via load‑balancing.

When a node changes, the center notifies clients.

Consistency and Availability

Based on the CAP theorem, registration centers are either CP (e.g., Zookeeper, etcd, Consul) prioritizing consistency, or AP (e.g., Eureka) prioritizing availability. For registration, AP is often sufficient because eventual consistency can be handled by client‑side fault‑tolerance.

Registration Methods

Two interaction modes:

In‑process SDK integration (e.g., Curator for Zookeeper).

Out‑of‑process registration (e.g., Consul agent or Registrator).

Storage Structure

Typically hierarchical: service → interface → node. Grouping can be based on data center, environment, etc. Nodes store address, port, and metadata such as retry count and timeout.

Health Monitoring

Clients maintain long‑lived sessions with the center; missing heartbeats cause the node to be removed.

Status Change Notification

Watchers (e.g., Zookeeper watchers) receive callbacks when node status changes.

How the Registration Center Guarantees Stability

Node information is cached in memory and persisted as a local snapshot, allowing consumers to continue operating when the center is down or after a restart.

Node removal mechanisms:

Center‑driven removal after missed heartbeats.

Consumer‑driven removal after repeated request failures (similar to circuit‑breaker logic).

Frequent node changes can cause network storms; mitigations include throttling change notifications, sending incremental updates, and setting a minimum healthy‑node threshold before removing nodes.

How Service Consumers Ensure Stability

Timeouts

Set appropriate timeouts (e.g., P999 latency or 2×P95) to avoid being blocked by slow downstream services. Differentiate between sync and async calls.

Fault‑Tolerance Mechanisms

Fail‑Try: retry the same instance (requires idempotency).

Fail‑Over: retry on a different instance.

Fail‑Fast: immediately report failure.

Circuit Breaker

Three states: closed (normal), open (stop calls after threshold), half‑open (test calls). Failure thresholds can be count‑based or ratio‑based; open‑state duration may grow exponentially.

Isolation

Semaphore isolation limits concurrent calls; thread‑pool isolation provides stronger resource separation.

Fallback

When the circuit breaker opens, return predefined fallback data or the last successful response captured from logs.

How Service Providers Ensure Stability

Rate Limiting

Limit incoming traffic by QPS or concurrent threads using algorithms such as token‑bucket or leaky‑bucket (e.g., Guava RateLimiter).

Restart and Rollback

Automatic rollback to a previous version or auto‑restart when abnormal metrics are detected. Capture diagnostic data before restart (GC logs, heap dumps, thread stacks).

Example diagnostic commands:

jstack -l <java_pid>

jmap -dump:format=b,file=hprof <java_pid>

Traffic Steering

Adjust load‑balancer weights to zero for unhealthy instances, route traffic to healthy clusters or data‑centers, and optionally use DNS VIP switching.

Conclusion

Microservice stability relies on a combination of robust registration/discovery, thoughtful client‑side fault tolerance, and provider‑side safeguards such as rate limiting, graceful restart, and traffic steering.