Microservices Overview and Core Components

Microservices have evolved from a concept to a mature architectural style used to replace monolithic applications, offering greater agility, speed, and security. Various frameworks and tools such as Spring Cloud, Netflix OSS, Dubbo, Consul, and Eureka are widely adopted.

In large organizations, different teams often use different service frameworks, which increases learning costs, resource consumption, fault probability, and incident resolution time. A unified, stable, and maintainable foundation is needed to support all business units.

The article introduces the challenges of migrating to microservices within NetEase Media Technology, where teams use Spring Cloud, Dubbo, Spring MVC, and multiple language stacks (Java, C++, Python). The goal is to achieve a smooth, comprehensive, and low‑impact transformation.

1. Microservices Introduction

Monolithic applications bundle all functionality into a single deployable unit (JAR, WAR, etc.). As business complexity grows, monoliths suffer from version management difficulties, poor stability, low flexibility, hindered continuous integration, and technology‑stack constraints.

Microservices break a monolith into small, independently deployable services that communicate via lightweight protocols (REST, MQ). Their key characteristics are single responsibility, independent deployment, language‑agnostic implementation, and lightweight communication.

However, microservices introduce new challenges: increased system and operational complexity, difficulty in determining proper service boundaries, and higher testing complexity.

2. Basic Microservice Components

Service registries are core to microservice architectures, providing registration, deregistration, and discovery functions.

CAP Principle : In distributed systems, consistency, availability, and partition tolerance cannot all be achieved simultaneously. Implementations may favor AP (e.g., Eureka) or CP (e.g., Consul).

Eureka (Netflix OSS) is a Java‑based AP service registry using a server/client model. The server stores service metadata, while clients register themselves and query the registry.

Consul (HashiCorp, written in Go) is a CP‑oriented registry that supports service registration & discovery, health checks, KV storage, and multi‑datacenter deployment.

Zookeeper is a CP‑oriented coordination service originally from Google, providing leader election, follower/observer servers, and client connections.

NetEase Media chooses Consul as its primary registry.

3. Service Registration and Invocation

Service consumption can be categorized as:

Centralized: traffic passes through a load balancer (hardware or software) that maintains a service address table and performs health checks.

In‑process: client libraries (e.g., Dubbo, Ribbon, Motan) embed load‑balancing logic within the application process.

Sidecar/independent process: a separate proxy process handles load balancing, offering better isolation and language‑agnostic support.

NetEase Media adopts a hybrid of in‑process (for Java) and sidecar (for other languages) approaches.

4. Service Fault Tolerance

Hystrix (Netflix) provides isolation (thread‑pool or semaphore), fallback (degradation), and circuit‑breaker mechanisms to prevent cascading failures.

5. API Gateway

An API gateway offers a unified entry point, handling routing, authentication, rate limiting, caching, logging, monitoring, and fault‑tolerance. Open‑source gateway solutions mentioned include Tyk, Kong, Orange, Zuul, apiaxle, and api‑umbrella. NetEase Media currently uses Kong as its unified gateway.

The next article will detail how NetEase Media implements and promotes this microservice framework internally.