DubboTester 2.1.3：一站式搞定 Dubbo 接口调试、压测、MCP 与 HTTP

我们在接口测试或调试中要调一个 Dubbo 接口，要先找接口 JAR、准备 Java 环境、写一段调用代码，再研究复杂对象怎么构造？临时测一下性能，还要换工具、写脚本？想让 AI 或其他语言调用现有接口，又得加一层适配服务？

DubboTester 想把这些事情变简单：选中服务方法，示例参数自动生成，直接调用；需要压测、MCP 或 HTTP 时，在同一套工具里继续完成。

它面向开发、测试和联调场景，既可以通过 Docker 部署成 Web 工具，也可以直接使用 Windows、macOS 桌面版。不需要导入业务 JAR，不需要安装 Java 环境，也不需要为了调试去修改业务服务。

docker一键部署，全组同事直接使用。

图 1：一次完整的 Dubbo 调用。选择方法 add，发送 [1, 2] （参数自动生成），直接得到结果 3。

项目地址：GitHub · lulianqi/DubboTester
桌面版下载：GitHub Releases
Docker 镜像：Docker Hub · lulianqi/dubbo-tester

如果您想要快速体验DubboTester的功能，可以直接使用 https://dubbo.lulianqi.com/ （该地址仅用于体验）

本文按 DubboTester 2.1.3 演示。界面图片来自实际操作；压测数据只用于说明操作流程，不代表工具或业务服务的性能上限。文中的注册中心属于演示环境，请替换为你有权限访问的环境，不要将其作为公共压测目标。

一、它能做什么，适合谁用？

DubboTester 的核心不是增加一套新的接入流程，而是把已有 Dubbo 服务直接用起来。

我更想突出它的三个特点。

第一，使用简单。 常规流程就是“配置注册中心 → 选择方法 → 发送请求”。有元数据时，工具会读取签名、展示复杂参数结构并生成示例，不必拿着接口定义从零拼 JSON。

第二，功能衔接完整。 调通的请求可以直接带入压测；同一个 Dubbo 方法也可以配置成 MCP 工具或 HTTP 接口，不需要为每一种用途重新开发适配层。

第三，跨平台、使用方式灵活。 个人电脑可以使用 Windows x64 或 macOS 桌面版；服务器可以使用支持 linux/amd64、linux/arm64 的 Docker 镜像，团队通过浏览器访问。

这里的“无需依赖”主要指无需业务工程、接口 JAR 和 Java 运行环境。它仍然需要能连到注册中心和 Provider。业务调用使用 Dubbo2 协议的泛化调用，不能把它理解为对 Triple/gRPC 等所有协议都无条件支持。自动参数结构和示例则依赖可用的元数据。

二、获取与安装：Docker 优先，也可以直接用桌面版

2.1 Docker：拉取镜像即可启动

本机体验或云端部署都可以直接运行下面两条命令（推荐Docker部署模式使用）。这里固定使用 2.1.3，避免 latest 后续变化影响复现。

docker pull lulianqi/dubbo-tester:2.1.3

docker run -d \
  --name dubbo-tester \
  --restart unless-stopped \
  -p 127.0.0.1:5154:8080 \
  -v dubbo-tester-data:/app/App_Data \
  lulianqi/dubbo-tester:2.1.3

启动后，打开：http://localhost:5154/。

这条命令将页面限制在本机访问。团队部署时，可以将端口映射中的 127.0.0.1 换为服务器的可信内网 IP，再通过 http://<服务器内网IP>:5154/ 访问；同时使用防火墙限制来源，或放在受保护的反向代理后面。不要直接把管理页面开放到公网。

几个配置说明：

• 宿主机 5154 映射到容器内 8080。本机端口占用时，可改成 127.0.0.1:5155:8080。
• 数据卷 /app/App_Data 用于持久化 MCP、HTTP 等服务端配置，更新容器时应保留。
• 也可以使用 GHCR 镜像，将镜像名替换为 ghcr.io/lulianqi/dubbo-tester:2.1.3，其他参数不变。
• 容器内必须能访问注册中心和 Provider 公布的地址。容器里的 localhost 指向容器自身，不是宿主机。

