From Proxies to Service Mesh: Evolution of Service Discovery in Cloud‑Native Architecture

Background

To improve R&D efficiency and enable large‑scale business innovation, both internet‑centric and traditional enterprises are decoupling monolithic architectures into microservices, a major trend in digital transformation.

In a microservice architecture, the number of services can range from a few to hundreds, each typically deployed as a high‑availability cluster.

Two problems arise:

Service discovery – how can a consumer locate the provider?

Load balancing – how can the consumer access provider instances according to a balancing strategy?

General Solution Approach: Proxy

Throughout the evolution of service discovery, three generations of solutions have emerged, all centered on a proxy placed at different points in the architecture. By inserting a proxy between consumers and providers, the proxy handles discovery and load balancing, allowing consumers to access service instances indirectly.

Three Generations of Service Discovery Solutions

First Generation: Traditional Centralized Proxy

The solution is simple: deploy a proxy service between consumers and providers.

Common centralized proxies include hardware load balancers (e.g., F5, A10) or software load balancers such as Nginx and HAProxy; hybrid deployments (F5 in front of Nginx) combine flexibility with ease of configuration.

This setup requires DNS domain names; each service must register a domain, and the proxy must map the domain to the service IP.

DNS and proxy configurations are usually performed manually by operations staff.

Companies such as eBay, Ctrip, and Paipaidai have adopted this approach.

Drawbacks include manual configuration, low efficiency, and limited flexibility, which are unfriendly to developers.

Second Generation: Client‑Embedded Proxy

With the rise of microservices and cloud technologies, enterprises demanded higher efficiency and flexibility, leading to the second‑generation solution.

The discovery and load‑balancing logic is embedded as a library within the application or service.

An independent service registry is required; services automatically register themselves on startup and send periodic heartbeats. Clients query the registry for IP lists and apply a load‑balancing strategy, enabling self‑service without heavy ops involvement.

Many open‑source projects implement this model, for example:

Eureka with Ribbon client proxy.

Dubbo and the newer Nacos.

Consul combined with Ribbon.

Drawbacks:

The client depends on a specific language stack; supporting multiple languages increases development cost.

Embedding the proxy adds complexity to the client.

Third Generation: Host‑Independent Process (Service Mesh)

With the emergence of containers and cloud‑native technologies, the industry explored a third‑generation solution.

This approach is a compromise: the proxy is not centrally deployed nor embedded in the application, but runs as an independent process on each host (physical or virtual). Multiple consumers on the same host can share the proxy, achieving discovery and load balancing.

The architecture resembles the second generation, still requiring a service registry; the only difference is the proxy’s placement.

This solution is commonly referred to as a Service Mesh.

Open‑source products include Envoy, Linkerd, and Istio, which integrate with service registries; Kubernetes also provides built‑in service discovery, fitting the third‑generation host‑independent model.

Kubernetes Service Discovery Mechanism

Given Kubernetes’s popularity and its complex internal discovery mechanism, we examine it separately.

In Kubernetes, a service consists of a set of Pods.

A Pod is the basic scheduling unit, analogous to a virtual machine in the cluster.

Each Pod has a PodIP; Pods communicate via these IPs, but PodIPs are not stable and may change.

To hide this volatility, Kubernetes introduces the Service abstraction, which provides service discovery, load balancing, and a stable virtual IP (ClusterIP).

When a Service is created, Kubernetes assigns it a ClusterIP.

On each worker node, kubelet starts Pods while kube‑proxy implements service discovery. The simplified discovery flow is:

Service Registration Phase:

kubelet launches the Pod instance.

After startup, kubelet registers the Pod’s IP list to the master node.

When the Service is published, Kubernetes assigns a ClusterIP and records the mapping on the master.

Service Discovery Phase:

kube‑proxy learns the mapping between ClusterIP and PodIP and updates local iptables rules for load balancing and forwarding.

When a consumer Pod accesses a target Service, it calls the ClusterIP; iptables intercepts the request, balances it, and forwards it to the appropriate Pod.

Consumers use the Service name to reach the ClusterIP; kube‑DNS resolves the Service name to the current ClusterIP, shielding clients from IP changes.

Comparison and Selection

All three solutions have distinct advantages and disadvantages, and each has been successfully deployed at large scale. Architects should understand these trade‑offs, consider the specific business context, and make an informed technology selection.

Source: https://www.cnblogs.com/jackyfei/p/12078420.html