一文看懂 Higress 从 Nacos 配置到 MCP 路由的完整下发链路【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress你在 Nacos 里发布了服务、配好了 MCP 服务器网关这边却始终 404。Higress一个把 AI 网关能力做进云原生网关的项目的配置下发到底走了哪几步哪一步断了请求就到不了后端。这篇文章就沿着这个问题往下挖。 认知锚点Higress 是个翻译官Higress 干的活一句话站在 Nacos 这类注册中心和 Envoy 之间当翻译官。它从 Nacos 拉取服务注册信息和 MCP 服务器配置翻译成 Istio 语法的 ServiceEntry、VirtualService、DestinationRule分别描述服务是谁、走哪条路由、用什么流量策略再经 xDS控制面向数据面下发配置的协议推到 Envoy。三个组件里你只需要盯着 ControllerConsole 管配置录入Gateway 只管转发真正的转换逻辑全在 registry/nacos/mcpserver/watcher.go 这条线上。 机制深挖一份配置的三跳网关启动后谁在盯着 Nacos一句话结论定时轮询兜底变更监听提速。Run()一进来先全量拉一次然后每 30 秒可配最低 10 秒再拉一次ticker : time.NewTicker(time.Duration(w.NacosRefreshInterval)) err : w.fetchAllMcpConfig() if err ! nil { mcpServerLog.Errorf(first fetch mcp server config failed, ...) } else { w.Ready(true) }轮询只负责发现。fetchAllMcpConfig()用 registry/nacos/mcpserver/client.go 里的configClient分页搜索mcp-server-versions组下所有*mcp-versions.json新出现的 dataId 会调用ListenToMcpServer()订阅之后 Nacos 一推变更回调mcpServerListener立刻开始转换不用等下一个 30 秒。反过来Nacos 里删掉的配置轮询会发现并CancelListenToServer取消订阅。拉到的配置到底变成了什么一句话结论一个 dataId 换出一套 Istio 资源再丢进内存缓存。processServerConfig()是转换的核心关键四行serviceEntry : generateServiceEntry(serviceHost, services) virtualService : w.buildVirtualServiceForMcpServer(mcpServer, dataId, ...) destinationRule : generateDrForMcpServer(serviceHost, mcpServer.Protocol) w.cache.UpdateConfigCache(gvk.ServiceEntry, dataId, se, false)ServiceEntry 装的是 Nacos 里的健康实例 IP 列表VirtualService 生成/{server-name}这样一条路由指向上一步的服务DestinationRule 定流量策略。如果服务器是 HTTP 协议processToolConfig()还会把工具列表、credentials 打包成 WasmPlugin 规则——MCP 的tools/list、tools/call请求就是由这个 wasm 插件处理的。这些资源不写 K8s而是全部落到 registry/memory/cache.go 的内存 store 里由UpdateService()触发 xDS 推送。整个 Higress Core 内部长这样SSE 长连接为什么不会被换到别的后端MCP 常用 SSEServer-Sent Events一种单向长连接连接是有状态的换后端等于推倒重来。Higress 在生成 DestinationRule 时按协议分情况case provider.McpSSEProtocol: return v1alpha3.DestinationRule{ Host: host, TrafficPolicy: v1alpha3.TrafficPolicy{ LoadBalancer: ...ConsistentHash{...UseSourceIp: true...}SSE 服务挂上源 IP 一致性哈希同一个客户端永远落到同一台后端HTTPS 服务则自动补一条 TLS 策略。协议差异在这里被抹平写配置的人不用关心。 跑起来看看三步本地验证git clone https://gitcode.com/GitHub_Trending/hi/higress cd higress helm install higress -n higress-system higress.io/higress --create-namespace然后照着 samples/mcp/ 里的环境脚本搭一个带 Nacos 的 demokind 集群加几个 yaml脚本都在samples/mcp/environment/scripts/下。MCP 端点路径是/{base-path}/{mcp-server-name}base path 在higress-system命名空间higress-configConfigMap 的mcpServer段配置。验证下发是否到位最快的是看日志kubectl -n higress-system logs deployment/higress-controller | grep subscribe mcp server success看到 dataId 出现说明监听、转换、缓存这条链路已经跑通再curl -N打一下 SSE 端点就能拿到工具列表。收个尾回到开头那个 404它只可能断在三跳之一——没订阅上看subscribe日志、协议不支持supportedProtocols白名单、或者资源没进缓存看UpdateConfigCache日志。断点基本都在这条链路上定位起来不用满仓库翻。想继续往下走从 docs/architecture.md 的 Discovery 和 Config Controller 部分读起再回头看这份 watcher会顺很多。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
一文看懂 Higress 从 Nacos 配置到 MCP 路由的完整下发链路【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress你在 Nacos 里发布了服务、配好了 MCP 服务器网关这边却始终 404。Higress一个把 AI 网关能力做进云原生网关的项目的配置下发到底走了哪几步哪一步断了请求就到不了后端。这篇文章就沿着这个问题往下挖。 认知锚点Higress 是个翻译官Higress 干的活一句话站在 Nacos 这类注册中心和 Envoy 之间当翻译官。它从 Nacos 拉取服务注册信息和 MCP 服务器配置翻译成 Istio 语法的 ServiceEntry、VirtualService、DestinationRule分别描述服务是谁、走哪条路由、用什么流量策略再经 xDS控制面向数据面下发配置的协议推到 Envoy。三个组件里你只需要盯着 ControllerConsole 管配置录入Gateway 只管转发真正的转换逻辑全在 registry/nacos/mcpserver/watcher.go 这条线上。 机制深挖一份配置的三跳网关启动后谁在盯着 Nacos一句话结论定时轮询兜底变更监听提速。Run()一进来先全量拉一次然后每 30 秒可配最低 10 秒再拉一次ticker : time.NewTicker(time.Duration(w.NacosRefreshInterval)) err : w.fetchAllMcpConfig() if err ! nil { mcpServerLog.Errorf(first fetch mcp server config failed, ...) } else { w.Ready(true) }轮询只负责发现。fetchAllMcpConfig()用 registry/nacos/mcpserver/client.go 里的configClient分页搜索mcp-server-versions组下所有*mcp-versions.json新出现的 dataId 会调用ListenToMcpServer()订阅之后 Nacos 一推变更回调mcpServerListener立刻开始转换不用等下一个 30 秒。反过来Nacos 里删掉的配置轮询会发现并CancelListenToServer取消订阅。拉到的配置到底变成了什么一句话结论一个 dataId 换出一套 Istio 资源再丢进内存缓存。processServerConfig()是转换的核心关键四行serviceEntry : generateServiceEntry(serviceHost, services) virtualService : w.buildVirtualServiceForMcpServer(mcpServer, dataId, ...) destinationRule : generateDrForMcpServer(serviceHost, mcpServer.Protocol) w.cache.UpdateConfigCache(gvk.ServiceEntry, dataId, se, false)ServiceEntry 装的是 Nacos 里的健康实例 IP 列表VirtualService 生成/{server-name}这样一条路由指向上一步的服务DestinationRule 定流量策略。如果服务器是 HTTP 协议processToolConfig()还会把工具列表、credentials 打包成 WasmPlugin 规则——MCP 的tools/list、tools/call请求就是由这个 wasm 插件处理的。这些资源不写 K8s而是全部落到 registry/memory/cache.go 的内存 store 里由UpdateService()触发 xDS 推送。整个 Higress Core 内部长这样SSE 长连接为什么不会被换到别的后端MCP 常用 SSEServer-Sent Events一种单向长连接连接是有状态的换后端等于推倒重来。Higress 在生成 DestinationRule 时按协议分情况case provider.McpSSEProtocol: return v1alpha3.DestinationRule{ Host: host, TrafficPolicy: v1alpha3.TrafficPolicy{ LoadBalancer: ...ConsistentHash{...UseSourceIp: true...}SSE 服务挂上源 IP 一致性哈希同一个客户端永远落到同一台后端HTTPS 服务则自动补一条 TLS 策略。协议差异在这里被抹平写配置的人不用关心。 跑起来看看三步本地验证git clone https://gitcode.com/GitHub_Trending/hi/higress cd higress helm install higress -n higress-system higress.io/higress --create-namespace然后照着 samples/mcp/ 里的环境脚本搭一个带 Nacos 的 demokind 集群加几个 yaml脚本都在samples/mcp/environment/scripts/下。MCP 端点路径是/{base-path}/{mcp-server-name}base path 在higress-system命名空间higress-configConfigMap 的mcpServer段配置。验证下发是否到位最快的是看日志kubectl -n higress-system logs deployment/higress-controller | grep subscribe mcp server success看到 dataId 出现说明监听、转换、缓存这条链路已经跑通再curl -N打一下 SSE 端点就能拿到工具列表。收个尾回到开头那个 404它只可能断在三跳之一——没订阅上看subscribe日志、协议不支持supportedProtocols白名单、或者资源没进缓存看UpdateConfigCache日志。断点基本都在这条链路上定位起来不用满仓库翻。想继续往下走从 docs/architecture.md 的 Discovery 和 Config Controller 部分读起再回头看这份 watcher会顺很多。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