镜像地址：Docker Hub、GitHub Container Registry。
阿里云 ACR（中国大陆）：crpi-ct3m45rpep0xlnep.cn-hangzhou.personal.cr.aliyuncs.com/lulianqi/dubbo-tester

docker pull 如果国内镜像源太慢，可以直接使用阿里云 ACR docker pull crpi-ct3m45rpep0xlnep.cn-hangzhou.personal.cr.aliyuncs.com/lulianqi/dubbo-tester:2.1.3

2.2 桌面版：下载、解压、运行

如果不想部署 Docker，可以直接使用桌面版更方便。

1. 打开 最新 Release 页面。
2. 展开页面下方的 Assets。
3. 按操作系统下载对应压缩包，解压后运行应用。

以 2.1.3 为例：

图 2：下载对应平台的应用 ZIP；Source code 是源码包，不是桌面安装包。SHA256SUMS.txt 可用于校验文件完整性。

桌面包是自包含的，不需要另外安装 .NET SDK 或 Java。Windows 解压后运行应用程序；macOS 解压后打开 Dubbo Tester.app，也可以将其移入“应用程序”目录。

当前 macOS 包使用 ad-hoc 签名，尚未经过 Apple 公证。首次打开可能需要在“系统设置 → 隐私与安全性”中确认；请先确认文件来自上述项目 Release，不要为此全局关闭系统安全保护。

桌面版的 MCP、HTTP 服务使用本机 5154 端口，仅监听本机地址。若端口被其他程序占用，应先处理端口冲突；需要给其他机器提供服务时，更推荐部署 Docker 版。

以上为桌面版运行截图，桌面版与云端版功能及操作界面本完全一致，后面不分开介绍，都是一样的

2.3 推荐怎样使用？

• 个人开发、测试：可以使用桌面版。 无需部署，连接自己的测试环境即可开始。（如果已经有docker环境，本地使用镜像部署同样方便）
• 计划长期、团队共享：优先 Docker。 使用固定内网访问地址，方便集中维护；每个使用端保留自己的连接设置和调用草稿。
• 快速验证性能：先调通，再压测。 从小并发、短时长开始，先确认请求和业务断言正确，再逐步增加负载。
• AI 接入：先开放少量只读 MCP 工具。 工具描述要明确，写操作要有额外的业务权限控制。
• 跨语言临时联调：按需开放 HTTP 方法。 用完及时关闭，不要把临时调试入口当作完整的生产 API 网关。

三、最快上手：用一次加法调用认识它

如果你只想先感受一下，记住这三步就够了：

1. 点击顶部设置按钮，填写 ZooKeeper 或 Nacos 地址，点击“保存并刷新”。
2. 在左侧展开服务目录，选择一个方法。
3. 修改自动生成的参数，点击“发送”，在下方查看响应。
   例如选择 DataTypeService 的 add(int, int)，工具会先生成 [0, 0]。将参数改为：

[1, 2]

发送后即可得到 3，对应图 1。整个过程没有导入接口 JAR，也没有编写调用代码。

图 3：元数据可用时，选择方法后可以自动填入参数示例；示例仍然可以自由编辑。（系统会根据元数据中心里参数结构的声明自动生成示例，大大缩短我们构建参数的时间，特别对复杂结构参数非常有效）

下面分别展开四个模块的完整用法。

四、模块一：接口调试——从发现服务到看懂复杂参数

步骤 1：连接注册中心

打开主页顶部的设置按钮，进入“连接与页面设置”。

使用 ZooKeeper 时，选择 ZooKeeper，填写连接地址。本文演示为：

110.40.136.183:2181 如果您使用的是https://dubbo.lulianqi.com/示例网站可以直连该地址

注册目录可以填写 /dubbo 等指定目录；留空或填写 / 时自动扫描一级目录。元数据中心与注册中心共用时，可以不填写单独的元数据中心地址。（如果不是明确知道注册目录名称，建议直接不填，系统会自动获取所有可用服务目录）

图 4：ZooKeeper 配置示例。填写地址、注册目录和必要的超时设置后，点击右下角“保存并刷新”。

如果环境使用 Nacos，切换到 Nacos，填写对应地址即可（切换注册中心类型只需要修改此处，起来都一样）。本文演示地址为：

