Cloud Native 8 min read

Nacos Service Mesh Ecosystem: Seamless Integration and Migration Strategies

This article explains Nacos as a dynamic naming and configuration service, its evolution at Alibaba, the challenges of migrating from traditional microservice architectures to service‑mesh‑based cloud‑native systems, and how Nacos supports seamless service discovery and configuration through MCP integration with Istio.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Nacos Service Mesh Ecosystem: Seamless Integration and Migration Strategies

Nacos (Dynamic Naming and Configuration Service) is designed to simplify building cloud‑native applications by providing dynamic service discovery, configuration management, and service governance.

Originating from Alibaba's 2008 Five‑Color‑Stone project and refined over a decade to handle millions of instances, Nacos was open‑sourced in 2018 to share Alibaba’s service‑discovery and configuration expertise.

With the rise of cloud‑native technologies and service‑mesh architectures, Nacos needed to better support mesh ecosystems.

In a traditional microservice 1.0 architecture, traffic enters via Tengine, passes through a microservice gateway, and services discover each other through Nacos SDKs; however, this model suffers from static configuration, tight SDK coupling, and high multi‑language maintenance costs.

Microservice 2.0 introduces an ingress gateway, Envoy sidecars, and Istio control plane, decoupling service‑governance from business logic and unifying management across languages.

Mesh adoption brings challenges such as sidecar performance, private‑protocol support, and smooth migration between old and new stacks, especially regarding service discovery.

Nacos addresses these by offering an MCP server; Istio retrieves full service lists via MCP (or MCP‑over‑XDS) from Nacos, enabling mesh‑enabled services to discover both mesh and non‑mesh services without code changes.

Alternative synchronization approaches are compared (see diagram), highlighting Nacos’s flexibility.

Practical implementations include two scenarios: (1) DingTalk cloud‑to‑group connectivity using MSE cloud‑native gateway, Envoy gateway, Dubbo 3.0 triple protocol, Istio control plane, and Nacos MCP for service list sync; (2) an internal group mesh where Envoy directly registers with Nacos to avoid performance issues with massive instance counts.

The Nacos source code is available at https://github.com/alibaba/nacos.

Disclaimer: The content is collected from the internet, reflects the author’s personal views, and is provided for learning and discussion only.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

NacosIstio
IT Architects Alliance
Written by

IT Architects Alliance

Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.