How Tencent’s TSF Mesh Overcame Real‑World Service Mesh Challenges

Background

Service Mesh is an infrastructure layer that abstracts inter‑service communication. Since 2018 the open‑source project Istio (over 22 000 GitHub stars) has become the de‑facto reference implementation.

TSF Mesh Overview

TSF Mesh (Tencent Service Mesh Framework) is a productized Service Mesh built on Istio. It provides automatic service registration, discovery, routing, authentication, rate‑limiting, circuit‑breaking and other governance capabilities without requiring code changes.

Istio was chosen because it offers a complete feature set, an active CNCF community, and high‑performance implementations (Golang for control plane components, C++ for Envoy).

Architecture

TSF Mesh retains Istio’s data plane (Envoy) and control plane (Pilot, Mixer, Citadel) and adds two components:

Apiserver – converts metadata from heterogeneous environments into Istio‑compatible resources.

Mesh‑dns – a distributed DNS sidecar that resolves service names locally and forwards non‑mesh queries to the underlying DNS.

The architecture supports public cloud, private cloud, on‑premises, VM and bare‑metal deployments.

Productization Challenges

1. Supporting Heterogeneous Compute Platforms

Istio’s control plane relies on Kubernetes CRDs, service discovery and health checks, which are unavailable in non‑Kubernetes environments. TSF Mesh decouples from Kubernetes by:

Extending Pilot with a Consul adapter to obtain service registration and health information.

Adding an Apiserver that converts metadata from VM, bare‑metal or custom PaaS into Istio resources.

Enhancing Pilot‑agent to inject Envoy into VMs, manage their lifecycle and perform automatic service registration.

After these extensions, the data plane can be controlled via gRPC or REST APIs regardless of the underlying platform.

2. Multi‑Tenant Isolation

TSF Mesh implements a soft‑multitenancy model:

Each tenant gets an isolated control‑plane cache indexed by tenant ID.

Metadata storage is partitioned so that a tenant only sees its own services, configurations and runtime state.

This design enables multiple tenants to share the same physical cluster while preserving security and resource fairness.

3. Service Addressing and DNS

Istio does not provide a DNS service; it relies on the platform’s DNS (e.g., kube‑dns). To support environments without Kubernetes, TSF Mesh introduces a distributed Mesh‑dns sidecar:

Mesh‑dns synchronizes service information from Pilot.

When an application resolves a service name, the request is handled locally by Mesh‑dns, which returns the appropriate IP and forwards traffic to the Envoy sidecar.

Non‑mesh queries are transparently forwarded to the underlying DNS, ensuring compatibility with external services.

The sidecar runs as a lightweight process, has no single point of failure, and automatically restarts on crash.

4. Interoperability with Spring Cloud

Spring Cloud is an intrusive Java‑centric microservice framework. To enable seamless calls between Spring Cloud services and Mesh‑based services, TSF Mesh aligns the two stacks on several dimensions:

Service model : a unified metadata schema maps Service Mesh registrations to Spring Cloud’s discovery mechanisms.

API definition : both sides expose OpenAPI v3 specifications, allowing consistent routing, rate‑limiting and circuit‑breaking policies.

Routing : weight‑based algorithms and label selectors are used to translate Istio VirtualService rules to Spring Cloud Ribbon configurations.

Rate limiting : a token‑bucket model with conditional matching is shared between Envoy’s Mixer and Spring Cloud’s RateLimiter.

Circuit breaking : Envoy is extended to support service‑level, API‑level and instance‑level circuit breakers compatible with Spring Cloud.

Authentication : tag‑based whitelist/blacklist rules are applied uniformly.

5. Observability

TSF Mesh extends Envoy’s tracing capabilities:

Retains the standard envoy.zipkin tracer.

Adds a local tracer ( envoy.local) that writes trace data to a mounted disk.

The local traces are collected by Tencent’s APM system, providing unified logging, metrics and distributed tracing for both Mesh and Spring Cloud workloads.

Conclusion and Outlook

TSF Mesh has been deployed in finance, retail and industrial IoT scenarios, demonstrating that the extensions above solve real‑world challenges such as platform heterogeneity, multi‑tenant isolation, DNS absence, and cross‑framework compatibility. Ongoing work includes simplifying the control plane, adopting the UDPA (Universal Data Plane API) standard, integrating WebAssembly extensions into Envoy, and further performance optimizations.