110.40.136.183:8848  

步骤 2：选中服务和方法

在左侧目录中依次展开注册目录、服务和方法。服务较多时，可以使用搜索框查找服务名或方法名。

选中方法后，重点看三个位置：

• Java 签名：确认方法参数个数、顺序，以及是否选中了正确重载。
• 请求参数：编辑 JSON 请求数据。
• 高级选项：需要时填写服务版本、服务分组、超时或 attachments 等信息。

默认可以通过注册中心发现 Provider 并进行负载均衡；需要定位某一台实例时，也可以切换为直连 Provider，填写主机、端口和精确参数类型。

步骤 3：复杂对象参数构建

复杂对象也不用从空白 JSON 开始，例如 OrderService.searchOrders(OrderQuery)，请求参数是一个业务对象。点击“按结构生成示例”，就能得到对象字段、集合和枚举对应的 JSON 结构：

图 6：复杂对象示例会生成可编辑的字段结构；默认值只是结构示意，发送前仍应替换为符合业务规则的数据。

如果不清楚某个字段的含义或类型，可以点击“参数结构”：

图 7：参数结构中可以查看字段类型和枚举取值，例如订单状态 CREATED、PAID 等。

“按结构生成示例”右侧的竖向 ⋮ 中，有一个默认开启的设置：如果用户数据为空，自动填充示例。

它不会覆盖已经输入的内容或已恢复的参数草稿。无参数方法不自动填充；元数据不可用时，也不会凭空生成参数结构。没有元数据并不代表完全不能调用：知道精确 Java 参数类型时，仍可以手动填写类型和数据进行调试。

几个常用的参数格式：

[]

无参数方法使用 []，也可以留空。

{"id": 1, "name": "demo"}

单个对象参数可以直接填写对象。

["demo", 123, true]

多个参数按方法签名顺序放入外层数组。

[[1, 2, 3]]

单个数组或 List 参数要注意区分“参数列表”和“参数本身的数组”，通常需要再包一层。

步骤 4：发送、查看响应、复用历史

点击“发送”后，下方会显示是否成功、调用耗时和响应正文。右侧历史记录支持再次载入，常用请求可以收藏；请求草稿也会按方法保留，方便刷新或返回后继续调试。

一个非常容易混淆的点：注册目录不等于服务分组。 例如 /dubbo 是服务发现所在的目录，dubbonet-3.3.6 可能才是 Provider 的业务分组。手工切换注册目录后，如果还沿用另一个环境的 group/version，可能出现 Not found exported service。排查时应同时核对目录、Provider、版本、分组和参数签名，而不是只看目录是否存在。

注意：如果使用容器部署，团队的每个人的每个浏览器打开这个网页工作空间都是对立的，也就是每个都可以设置自己的注册中心地址，有自己的操作记录，这些都是独立的

五、模块二：快速压测——调通的请求，直接来一次压测吧

步骤 1：从调试请求进入压测

先在主页调通一次请求，再点击“发送”右侧的小箭头，选择“压力测试”。目标服务、方法、连接信息和请求参数会作为初始值带过去。

步骤 2：设置小负载，先确认请求有效

本文继续使用没有业务写入的 add(1, 2)，配置如下：

图 8：开始前先核对目标、Java 参数类型、版本/分组，以及右侧负载摘要。不要直接把历史大并发配置用于陌生接口。

除了时间上限，也可以选择次数上限，按“并发用户数 × 每用户发送次数”运行。负载均衡模式支持 Random、RoundRobin 等选择；并发用户数旁的设置入口还可以调整 TCP 复用方式。

需要模拟逐步加压时，可以配置阶梯用户数、阶梯启动间隔和用户启动间隔。它们控制的是负载节奏，不是简单地把所有请求在同一时刻发出去。

步骤 3：参数化请求与业务断言

请求模板支持用户序号、发送序号、随机数、随机字符串、GUID、时间等变量，例如：

["user-{{user}}-{{iteration}}", "{{guid}}"]

以上仅说明变量写法，实际参数个数和类型必须匹配目标方法。字符串变量要放在 JSON 引号中；数值变量可以用于数值位置。

