How Tencent’s TSF Mesh Bridges Spring Cloud and Service Mesh for Seamless Migration

Background and Motivation

Many enterprises still use SDK‑based microservice frameworks, but the rise of Service Mesh has prompted a shift toward mesh‑based governance. Companies often cannot migrate all services at once; Java services may stay on Spring Cloud while non‑Java services adopt a mesh, raising questions about inter‑service communication, unified governance, and smooth migration.

Why Build TSF Mesh?

Although Istio is a mature open‑source mesh, Tencent created TSF Mesh to handle scenarios that Istio cannot, such as supporting services running on virtual machines (VMs) without full Kubernetes reliance and providing a complete migration path from Spring Cloud to a mesh‑centric model.

Key Challenges

Platform Dependency : Istio tightly couples to Kubernetes for lifecycle, health checks, and routing, which does not suit VM or bare‑metal deployments.

Framework Integration : Spring Cloud and Service Mesh have separate service‑registry, routing, and circuit‑breaker mechanisms that must interoperate.

Observability : Unified logging, metrics, and tracing across both stacks are required.

PaaS Platform Decoupling

TSF Mesh introduces a Resource Controller as an intermediate layer that abstracts both Kubernetes and VM environments. For containers it talks to the standard K8s API server; for VMs it uses a custom aPaaS platform with four modules:

Repo Manager : versioned package storage, similar to a container registry.

TSF‑master‑api / TSF‑master : task dispatcher that forwards deployment, start/stop, and scaling commands to VMs.

TSF Controller : horizontal pod autoscaler‑like component that scales VM instances based on CPU/memory metrics.

tsf‑agent : node‑level agent that initializes the VM, downloads packages, manages process lifecycles, and performs health checks.

Sidecar Injection and Traffic Hijacking

Sidecar injection is performed by the Resource Controller for both containers and VMs. For containers the injection follows the standard Istio model (manual istioctl kube‑inject or automatic webhook). For VMs the injection is packaged into a task sent to tsf‑agent, which launches the sidecar alongside the application.

Traffic hijacking uses iptables rules that redirect DNS (port 53) and service‑mesh traffic (port 15001) to the local Mesh‑DNS and Envoy sidecars, ensuring only mesh‑registered services are intercepted.

No‑Loss Release and Graceful Shutdown

TSF Mesh implements readiness probes for both containers and VMs: the framework probes the application health before registering the instance in the service registry, guaranteeing no‑loss releases. Graceful shutdown removes the instance from the registry first, then executes a preStop hook (or equivalent VM command) before terminating the process.

Unified Service Registry (Consul)

Because native Istio relies on Kubernetes Service objects, TSF Mesh replaces it with Consul, which both Spring Cloud and the mesh can use. Modifications include:

Switching from polling to Consul watch for service‑change events.

Extending pilot‑discovery with registration and heartbeat gRPC interfaces.

Adding an HDS (Health Discovery Service) to receive health reports from Envoy.

Applications provide a spec.yaml describing service name, port, and health‑check URL; Envoy reads this file, registers the service via HDS, and performs periodic health checks.

Distributed DNS (Mesh‑DNS)

To avoid Kubernetes‑specific DNS, TSF Mesh implements a distributed DNS that runs on each data‑plane node. Mesh‑DNS syncs service lists from the control plane and resolves mesh‑registered names to a special IP that iptables redirects to Envoy. Non‑mesh names fall back to the system resolve.conf DNS.

Unified Service Governance

TSF Mesh aligns the governance models of Spring Cloud and the mesh:

Metadata Model : a common service‑registration schema ensures both sides see identical instance lists.

API Description : Spring Cloud’s Swagger output and mesh‑side OpenAPI v3 definitions are unified, enabling shared routing, circuit‑breaking, and rate‑limiting policies.

Policy Engine : configuration UI, routing weight algorithms, circuit‑breaker logic, and token‑bucket rate limiting are standardized across both stacks.

Circuit‑Breaker Enhancements : Spring Cloud moves from Hystrix to Resilience4J with multi‑level isolation; Envoy is extended to support industry‑standard circuit‑breaker semantics at service, API, and instance levels.

Routing consistency is achieved by using identical rule definitions, a shared registry, and the same weight‑based algorithm, guaranteeing that identical traffic yields identical routing outcomes in both environments.

Data Operation (Unified APM)

TSF Mesh provides an APM platform that consolidates logs, metrics, and tracing:

Configuration requests from the console are routed to TSF Master (VM) or TSF Resource (container) which inject Filebeat agents.

Agents collect logs, send them to Elasticsearch, where pipelines parse and index them.

Tracing uses OpenTracing: Spring Cloud leverages Sleuth (with extensions for local log‑trace correlation) and Envoy emits OpenTracing spans (extended to write local trace files).

The APM also supports alerting via TSF Monitor, which forwards metrics to Barad and downstream alerting platforms.

Migration Strategies

Three migration paths are described:

Go Native : direct re‑architecture to cloud‑native, fully mesh‑enabled services.

Evolve : first containerize, then adopt the mesh.

Lift & Shift : move existing VMs to the cloud, then containerize and mesh‑ify.

TSF Mesh’s decoupled design allows hybrid migrations where some services stay on Spring Cloud while others run on the mesh, with seamless inter‑service communication.

Conclusion

By building a cross‑platform, multi‑framework Service Mesh based on Istio + Envoy, extending registration to Consul, implementing distributed DNS, and unifying governance and observability, TSF Mesh enables enterprises to migrate legacy Spring Cloud microservices to a cloud‑native mesh with minimal disruption.