How Service Mesh Enables Platform‑Decoupled Microservices: A TSF Mesh Deep Dive

Background

In microservice architectures, Service Mesh provides a non‑intrusive way to manage traffic, health checks, and service discovery. The author, a senior microservice architect at Anhui Cloud Native, shares practical experiences from a real‑world retail e‑commerce project where a hybrid cloud environment required a unified mesh solution.

Platform Decoupling and TSF Mesh Extensions

The original architecture mixed on‑premise IDC servers and cloud VMs, making Istio’s Kubernetes‑bound CRD model unsuitable. TSF Mesh extends Istio by adding a Consul Server cluster for service registration and discovery, replacing K8s CRDs. Pilot and Mixer components are enhanced to read Consul data, while health checks are performed via Envoy’s HDS interface and reported back to Consul.

Cross‑Platform Service Discovery and DNS Evolution

To enable services deployed on different platforms to locate each other, the solution moves from a centralized DNS (e.g., CoreDNS) to a distributed DNS model. TSF Mesh introduces a Mesh‑dns process that watches /etc/resolv.conf via inotify, synchronizes service lists with Pilot, and adds iptables rules to forward name‑server traffic, ensuring seamless cross‑platform name resolution.

Multi‑Service Scenarios and Service Description Files

Legacy applications often expose multiple logical services on a single process (single‑port multi‑service) or on multiple ports. TSF Mesh uses a simple service description file that lists service names, ports, and health‑check endpoints. The Pilot‑agent reads this file at startup, registers each service in Consul, and the data plane routes traffic based on LDS, RDS, CDS, and EDS configurations.

Implementation Steps and Takeaways

Add iptables rules on each node to forward DNS traffic to Mesh‑dns.

Deploy Mesh‑dns to monitor /etc/resolv.conf and keep service lists in sync with Pilot.

Extend Pilot‑agent and add an API Server to expose RESTful interfaces for routing rules, black‑/white‑lists, etc.

These three methods—platform decoupling via Consul, distributed DNS for cross‑platform communication, and flexible service description for multi‑service processes—demonstrate how to adapt Istio‑based Service Mesh to heterogeneous environments without rewriting existing applications.