如果“RPC 没报错”还不足以代表业务成功，可以在请求模板下添加业务断言，例如检查响应正文、通过 JSONPath 读取字段，并使用等于、包含、数值比较等条件；多个条件可以选择 AND 或 OR。

建议先用“调试断言”验证一段模拟响应。RPC 返回成功，但业务断言不满足，仍然会计入失败请求。 例如返回值是 3，而断言要求等于 99，成功率自然不会是 100%。

步骤 4：启动后实时看指标

确认配置后点击“开始压测”。运行时配置会锁定为不可编辑状态，防止测试途中误改；需要调整时先停止本轮，再启动新一轮。
运行状态中可以看到已执行时长和请求数，目标与负载配置均为灰色锁定状态。

页面会实时更新平均响应时间、TPS、成功率、P95/P99，以及吞吐、响应时间、错误请求和慢请求趋势。

*图 10：压测过程中的实时监控及压测进度 （这里其实可以发现压测进行到一半时TPS就停止了上涨）

读图时可以先关注：

• 成功率：先确认请求有效，再讨论吞吐高不高。
• TPS：单位时间完成的请求数，不等同于“成功业务处理量”。默认包含失败请求。
• 平均响应时间：看总体变化，但不要只盯平均值。
• P95 / P99：分别表示约 95% / 99% 的请求耗时不超过该值，适合观察长尾。
• 错误与慢请求分布：定位异常集中在哪个时间段，以及是否随用户增长而增加。

响应时间、TPS 卡片，以及吞吐趋势、响应时间趋势图，都提供独立的“仅统计成功请求”开关，默认关闭。打开后只改变对应卡片或图表的统计口径，不改变成功率，也不会删除失败请求。

趋势图支持查看采样点、切换平滑区间或统计方式、调整横向时间标尺和放大查看。

步骤 5：看明细，及时导出报告

需要逐条核对时，查看下方“运行明细”；可以筛选状态、耗时和请求/响应内容，并展开单条详情。开启“记录请求&响应”后，会在本轮页面内存中记录正文，便于分析。

图 11：如果出现问题优先关注业务上失败的或耗时的请求 （默认不记录成功的响应内容，可以打开右上角开关）

完成或停止后，可以点击“导出报告”，保存自包含 HTML 报告，便于离线查看和分享。正式测试时建议保留报告，同时记录测试环境、请求样本和负载配置，避免仅凭一张 TPS 截图得出结论。

运行中请勿刷新页面，结果仅保存在当前页面。 压测草稿可以恢复，不代表运行结果会自动长期保存；需要留档时应导出报告。请求/响应正文还存在内存预算，长时间运行后，早期正文可能被清理，统计与基础明细不因此消失。（浏览器中如果打开2个压测页面将会视为2次独立的压测任务空间）

六、模块三：MCP 服务——让现有 Dubbo 方法成为 AI 工具

如果业务能力已经在 Dubbo 中，没必要为了给 AI 使用，再写一套中间服务。DubboTester 可以将选定方法映射为 MCP 工具，通过 Streamable HTTP 提供给支持 MCP 的客户端。

业务服务不需要新增 MCP 依赖，也不需要为了接入 AI 改造接口。对于仍使用历史 Dubbo 版本的系统，这是一种低侵入的接入方式；前提依然是目标服务兼容当前 Dubbo2 调用方式。

步骤 1：进入 MCP 页面，配置独立的连接

点击主页顶部“MCP 服务”，展开“全局配置”。它有自己的注册中心设置，不要以为改了主页连接，后台 MCP 就会自动切换到同一环境。

首次配置时，保持全局开关关闭，填写注册中心、目录、元数据中心和超时等配置；检查后再开启服务。全局开关开启后，连接和鉴权配置会锁定；需要修改时先关闭服务，修改完成后再开启。

图 12：本机 MCP 地址为 http://localhost:5154/mcp。截图为已经启用的本机演示环境，配置处于锁定状态；鉴权关闭不应照搬到对外部署。

步骤 2：选择方法，填写工具说明

在“已配置工具”区域点击“＋ 添加配置”，依次选择：

1. 注册目录；
2. Dubbo 服务；
3. 方法，并确认具体 Java 签名。

