Mastering Backend Architecture: From Microservices to Service Mesh and Message Queues

Overview

"Architecture Map" is a large‑scale concept that reflects the growth of an architect from points to planes to a full map. The author shares personal experience in architecture, R&D, and management, focusing on backend stacks, open‑source, cloud‑native, and third‑party services. The goal is to provide a technology stack, design ideas, and scenario guidance for decision‑making, emphasizing that architecture is a set of decisions constrained by team experience, cost, resources, schedule, and business stage.

Microservices

Microservices (Microservices) are a software architecture style that builds applications from small, single‑responsibility building blocks communicating via language‑agnostic APIs. Compared with monoliths, microservices enable independent development, deployment, and scaling of each service, reducing change scope and risk.

Theoretical Foundations

Design decisions should follow Conway’s Law: system designs mirror the communication structures of the organizations that create them. Effective architecture requires aligning team communication with system boundaries.

Domain‑Driven Design (DDD) provides a high‑level abstraction for complex domains, guiding service boundaries, entity identification, aggregation, and repository design. DDD is not a silver bullet; iterative refinement is essential.

Gateway

Gateways act as the unified entry point for microservices, handling traffic ingress, security, and routing. Two layers are typical:

Access gateway: provides global traffic entry, security, and load‑balancing (DNS, hardware/software load balancers, SSL, IPv6).

Business gateway: implements BFF, authentication, rate limiting, circuit breaking, service aggregation, and plugin extensions (e.g., Kong, APISIX, Spring Cloud Gateway, gRPC‑Gateway).

Protocol

Service communication choices include:

HTTP REST: API style built on HTTP, URLs, and JSON; often used in a “pseudo‑REST” fashion.

RPC: point‑to‑point calls over TCP or HTTP; frameworks include Dubbo, Motan (service‑governance focus) and Thrift/gRPC (cross‑language focus).

RPC offers clearer API definitions (proto files), better serialization efficiency, and richer fault‑tolerance, while REST excels in external integration simplicity.

Service Registration & Discovery

Two models exist:

Server‑side mode: uses load balancers and DNS for health checks and traffic routing.

Client‑side mode: relies on a registry (etcd, ZooKeeper, Consul) where clients pull configuration and perform load balancing.

Configuration Center

Beyond registration, configuration centers store KV data (etcd, ZooKeeper, Consul) or, in Kubernetes, ConfigMaps/Secrets. Solutions like Nacos and Apollo add UI, permission control, and dashboard features.

Observability

Observability measures system state from external outputs. In cloud‑native environments, the three pillars are Tracing, Logging, and Metrics.

Tracing: tools such as Jaeger, Zipkin, SkyWalking (OpenTracing) and OpenTelemetry unify tracing, logging, and metrics.

Logging: structured logs (RFC 5424 levels) are collected via agents (Filebeat, Fluentd) and stored in Elasticsearch/Kibana.

Metrics: Prometheus (cloud‑native) and Zabbix (traditional) expose counters, gauges, histograms, and summaries for resource and business monitoring.

Service Mesh

Service Mesh abstracts service‑to‑service communication, providing discovery, traffic control, security, and observability via a sidecar layer. Popular implementations include Istio (Envoy sidecar), Linkerd, and Conduit. High availability requires redundant sidecars or centralized sidecar deployments.

Message Queues

Message queues enable asynchronous communication, decoupling, load‑leveling, and eventual consistency. Key evaluation criteria are HA, throughput, feature richness, broadcasting, backlog handling, persistence, duplicate consumption, and ordering.

Redis

Supports List, Pub/Sub, and Stream. Simple to use but limited in durability, ordering, and broadcasting.

RabbitMQ vs Kafka vs RocketMQ

HA: all use replication; RabbitMQ at cluster level, Kafka via partitions/ISR, RocketMQ via master/slave.

Throughput: Kafka and RocketMQ write directly to disk for high speed; RocketMQ’s commit‑log design eases scaling.

Feature richness: RabbitMQ offers priority queues and TTL; RocketMQ adds built‑in retry intervals and 2‑phase commit transactions.

Ordering: Kafka guarantees order per partition; RocketMQ and RabbitMQ can preserve order per topic/queue with single consumer.

Pulsar

Apache Pulsar separates compute (broker) from storage (BookKeeper), offering HA, high throughput, rich features (delayed messages, retry queues), and flexible ordering via segment‑based storage.

Choosing a message‑queue solution involves balancing performance, reliability, operational complexity, and ecosystem support.