How YANXU’s Service Mesh Evolved from Consul+Nginx to Istio

Preface

Like any business, the underlying IT system must survive, breathe, grow, and evolve; otherwise a stale architecture stalls the organization.

The industry has progressed from monolithic modularization to SOA, then microservices, and finally Service Mesh. YANXU’s backend evolution mirrors this trend and even leads in some aspects.

Architecture Maturity

Although there is no universal maturity model, moving from monolithic modularization → SOA → microservices → Service Mesh clearly represents increasing sophistication.

Each stage introduces its own challenges that are resolved at the next level, with differing complexity and focus.

Monolithic Modular Architecture : High cohesion, low coupling; modules communicate via in‑process method calls.

Service‑Oriented Architecture (SOA) : Reuse at the application level; services communicate through an enterprise service bus.

Microservices : Vertically split, high cohesion, low coupling; communication via RPC.

Service Mesh : Separates business logic from service‑governance logic; communication is proxied by a mesh, achieving the deepest decoupling and reuse.

What Is Service Mesh?

According to William, CEO of Linkerd, a Service Mesh is an infrastructure layer that handles service‑to‑service communication, typically implemented as a set of lightweight network proxies deployed alongside applications and transparent to them.

Modern Service Meshes encompass all aspects of service governance, separating business code from governance code, which improves developer productivity and operational efficiency.

First Generation – YANXU’s Consul + Nginx Mesh

Before the term “Service Mesh” existed, YANXU built a sidecar‑style solution using Consul and Nginx (cNginx) to provide non‑intrusive service routing, load balancing, timeout handling, retries, and fail‑over.

The control plane (Consul admin) offered traffic scheduling, service registration/discovery, and rate‑limit & circuit‑break features.

Benefits included transparent governance for business services, unified communication across languages, reduced middleware costs, and lower coupling between business and infrastructure.

Second Generation – Istio‑Based Mesh

Growth outpaced cNginx’s capabilities, and the rise of cloud‑native infrastructure made Istio the natural choice.

Istio also separates data plane and control plane. The data plane uses Envoy sidecars; the control plane consists of Pilot, Mixer, Citadel, and Galley, providing service discovery, traffic routing, policy enforcement, security certificates, and configuration validation.

Key Decisions

1. Client‑Sidecar Mode : Chosen for continuity with the first generation and to avoid performance penalties of both‑sidecar deployments.

2. Feature‑by‑Feature Adoption : Initially enable only features equivalent to cNginx, gradually adding more; some heavy‑weight features like Mixer policy checks were deferred due to performance concerns.

3. Integration with Kubernetes : Leveraged automatic sidecar injection, unified service discovery, CRD‑based governance rules, and declarative service registration.

Transition Architecture

During migration, both cNginx (cloud‑external) and Istio (cloud‑internal) coexist, with routing logic that transparently directs traffic to the appropriate mesh based on service location.

Performance Pitfalls

Misconceptions claim that the extra hop of a mesh dramatically hurts latency. In YANXU’s benchmarks, Istio (client sidecar) adds ~0.6 ms overhead at 1600 RPS with 40 concurrent users, comparable to cNginx’s ~0.4 ms.

Further optimizations include eBPF/xDP (10‑20% latency reduction) and DPDK+Fstack (0.8‑1× improvement), with ongoing performance regression testing.

Conclusion

Transitioning from cNginx to Istio modernized YANXU’s service‑governance capabilities, boosting developer efficiency by cleanly separating business and infrastructure concerns, and ultimately accelerating business growth.