或者还有更容易的方法，直接在服务与方法列表上选择添加MCP

然后填写工具名（会自动生成）、方法描述、适用/触发条件、参数要求。工具名可以使用自动生成值；描述则应该认真填写，让 AI 知道“什么时候该调用、该传什么、结果代表什么”。

例如一个加法工具可以这样描述：

方法描述：为公司添加一个新员工
触发条件：当用户想为公司添加一个新员工时触发
参数要求：age为员工年龄，name为员工姓名，roles里为员工其他信息

图 13：新增工具的配置示意。描述应结合业务语义填写，而不是只重复一个 Java 方法名。

可以先用“调试该方法”验证参数，再保存配置并按需启用。“全局开关”和工具自身的启用状态共同决定是否对客户端提供工具；不要把所有写操作无差别开放给 AI。

步骤 3：在 MCP 客户端连接

在支持远程 MCP 的客户端中，新建服务连接：

传输方式：Streamable HTTP
服务地址：http://localhost:5154/mcp  这个地址在全局配置里会自动生成，如果你远程部署了他可能是个域名

如果开启了鉴权，按客户端支持的方式添加请求头：

Authorization: Bearer <你的访问令牌>

不同客户端的配置格式不同，这里不强行套用某一种 JSON。连接后，应只看到已经启用且当前环境可用的工具；使用时遵循客户端获取到的输入 Schema。

上图以vscode的Cline为例

agent如何使用使用暴露的MCP

注意：客户端不在同一台机器时，localhost 指向客户端自己的机器。远程接入应使用可达的服务地址和 HTTPS；桌面版仅本机监听，跨机器使用优先选择受保护的 Docker 部署。

步骤 4：通过调用记录核对结果

页面底部的“MCP 调用记录”可以查看工具、目标方法、调用结果、耗时、请求参数及响应。

图 14：实际 MCP 调用记录，3个参数都是agent自己根据MCP描述推断出来的最终得到响应创建成功（如果MCP调用失败，可以调整描述告诉他应该如何构建参数），可以追溯到具体 Dubbo 方法。

元数据异常（少部分dubbo服务可能会手动关闭元数据中心）也不一定等于工具不可用。如果已经确认 Provider 和方法存在，且配置中保留了正确的 Java 参数类型，可以显示“元数据告警（可用）”并继续显式调用。服务不存在、没有 Provider 或精确签名不匹配，则仍需要修正，不能忽略。

注意MCP服务是全局服务（因为他需要通过后台服务），多个人打开MCP服务他们配置的是同一份数据（如果您是在https://dubbo.lulianqi.com/ 您可以添加自己的测试MCP，但请尽量不要修改他的全局配置，）

七、模块四：HTTP 服务——不用写适配层，直接 curl 调 Dubbo

有时前端、Python 脚本或其他系统只想临时调用一个 Dubbo 方法，没必要先搭一个转换服务，或升级在使用的Dubbo版本。HTTP 模块可以直接把选定方法开放为 HTTP JSON 接口。

步骤 1：打开 HTTP 页面并配置连接

点击主页顶部“MCP 服务”右侧的下拉入口，进入“HTTP 服务”。展开“全局配置”，填写自己的注册中心信息。

HTTP 与 MCP、主页分别维护连接配置。首次配置时保持全局开关关闭；需要鉴权时，开启“启用鉴权”并保存好访问令牌，再启用全局服务。

图 15：HTTP 服务可以配置 Bearer Token。全局开启时，连接和令牌输入均不可编辑；截图中的令牌保持隐藏。

步骤 2：找到方法，按需启用

在“服务与方法列表”中搜索服务或方法，确认注册目录、Java 签名、版本和分组，然后开启目标方法。

图 16：同一个服务可以按方法控制。截图保留了演示环境已有的“全部开启”状态；实际使用建议只开放需要联调的方法。

“全部开启”不仅会开放当前方法，还会自动开放后续刷新发现的可用方法。除非明确需要这种行为，否则更推荐逐项控制。

只有全局服务和具体方法都启用，调用才会放行。

步骤 3：复制该方法的调用方式

点击方法右侧“调用方式”，页面会显示实际 URL、参数规则和可复制的 curl。

