How China Unicom’s Service Mesh Evolved: From SDKs to Sidecars and Beyond

What Is a Service Mesh

A service mesh abstracts microservice capabilities—such as routing, load‑balancing, rate‑limiting, and circuit‑breaking—into a dedicated sidecar data plane, allowing these functions to be managed independently of application code.

Evolution of China Unicom’s Microservice Architecture

Since 2020, China Unicom’s Software Research Institute (CSM) aligned its architecture roadmap with Kubernetes (K8s) as the resource scheduler and chose service mesh as the next‑generation microservice framework.

Stage 1 (Microservice 1.0): Functionality delivered via language‑specific SDKs, tightly coupling capabilities to the application.

Stage 2 (Microservice 2.0): Introduction of independent sidecar processes, eliminating language constraints.

Stage 3 (Service Mesh): Adoption of K8s and Istio, establishing a mesh‑centric target architecture.

The institute also ensured backward compatibility for legacy services during migration.

Practical Migration Scenarios

3.1 RPC Architecture → Service Mesh

Existing RPC‑based services rely on interface‑level service discovery and require code annotations for migration. The joint solution with Baidu uses dynamic proxies to keep business code unchanged, reducing migration cost.

Key Benefits:

Business code remains untouched; only annotations are added.

Service discovery shifts from interface‑level to application‑level, decreasing redundant registration data.

3.2 Mesos + Marathon → Service Mesh

Legacy workloads use Mesos/Marathon for scheduling and Spring Cloud for governance, with capabilities scattered across multiple components.

The migration plan retains existing business code, extracts microservice functions from a “fat” SDK into a “thin” SDK, and moves them to the sidecar layer. Additional optimizations include:

Cloud‑native transformation: Replacing Mesos with K8s + Istio.

Observability: Using Java agents for zero‑code trace‑header propagation and method‑level monitoring.

OpenTelemetry integration: Unified data collection via OTLP to various back‑ends (Jaeger, SkyWalking, etc.).

Future Service Mesh Product Roadmap

4.1 Performance – Single‑Hop Architecture

Current double‑hop (inbound + outbound) sidecar interception adds latency. By eliminating unnecessary inbound interception, a single‑hop design reduces delay significantly.

4.2 Performance – eBPF Acceleration

Leveraging kernel‑level socket‑map and redirect mechanisms bypasses the TCP/IP stack, further cutting sidecar‑induced latency.

4.3 Extensibility – Fallback Mechanism

A fallback mode allows traffic to bypass the sidecar during extreme failures, providing seamless switching between proxy and direct modes.

4.4 Extensibility – On‑Demand XDS Delivery

Instead of full‑mesh XDS pushes, only the configuration required by each sidecar is sent, reducing redundant data and improving scalability.

4.5 Extensibility – Domestic‑Friendly Support

The mesh is being adapted for various Chinese‑made platforms, supporting X86, ARM, PPC CPUs and operating systems such as UnionTech UOS and Kylin.

Value and Benefits

The mesh delivers unified microservice stacks, cloud‑native architecture, multi‑language support, non‑intrusive monitoring, and an improved service‑governance UI, leading to reduced operational overhead and faster feature rollout.

Outlook

All pilot projects have validated the migration in test environments and many have entered production. Ongoing collaboration between China Unicom and Baidu will deepen joint R&D, accelerate cloud‑native transformation, and unlock further business value.