首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >别人花 3 个月重写,我花了 3 天配网关:老系统零改造对接 AI 的野路子

别人花 3 个月重写,我花了 3 天配网关:老系统零改造对接 AI 的野路子

作者头像
HELLO程序员
发布2026-07-28 11:35:10
发布2026-07-28 11:35:10
660
举报

你的企业有多少套老系统?ERP、OA、CRM、自研后台……光登录密码就得记七八个。当大模型浪潮袭来,所有人都说要“拥抱 AI”,但看着这些跑了十年、百万行代码的存量系统,到底怎么拥抱?重写?不可能。改接口?牵一发动全身。本文用一次真实项目经验告诉你:不用改一行存量代码,三天内让所有老系统对 AI 对答如流。

一、一个真实的场景

某天,公司技术负责人找到我:“我们有个想法,能不能让 AI 直接查库存、下订单、看报表?就像跟人聊天一样。”

我说:“当然可以,这不就是 AI Agent 嘛。”

他眼睛一亮,随即又黯淡下来:“但问题是——我们的进销存系统是七八年前做的,接口倒是齐全,50 多个 REST API,有 GET 有 POST,有的要 Token 鉴权,有的要路径参数,有的 POST body 里还嵌套了复杂的查询条件……难道要重写?”

“不用重写,”我说,“我们刚验证完一条路,三天出活,老系统一行不改。”

他半信半疑。三天后,他的 AI 助手已经能说:“好的,我帮你查一下今天的库存”了。

二、老系统的“原罪”

如果你在传统企业做技术,下面的场景一定不陌生:

  • 公司十年前上了一套管理系统,稳定运行,但技术栈是 Java 8 + Spring MVC,连文档都不全
  • 每个接口都有自己的脾气:有的 POST 返回 JSON,有的 GET 返回 XML,有的连 Content-Type 都不写
  • 鉴权方式五花八门:Bearer Token、Cookie Session、自定义 Header、甚至有个接口直接把用户名密码拼在 URL 里
  • 查询接口的请求体里嵌套了三层 GroupListWhereListWhereField,结构复杂得像俄罗斯套娃
  • 每当有人问“能不能对接 AI”,你都想说:能,前提是给我 6 个月和 10 个人

这就是传统企业数智化转型的最大堵点:不是不愿意 AI 化,而是历史包袱太重,改不动。

三、思路转个弯:不改代码,改协议

回到正题。我们是怎么做到“三天出活,一行不改”的?

答案出奇的简单——让网关替你翻译。

想象这个场景:你和外国客户开会,中间坐了个翻译。你说中文,翻译翻成英文;客户说英文,翻译翻回中文。你和客户都无需学对方的语言。

在 AI 领域,这个“翻译”的角色就叫 MCP(Model Context Protocol,模型上下文协议)。它是 Anthropic 于 2024 年 11 月开源的协议,目标是成为 AI 世界的“通用语”——不管你底层是什么系统,包装成 MCP 之后,任何 AI 工具都能用同一套语言跟你对话。

而我们选择的“翻译官”,是 Higress 网关。它能自动把 AI 说的 MCP 语言,翻译成你的老系统听得懂的 HTTP 请求。

一句话说清楚这个方案:给老系统前面加一个网关,一行代码不改,零部署变更,0 成本让 AI 读懂你的老系统。

四、架构全景:三个组件搭一座桥

4.1 整体架构