图 17：调用地址按注册目录、服务全名、方法名组织。此图只截取说明区域，避免公开实际令牌。

例如本文的加法接口为：

POST http://localhost:5154/api/dubbo/dubbo/com.example.dubbonet.api.DataTypeService/add

这里第一个 dubbo 属于 /api/dubbo/ 固定前缀，第二个 dubbo 是注册目录 /dubbo，不是重复写错。

在终端中，将环境变量设置为你自己的访问令牌，再调用：

export DUBBO_TESTER_TOKEN='替换为你自己的访问令牌'

curl -X POST \
  'http://localhost:5154/api/dubbo/dubbo/com.example.dubbonet.api.DataTypeService/add' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${DUBBO_TESTER_TOKEN}" \
  --data-raw '{
    "arguments": [1, 2],
    "attachments": {"traceId": "cnblogs-demo"}
  }'

如果该环境没有开启鉴权，可以省略 Authorization 请求头；对外提供调用时，建议保留鉴权并通过 HTTPS 传输。
本次调用返回：

{
  "success": true,
  "data": 3,
  "error": null,
  "elapsedMs": 162
}

同一路径存在多个版本、分组或重载时，页面生成的 URL 会加入 version、group、parameterTypes 查询参数。优先复制页面生成的完整 curl，不要擅自删掉这些参数；无法唯一确定目标时会返回 HTTP 409，而不是随机挑选一个方法。

HTTP 请求的 arguments 按 Java 参数顺序填写；无参数用 []，单个数组参数用 [[1, 2]]。attachments 可省略，值使用字符串，不能用于覆盖服务路由。

步骤 4：查看 HTTP 记录和详情

页面底部会记录 HTTP 状态、耗时、来源和调用目标。点击“详情”，可以同时核对请求正文和响应。

图 18：真实 HTTP 调用得到 200，Dubbo 返回值为 3；请求中携带了便于追踪的 traceId。

联调结束后，可以关闭单个方法，或关闭全局服务。它适合快速联调和临时调试，不替代生产环境中的完整网关、业务鉴权、限流和审计机制。

八、使用前再记住这几个细节

1. 注册中心能连通，不代表 Provider 一定可达。

尤其在 Docker、跨网段、NAT 环境中，注册中心返回的 Provider IP 可能是另一张网络里的地址。发现服务成功但调用失败时，应继续核对目标 IP、端口和网络规则。

2. 调用成功与业务成功，是两回事。

压测配置了业务断言后，应先验证断言；分析失败时，既看 RPC 异常，也看业务断言失败原因。不要把包含大量快速失败的 TPS 当作成功处理能力。

3. 本地草稿、服务端配置、压测结果，保存位置不同。

连接与页面设置、历史及请求草稿保存在当前使用端的本地存储中。Web 版更换域名、端口或清除站点数据，看到的可能是另一份本地数据。MCP、HTTP 配置由服务端保存，Docker 更新时保留数据卷；调用记录主要在内存中。压测结果仅在当前页面，留档应导出报告。

4. 最小开放范围，比“先全开再说”更重要。

MCP、HTTP 新配置的鉴权默认关闭。只在受控环境中体验；对外使用时开启鉴权、使用 HTTPS，并限制可调用的方法和网络来源。不要在生产环境直接对写入、删除等高风险方法进行无约束演示或压测。

九、总结：把准备工作缩短，把时间留给接口本身

DubboTester 的价值，不是要求业务再适配一套新的调用方式，而是尽量复用现有 Dubbo 能力：

• 想验证接口，选方法、改参数、直接发送；
• 想快速看看性能，从当前请求进入压测，现场看指标与图表；
• 想让 AI 调用业务，把方法配置为 MCP 工具；
• 想跨语言临时联调，按需开放 HTTP 接口。

如果你的日常工作里也有 Dubbo 接口自测、联调或排障，不妨先下载桌面版，或者启动一个 Docker 容器，从一个最简单的只读方法开始试试。

欢迎到 DubboTester GitHub 仓库 查看源码、提出问题和建议。如果它帮你少写了一段临时调用代码，也欢迎 Star 支持。

下载与部署入口：桌面版 Releases · Docker Hub · 项目使用文档。