代码语言:javascript
复制
┌─────────────────────────────────────────────────────────────────────┐
│                         AI 平台(控制面)                              │
│                                                                     │
│    ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐   │
│    │ API 服务    │  │ MCP Server  │  │ MCP Tool   │  │ 产品/订阅   │   │
│    │ 管理       │  │ 管理        │  │ 管理       │  │ 管理       │   │
│    └──────┬─────┘  └──────┬─────┘  └──────┬─────┘  └──────┬─────┘   │
│           │               │               │               │          │
│           └───────────────┴───────────────┘               │          │
│                           │                               │          │
│             Nacos AI Admin API (/v3/admin/ai/*)            │          │
│                           │                               │          │
│           ┌───────────────┴───────────────┐               │          │
│           │     Nacos AI Registry 写入     │◄──────────────┘          │
│           │  · mcp-server (元数据)         │   产品 upsert / 订阅审批  │
│           │  · mcp-tools (工具定义)        │                          │
│           │  · mcp-server-versions        │                          │
│           │  · mcp-endpoints (自动生成)    │                          │
│           └───────────────┬───────────────┘                          │
└───────────────────────────┼──────────────────────────────────────────┘
                            │
                            ▼
              ┌─────────────────────────┐
              │   Higress AI 网关        │
              │  · 自动发现 Nacos MCP    │
              │  · 协议转换 HTTP ↔ MCP   │
              │  · 暴露 SSE 端点:        │
              │    /mcp/{name}/sse       │
              └────────────┬────────────┘
                           │
                           ▼
              ┌─────────────────────────┐
              │   存量 REST API 服务     │
              │   (Nacos Naming 实例)    │
              │   /api/order/query      │
              │   /api/inventory/list   │
              └─────────────────────────┘

4.2 三个组件的职责

组件

角色

一句话

Nacos 3.2

登记处 + AI 注册中心

记录“老系统在哪、有哪些接口、怎么调用”

Higress 2.2

翻译官 + AI 网关

接收 MCP 指令,翻译成 HTTP 请求发给老系统

Redis 7

会话本

维护 SSE 长连接的会话状态

4.3 一次调用的完整数据流

当 AI Agent 说“帮我查一下产品 P001 的库存”时,背后发生了什么?

  1. Agent 发起 MCP tools/call 请求 → Higress 的 SSE 端点 /mcp/{name}/sse
  2. Higress 从 Nacos AI Registry 查到 Tool 的定义(URL、方法、参数映射方式)
  3. Higress 按 Tool 定义组装 HTTP 请求:URL 填 /api/inventory/query,method 填 POST,body 填 {"productCode":"P001"}
  4. Higress 通过 Nacos Naming 服务发现,找到老系统的实际 IP:Port
  5. 调用老系统 REST API,拿到响应 {"stock": 150, "warehouse": "A01"}
  6. Higress 将响应包装成 MCP 协议格式,返回给 Agent

全程老系统一行代码没改,它甚至不知道自己被 MCP 化了。

五、动手!完整部署指南

5.1 Docker Compose 一键部署

下面是可以直接复制使用的 docker-compose.yml

代码语言:javascript
复制
version: "3.8"
services:
  # Redis 7: MCP 会话保持
  redis:
    image: redis:7-alpine
    container_name: mcp-redis
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    command: redis-server --appendonly yes
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5
    restart: unless-stopped
    networks:
      - mcp-net

  # Nacos 3.2: 配置中心 + AI Registry + Naming
  nacos:
    image: nacos/nacos-server:v3.2.0
    container_name: mcp-nacos
    ports:
      - "8848:8848"  # API
      - "9848:9848"  # gRPC
      - "8081:8080"  # 控制台
    environment:
      - MODE=standalone
      - NACOS_AUTH_ENABLE=true
    volumes:
      - nacos-logs:/home/nacos/logs
    restart: unless-stopped
    networks:
      - mcp-net

  # Higress 2.2: AI 网关
  higress:
    image: higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/all-in-one:2.2.0
    container_name: mcp-higress
    ports:
      - "8001:8001"  # 控制台
      - "8088:8080"  # HTTP 网关 ⚠️ 注意容器内是 8080,映射到 8088
    environment:
      - REDIS_ADDR=redis:6379
    volumes:
      - ./higress-data:/data  # ⚠️ 必须持久化,否则重启配置丢失
    depends_on:
      nacos:
        condition: service_started
      redis:
        condition: service_healthy
    restart: unless-stopped
    networks:
      - mcp-net

volumes:
  redis-data:
    driver: local
  nacos-logs:
    driver: local

networks:
  mcp-net:
    driver: bridge

部署后立即验证的 4 件事:

#

验证项

怎么做

1

Nacos 控制台可登录,左侧有 MCP 菜单

浏览器打开 http://localhost:8081

2

Higress 控制台可打开

浏览器打开 http://localhost:8001

3

Redis 可达

redis-cli ping 返回 PONG

4

Higress 能连通 Nacos

进入 Higress 容器执行 curl nacos:8848/nacos

5.2 打通 Higress 与 Nacos Registry

Higress 控制台 → 服务来源 → 添加 Nacos 3.x,指向同一个 Nacos 实例。这一步不配,后续所有 SSE 端点都会 404。

六、三步落地:让老系统“开口说话”

第一步:登记老系统——让它有个“身份证”

老系统要先注册到 Nacos Naming,Higress 以后才能通过服务发现找到它:

代码语言:javascript
复制
# 先获取 Nacos 的访问 Token
NACOS_TOKEN=$(curl -s -X POST "http://localhost:8848/nacos/v1/auth/login" \
  -d "username=nacos&password=nacos" | jq -r '.accessToken')

# 把老系统注册为 Nacos 服务实例
curl -X POST "http://localhost:8848/nacos/v1/ns/instance" \
  -H "Authorization: Bearer ${NACOS_TOKEN}" \
  -d "serviceName=my-old-system" \
  -d "groupName=DEFAULT_GROUP" \
  -d "ip=192.168.1.100" \
  -d "port=8081" \
  -d "ephemeral=false"

这一步就像给老系统发了一张身份证。服务名 my-old-system 是之后所有配置的“锚点”,MCP Server 和 Tool 都要引用它。

第二步:创建 MCP Server——告诉网关“我要监控这个系统”

在 Nacos 控制台 → MCP 管理 → 创建 MCP Server,填写:

代码语言:javascript
复制
{
  "name": "my-old-system",
  "description": "老系统业务查询服务",
  "protocol": "mcp",
  "version": "1.0.0",
  "exportPath": "/sse",
  "mcpSpecificationVersion": "1.0",
  "remoteServerConfig": {
    "serviceProtocol": "HTTP",
    "serviceRef": "my-old-system:1.0.0",
    "exportPath": "/sse"
  }
}

几个关键字段说明:

字段

含义

为什么重要

name

MCP Server 名称

决定 SSE 入口 URL:/mcp/{name}/sse,不能包含中文

remoteServerConfig.serviceRef

引用第一步注册的 Naming 服务名

格式 {服务名}:{版本},让 Higress 知道去哪里找老系统

exportPath

固定 /sse

告诉 Higress 用 SSE 方式暴露

第三步:创建 Tool——把每个接口翻译成 MCP 工具

这是最关键的一步。每个存量接口都需要配一个 Tool,Tool 包含两层信息:

A. 给 AI 看的(Agent 契约)——告诉 AI 这个工具叫什么、接受什么参数:

代码语言:javascript
复制
{
  "name": "query_inventory",
  "description": "根据产品编码查询当前库存数量",
  "args": [
    { "name": "productCode", "type": "string", "description": "产品编码", "required": true },
    { "name": "page", "type": "number", "description": "页码,从1开始" }
  ]
}

B. 给网关看的(HTTP 转发)——告诉网关怎么把 MCP 请求翻译成 HTTP 调用。

根据老系统接口的不同风格,有四种常见配置模式:

模式一:简单 GET 查询

代码语言:javascript
复制
{
  "url": "/api/health/check",
  "method": "GET"
}

适用于无参数的健康检查、系统状态类接口。

模式二:GET + 参数自动转 Query

代码语言:javascript
复制
{
  "url": "/api/inventory/get",
  "method": "GET",
  "argsToUrlParam": true
}

网关会自动把 Agent 传入的参数拼到 URL 后面:/api/inventory/get?productCode=P001&page=1

模式三:POST JSON Body

代码语言:javascript
复制
{
  "url": "/api/order/create",
  "method": "POST",
  "argsToJsonBody": true,
  "headers": [
    { "key": "Content-Type", "value": "application/json" }
  ]
}

Agent 传入的参数会自动序列化成 JSON 放在请求体里。

模式四:路径参数 + 自定义 Body 模版

这是最灵活的模式,适用于复杂的查询接口——比如老系统的查询条件嵌套了三层 JSON 结构:

代码语言:javascript
复制
{
  "url": "/users/{{ .args.userId }}/status",
  "method": "PUT",
  "body": "{\"status\":\"{{ .args.status }}\",\"remark\":\"{{ .args.remark }}\"}",
  "headers": [
    { "key": "Content-Type", "value": "application/json" }
  ]
}

{{ .args.xxx }} 是 Go Template 语法,网关会自动把 Agent 传的参数填充进去。URL 里的 {{ .args.userId }} 会被替换成实际值,请求体同理。

创建完成后,别忘了“发布为最新版本”

这一点是新手最容易踩的坑:配完 Tool 之后,Nacos 不会自动生效,必须回到 MCP Server 页面点「发布为最新版本」。 不点这步,Higress 读到的永远是旧配置。

七、进阶:用自建平台驱动,告别手动配置

到这里,你已经掌握了核心原理和手动操作流程。但如果你面对的是 50 个接口、10 个老系统、需要反复调整 Tool 配置的场景,每次都在 Nacos 控制台里手写 JSON 显然不现实。

我们做了一件事:把上面所有手动步骤,封装成了一个自建平台,用 Java 后端 + Vue 前端驱动整个流程。

下面我拆解这个平台是怎么设计的,以及它如何把“三天出活”变成“十分钟出活”。

7.1 平台整体架构

自建平台在原有三件套(Nacos + Higress + Redis)之上,增加了一个 控制面,负责:

  • 把老系统信息录入数据库,一键注册到 Nacos Naming
  • 可视化配置 MCP Server 和 Tool,不用手写 JSON
  • 调用 Nacos AI Admin API 自动发布,不用手动点「发布为最新版本」
  • 同步到产品市场,让 AI 工具用户可以订阅和发现
代码语言:javascript
复制
┌──────────────────────────────────────────────────────────────────┐
│                      自建平台(控制面)                             │
│                                                                  │
│  ┌────────────────────┐  ┌────────────────────┐                   │
│  │   Vue 前端          │  │   Java 后端          │                   │
│  │  · ApiServiceList   │  │  · McpServerService  │                   │
│  │  · McpServerList    │  │  · ApiServiceService │                   │
│  │  · McpServerDetail  │  │  · NacosAiAdminClient│                   │
│  │  · ToolEditor       │  │  · McpProductSyncApi │                   │
│  └────────┬───────────┘  └──────────┬───────────┘                   │
│           │                         │                              │
│           │    REST API              │  调用 Nacos AI Admin API     │
│           │   /api/mcp/*             │  /v3/admin/ai/mcp            │
│           │                         │                              │
│           └─────────────┬───────────┘                              │
│                         │                                          │
│              ┌──────────┴──────────┐                               │
│              │    MySQL 数据库      │                               │
│              │  · api_service       │                               │
│              │  · mcp_server        │                               │
│              │  · mcp_tool          │                               │
│              │  · product           │                               │
│              └─────────────────────┘                               │
└──────────────────────────────────────────────────────────────────┘

7.2 数据模型:三张表管好一切

平台的核心数据模型只有三张表,对应三个实体类:

ApiService(老系统登记表)

代码语言:javascript
复制
字段            说明
─────────────────────────────────
name            老系统展示名称,如“进销存系统”
nacosServiceName  Nacos Naming 服务名,如“inventory-api”
host            老系统 IP 地址
port            老系统端口
healthCheckPath 健康检查路径,如 /api/health
status          状态:已注册 / 未注册

这张表是“老系统的身份证”。录入后,平台会调用 Nacos Naming API 自动注册服务实例,不用手动 curl。

McpServer(MCP 服务定义表)

代码语言:javascript
复制
字段            说明
─────────────────────────────────
name            MCP Server 名称,决定 /mcp/{name}/sse
fromType        来源类型:HTTP_TO_MCP / NATIVE_MCP
apiServiceId    关联哪个老系统
protocol        sse / streamable
version         版本号,固定 1.0.0
status          0=草稿  1=已发布  2=已下线
exposeUrl       对外暴露的 SSE URL
productId       关联的产品市场 ID

McpTool(工具定义表)

代码语言:javascript
复制
字段            说明
─────────────────────────────────
serverId        关联哪个 MCP Server
name            Agent 看到的工具名称
description     工具描述
argsJson        入参定义 JSON
httpMethod      GET/POST/PUT/DELETE
path            接口相对路径
argMapping      参数映射方式:url_param/json_body/form_body/body
headersJson     请求头配置
requestBody     自定义请求体模版

7.3 发布链路:从点击“发布”到 Nacos 写入,一条代码流

这是整个平台最核心的逻辑——McpServerService.publish() 方法。当用户在平台上点击“发布”按钮时,后端执行以下编排:

代码语言:javascript
复制
publish()
  ├── Step 1: 校验 MCP 名称合法性
  │     ↳ 只允许英文、数字、-、_、/、.,最长 128 字符
  │
  ├── Step 2: 校验关联的老系统已注册到 Nacos
  │     ↳ 如果还没注册,自动调用 ApiServiceService.register() 注册
  │
  ├── Step 3: 查询该 Server 下所有 Tool
  │     ↳ SELECT * FROM mcp_tool WHERE server_id = ?
  │
  ├── Step 4: 组装三份 Nacos Spec JSON
  │     ├── buildServerSpecification() → mcp-server.json
  │     │     { name, description, protocol, version,
  │     │       remoteServerConfig: { serviceRef, serviceProtocol } }
  │     │
  │     ├── buildToolSpecification() → mcp-tools.json
  │     │     遍历每个 Tool,组装扁平 HTTP 配置:
  │     │     { url, method, headers, argsToUrlParam/argsToJsonBody/body, ... }
  │     │
  │     └── buildEndpointSpecification() → mcp-endpoints.json
  │           { exportPath: "/sse", ... }
  │
  ├── Step 5: 调用 NacosAiAdminClient 写入 Nacos AI Registry
  │     ↳ createMcpServer(serverSpec, toolSpec, endpointSpec)
  │     ↳ 底层调用 Nacos 3.2 的 /v3/admin/ai/mcp 接口
  │
  ├── Step 6: 生成对外暴露的 SSE URL
  │     ↳ exposeUrl = "http://{gateway}:8088/mcp/{name}/sse"
  │
  ├── Step 7: 同步到产品市场
  │     ↳ McpProductSyncApi.upsert() → 创建/更新 product 记录
  │     ↳ 用户可以在产品市场看到这个 MCP Server,申请订阅
  │
  └── Step 8: 更新数据库状态
        ↳ mcp_server.status = 1(已发布)

关键代码片段(Step 4,组装 Tool 的扁平 HTTP 配置):

代码语言:javascript
复制
private JSONObject buildFlatHttpConfig(McpTool tool) {
    JSONObject config = new JSONObject();
    config.put("url", tool.getPath());
    config.put("method", tool.getHttpMethod());

    // 参数映射方式
    switch (tool.getArgMapping()) {
        case "url_param":   config.put("argsToUrlParam", true);  break;
        case "json_body":   config.put("argsToJsonBody", true);  break;
        case "form_body":   config.put("argsToFormBody", true);  break;
        case "body":        config.put("body", tool.getRequestBody()); break;
    }

    // 请求头
    if (StrUtil.isNotBlank(tool.getHeadersJson())) {
        config.put("headers", JSON.parseArray(tool.getHeadersJson()));
    }
    return config;
}

关键代码片段(Step 5,写入 Nacos AI Registry):

代码语言:javascript
复制
public void publish(McpServer server) {
    // 组装三份 Spec
    String serverSpec = buildServerSpecification(server);
    String toolSpec = buildToolSpecification(tools);
    String endpointSpec = buildEndpointSpecification(server);

    // 一键写入 Nacos
    nacosAiAdminClient.createMcpServer(serverSpec, toolSpec, endpointSpec);

    // 生成 exposeUrl
    String exposeUrl = String.format("http://%s:%d/mcp/%s/sse",
        gatewayHost, gatewayPort, server.getName());

    // 同步产品市场
    productSyncApi.upsert(Product.builder()
        .type("mcp_server")
        .name(server.getName())
        .exposeUrl(exposeUrl)
        .build());

    // 更新状态
    server.setStatus(1);
    mcpServerMapper.updateById(server);
}

7.4 下线链路:同样一键完成

发布有发布流程,下线也有对应的清理逻辑:

代码语言:javascript
复制
offline()
  ├── 1. 调用 NacosAiAdminClient.deleteMcpServer() 删除 Nacos 中的 MCP 声明
  ├── 2. 产品置为下架(status=inactive)
  └── 3. 更新 mcp_server.status = 2(已下线)

7.5 前端体验:一个页面搞定所有操作

自建平台的前端用 Vue 3 + Arco Design 实现,核心里有三个页面:

页面一:API 服务管理(ApiServiceList.vue)

一个表格页面,列出所有已登记的老系统。每条记录显示名称、Nacos 服务名、IP:端口、健康检查路径、注册状态。操作按钮包括:

  • 注册到 Nacos:一键调用 ApiServiceService.register(),把老系统实例注册到 Nacos Naming
  • 用此服务创建 MCP:直接跳转到 MCP Server 新建页面,自动关联这个老系统

页面二:MCP Server 列表(McpServerList.vue)

卡片式布局,每张卡片展示一个 MCP Server 的名称、服务名、类型标签(存量 REST / 原生 MCP)、协议、状态。顶部有搜索框和筛选器,支持按名称、类型、状态过滤。操作按钮:

  • 配置 Tools:进入详情页编辑工具
  • 发布:一键执行上面那条完整的 publish 链路
  • 下线:一键清理 Nacos 数据 + 产品下架
  • 预览 Nacos Spec:在发布前预览即将写入 Nacos 的三份 JSON,确认无误再发布——这个功能救了我们很多次

页面三:MCP Server 详情(McpServerDetail.vue)

这是最复杂的页面,分成三个区域:

  • 顶部:基础信息面板(名称、关联服务、协议、版本)
  • 中间:进度步骤条(关联上游 → 配置 Tools → 发布上线),引导用户按正确顺序操作
  • 底部:左栏是 Tool 列表,右栏是 Tool 编辑器。在编辑器中,你可以:
    • 填写 Tool 名称和描述
    • 选择 HTTP 方法和参数映射方式
    • 配置请求头(支持 Nacos 配置引用语法)
    • 编写入参定义
    • 预览生成的 Nacos JSON

7.6 从手动到自动:效率提升了多少?

操作

Nacos 控制台手动

自建平台驱动

登记老系统

复制 curl 命令,改 IP 和端口

表单填写,点保存

注册到 Nacos Naming

跑 curl 命令,注意 Token

点「注册到 Nacos」按钮

创建 MCP Server

手写 JSON,注意字段名不能错

表单填写,自动校验

创建 Tool

手写 JSON,含入参定义和 HTTP 转发配置

可视化编辑器,下拉选择

发布

回到 Nacos 点「发布为最新版本」

点「发布」按钮,一键完成

修改 Tool

重新写 JSON,重新发布

编辑表单,重新发布

下线

手动删除 Nacos 配置

点「下线」按钮,自动清理

预览 Nacos Spec

点「预览」看即将写入的 JSON

最关键的差异:手动操作时,你需要在 Nacos 控制台和 curl 命令之间反复横跳;平台驱动下,所有操作都在一个页面里完成,发布链路是事务性的——要么全部成功,要么全部回滚。不会出现“Nacos 写进去了但产品表没同步”这种半吊子状态。

7.7 平台的一个隐藏功能:预览 Nacos Spec

在真正发布之前,平台提供了一个 previewNacosSpec() 接口,可以预览即将写入 Nacos 的三份完整 JSON,但不实际调用远端。这个功能在调试阶段极其有用——你可以在数据库里把 Tool 配好,点「预览」看一眼生成的 JSON 对不对,确认无误再点「发布」。

代码语言:javascript
复制
# 预览接口
GET /api/mcp/servers/{id}/preview-nacos-spec

# 返回三份 JSON:
{
  "serverSpec": { ... },
  "toolSpec": { ... },
  "endpointSpec": { ... }
}

八、老系统鉴权:三种方案,总有一种适合你

80% 的存量系统都有鉴权,而且很多系统的 Token 每两小时就过期一次。如果每次过期都重新配一遍 Tool,那不叫“零改造”,叫“换了个地方折腾”。

我们经过验证,推荐三种方案:

方案

做法

优点

缺点

适用场景

固定 Token

Tool headers 里直接写死 Bearer xxx

最快上手

Token 过期需重新发布

POC 验证

Nacos 配置引用

Token 存 Nacos 配置中心,Tool 里用 ${nacos.xxx} 引用

热更新、无需重新发布

需要多维护一个配置项

推荐

Token 中转服务

旁路代理自动刷新 Token

全自动

架构复杂

生产环境

推荐方案(Nacos 配置引用)的具体操作:

  1. 在 Nacos 配置管理里新建一个配置,DataId = my-token,Group = DATA,内容为:
代码语言:javascript
复制
{ "token": "eyJhbGciOiJIUzI1NiIs..." }
  1. 在 Tool 的 headers 里引用这个配置:
代码语言:javascript
复制
{
  "headers": [
    { "key": "Content-Type", "value": "application/json" },
    { "key": "Authorization", "value": "Bearer {{ ${nacos.my-token/DATA}.token }}" }
  ]
}
  1. Token 过期时,只需更新 Nacos 里的配置内容,网关会自动读到最新值,不用重新发布任何东西。 对业务完全无感。

这里有两个语法细节要注意:

  • ${nacos.dataId/group} 是 Nacos 配置引用语法,注意中间是 / 不是 .
  • {{ {nacos.xxx}.token }} 的外层 {{ }} 是 Go Template 变量语法,里层 {nacos.xxx} 是 Nacos 取值语法,不要写反

九、验证:亲眼看到 AI 调用你的老系统

8.1 验证 SSE 端点

代码语言:javascript
复制
curl -N http://localhost:8088/mcp/my-old-system/sse

正常输出应该看到 endpointsessionId 和定时 ping 心跳。如果只看到 ping 没有业务数据,这是正常的——真实业务数据需要通过 MCP tools/call 触发。

8.2 用 MCP Inspector 图形化调试

MCP Inspector 是官方提供的调试工具,可以图形化地查看工具列表和调用结果:

代码语言:javascript
复制
npx @modelcontextprotocol/inspector
# 在弹出的界面中:
# Transport 选择 SSE
# URL 填 http://localhost:8088/mcp/my-old-system/sse

连接成功后,你应该看到:

  • Tools 列表query_inventorycreate_order 等你配置的工具
  • 点击某个 Tool:可以填入参数,点击 Call,看到老系统返回的真实业务数据

8.3 接入 AI 编程工具(以 CodeBuddy 为例)

在 IDE 的 MCP 配置文件中添加:

代码语言:javascript
复制
{
  "mcpServers": {
    "my-old-system": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-proxy", "http://localhost:8088/mcp/my-old-system/sse"]
    }
  }
}

重启 IDE 后,你就能在对话中直接触发工具调用:

调用 my-old-system 的 query_inventory 工具,查询产品 P001 的库存信息。

AI 助手会返回老系统查到的真实数据。

十、踩坑血泪史:这些地方最容易翻车

以下是 POC 验证过程中踩过的坑,每一个都浪费了至少半小时:

#

现象

根因

正确做法

1

SSE 端点 404

端口映射写成了 8088:8088,但容器内网关端口是 8080

映射必须写 8088:8080

2

重启容器后服务列表为空

All-in-One 镜像不支持 Nacos 做配置存储

挂载 -v ./higress-data:/data 持久化

3

Nacos 里改了配置,调用还是旧的

改完没点「发布为最新版本」

每次修改完必须点发布

4

SSE 端点只返回 ping

正常现象,不是错误

用 MCP Inspector 做 tools/call 验证

5

requestTemplate.url 填了完整 URL 报错

只能填相对路径,如 /api/xxx

真实地址靠 Naming 服务发现的 IP:Port

6

Higress 服务列表为空

没在 Higress 控制台添加 Nacos 服务来源

控制台 → 服务来源 → 添加 Nacos 3.x

7

tools/call 返回 401

Token 过期或模版引用语法错误

检查 ${nacos.xxx/DATA} 语法,注意是 / 不是 .

8

容器内连通性失败

安全组/防火墙未放行

确保 Higress 容器能访问 Nacos 8848 端口

十一、上手路线图:从 0 到 1 怎么走

如果你现在就想开始,建议按这个节奏推进:

第一周:基础设施 + 跑通一个接口

  • 用 Docker Compose 部署 Nacos 3.2 + Higress 2.2 + Redis 7
  • 在 Higress 控制台添加 Nacos 服务来源
  • 把老系统注册到 Nacos Naming
  • 选一个最简单的接口(比如 GET 无参数的健康检查),配成 MCP Tool
  • 发布版本,用 curl 验证 SSE 端点是否可达

目标:亲眼看到 AI 调用了你的老接口并返回了正确数据。

第二周:批量覆盖 + 鉴权

  • 把老系统的核心接口逐一配成 Tool
  • 处理 Token 鉴权:用 Nacos 配置引用方案,让 Token 热更新
  • 用 MCP Inspector 验证每个 Tool 的调用结果

目标:50 个接口全部接入,AI 能完成 80% 的日常查询。

第三周:接入 AI 工具 + 收尾

  • 接入 CodeBuddy / Cursor 等 AI 编程工具
  • 整理调用示例,输出给业务团队
  • 可选:把 MCP 发布到产品市场,支持订阅审批

十二、投入产出比:这笔账怎么算?

我们算一笔保守的账:

方案

时间

人力

风险

后续维护

重写或改造老系统

3-6 个月

5-10 人

高(牵一发动全身)

手写 MCP Server

每接口约 0.5 天

2-3 人

中(维护成本高)

网关声明式转换

3 天

1 人

低(不改业务代码)

对于有 50 个接口的存量系统,网关方案能省下 90% 以上的时间和人力

更关键的是 零风险:不需要改老系统一行代码,不存在“改坏了回不去”的担心。最坏的情况,删掉 Nacos 里的配置,老系统恢复原样,AI 助手不再能调用它而已。

十三、给技术负责人的三条建议

如果你正在考虑让传统系统接入 AI,这三条建议请收好:

1. 不要一上来就想“重构”

传统企业最怕听到“重构”两个字。一个跑了好几年没出过问题的系统,谁敢动?网关方案的最大优势就是不碰存量代码——你只管加一层“翻译层”,出问题随时可以关掉。

2. 先跑通一个接口,再谈全面铺开

选一个最简单的接口——比如“查询当前用户信息”这种 GET 请求——先跑通端到端。等你亲眼看到 AI 真的调用了你的老接口并且返回了正确数据,再决定要不要批量铺开。我们就是这么做的,从第一个接口到 50 个接口,后面的复制粘贴十分钟一个。

3. 把 Token 管理做成可配置的

不要图省事把 Token 写死在配置里。用 Nacos 的配置引用功能,让 Token 可以随时更新。这是从 POC 到生产最关键的细节,也是后续运维成本最低的做法。

十四、写在最后

2024 年 11 月 MCP 协议问世以来,AI 行业最大的变化不是模型本身,而是 连接方式。以前我们教 AI 理解世界,现在我们给 AI 接入世界。

对于传统企业来说,数智化转型最大的障碍从来不是“技术不够先进”,而是“历史包袱太重,改不动”。

好在,我们找到了不改代码的办法。

你的老系统,在等 AI 敲门。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 HELLO程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、一个真实的场景
  • 二、老系统的“原罪”
  • 三、思路转个弯:不改代码,改协议
  • 四、架构全景:三个组件搭一座桥
    • 4.1 整体架构
    • 4.2 三个组件的职责
    • 4.3 一次调用的完整数据流
  • 五、动手!完整部署指南
    • 5.1 Docker Compose 一键部署
    • 5.2 打通 Higress 与 Nacos Registry
  • 六、三步落地:让老系统“开口说话”
    • 第一步:登记老系统——让它有个“身份证”
    • 第二步:创建 MCP Server——告诉网关“我要监控这个系统”
    • 第三步:创建 Tool——把每个接口翻译成 MCP 工具
    • 创建完成后,别忘了“发布为最新版本”
  • 七、进阶:用自建平台驱动,告别手动配置
    • 7.1 平台整体架构
    • 7.2 数据模型:三张表管好一切
    • 7.3 发布链路:从点击“发布”到 Nacos 写入,一条代码流
    • 7.4 下线链路:同样一键完成
    • 7.5 前端体验:一个页面搞定所有操作
    • 7.6 从手动到自动:效率提升了多少?
    • 7.7 平台的一个隐藏功能:预览 Nacos Spec
  • 八、老系统鉴权:三种方案,总有一种适合你
  • 九、验证:亲眼看到 AI 调用你的老系统
    • 8.1 验证 SSE 端点
    • 8.2 用 MCP Inspector 图形化调试
    • 8.3 接入 AI 编程工具(以 CodeBuddy 为例)
  • 十、踩坑血泪史:这些地方最容易翻车
  • 十一、上手路线图:从 0 到 1 怎么走
    • 第一周:基础设施 + 跑通一个接口
    • 第二周:批量覆盖 + 鉴权
    • 第三周:接入 AI 工具 + 收尾
  • 十二、投入产出比:这笔账怎么算?
  • 十三、给技术负责人的三条建议
  • 十四、写在最后
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档