引言

上个月联调一个新模块，团队里发生了经典的一幕：后端小哥在终端里敲 grpcurl 敲得飞起，测试同学凑过来问"Postman 里怎么没有这个接口？"——一句话暴露了两个事实：一是我们的接口早就不是"清一色 REST"了（gRPC 做内部服务、WebSocket 做实时推送、MQTT 做设备接入、Kafka 做事件总线），二是调试工具的口味还停留在 HTTP 时代。

拿 Postman 硬调这些协议，结果都是"能用但别扭"：gRPC 要手写一坨 proto 导入流程；WebSocket 能连但历史消息和定时发送都缺；MQTT 和 Kafka 更是基本无能为力。这五个协议各自有专门的调试工具，用对了效率翻倍：

这篇文章逐个过：安装、最常用的命令/配置、以及每个工具"真正区别于其他选项"的杀手锏。

一、grpcurl：命令行 gRPC 调试

1.1 安装

# macOS
brew install grpcurl
# Linux（Go 安装）
go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest
# 或直接下载 release 二进制
# https://github.com/fullstorydev/grpcurl/releases

1.2 前置知识：反射模式 vs -proto 模式

gRPC 是强类型 RPC，调用前需要知道 proto 定义。grpcurl 有两种获取方式：

// 服务端开启反射（Go 示例，一行代码）
import "google.golang.org/grpc/reflection"

func main() {
    s := grpc.NewServer()
    pb.RegisterOrderServiceServer(s, &orderServer{})
    reflection.Register(s)   // ← 生产环境建议评估后决定是否开启
    s.Serve(lis)
}

1.3 常用命令速查

# ── 探查服务 ──
# 列出服务端所有服务（验证连通性 + 服务名，联调第一步）
grpcurl -plaintext 192.168.1.10:50051 list

# 列出某个服务的所有方法
grpcurl -plaintext 192.168.1.10:50051 list order.OrderService

# 看某个方法的入参出参定义（比翻 proto 文件快）
grpcurl -plaintext 192.168.1.10:50051 describe order.OrderService.CreateOrder

# ── 发起调用 ──
# 最常用：-d 传 JSON 参数
grpcurl -plaintext 192.168.1.10:50051 \
  order.OrderService/CreateOrder \
  -d '{"userId": 10001, "productId": "P2001", "quantity": 2}'

# 带 metadata（等价于 HTTP header，传 token 用）
grpcurl -plaintext 192.168.1.10:50051 \
  -H "authorization: Bearer eyJhbGciOi..." \
  order.OrderService/GetOrder -d '{"orderId": "O10086"}'

# 设置超时（默认无限等待，脚本里务必加）
grpcurl -plaintext -max-time 3 192.168.1.10:50051 order.OrderService/GetOrder -d '{}'

# ── 无反射：本地 proto 文件 ──
grpcurl -plaintext \
  -import-path ./api/proto \
  -proto order.proto \
  192.168.1.10:50051 order.OrderService/CreateOrder \
  -d '{"userId": 10001}'

# ── TLS ──
# 服务端单向 TLS
grpcurl 192.168.1.10:50051 order.OrderService/GetOrder -d '{}'
# 自签证书 + 跳过校验（测试环境）
grpcurl -insecure 192.168.1.10:50051 order.OrderService/GetOrder -d '{}'
# 双向 TLS（mTLS）
grpcurl -cacert ca.pem -cert client.pem -key client.key \
  192.168.1.10:50051 order.OrderService/GetOrder -d '{}'

1.4 杀手锏：进 CI 脚本

grpcurl 最大的价值是可脚本化——把它嵌进流水线做接口冒烟：

#!/bin/bash
# ci/grpc-smoke.sh：部署后 gRPC 冒烟检查
set -e
ADDR="order-service:50051"

# 1. 服务注册检查
services=$(grpcurl -plaintext -max-time 3 $ADDR list)
echo "$services" | grep -q "order.OrderService" || {
    echo "❌ OrderService 未注册"; exit 1; }

# 2. 健康检查调用
resp=$(grpcurl -plaintext -max-time 3 $ADDR \
    order.OrderService/HealthCheck -d '{}' 2>&1)
echo "$resp" | grep -q '"status": "SERVING"' || {
    echo "❌ 健康检查失败: $resp"; exit 1; }

echo "✅ gRPC 冒烟通过"

配合 -format grpcurl-cli-json（输出 JSON）还可以用 jq 断言字段，比肉眼校验返回值可靠得多。

二、BloomRPC：有 GUI 的 gRPC 客户端

2.1 安装

# macOS
brew install --cask bloomrpc
# 或 GitHub Releases 下载 dmg/AppImage
# https://github.com/uw-labs/bloomrpc/releases

2.2 基本使用流程

四步上手，和 Postman 的心智模型几乎一致：

① 导入 proto：左侧 Proto Files 点 + ，选中 .proto 文件
   （依赖的公共 proto 会自动按 import 路径解析，目录结构要保持）
② 选中方法：左侧树展开 order.OrderService → 点 CreateOrder
③ 填请求体：中间的请求编辑器自动生成 JSON 模板，按提示填参
④ 点 ▶ 发送：右侧看响应（含耗时、错误码、响应 JSON）

2.3 关键配置项

2.4 维护状态提醒与替代品

必须诚实说：BloomRPC 原仓库已停止维护（最后版本停在 2021 年），遇到新语法特性（如 proto3 的 optional 字段）可能解析异常。选型建议：

团队实践：日常点调用 Postman 的 gRPC 页签（省得维护两个工具），复杂 proto/批量验证用 grpcurl——GUI 和 CLI 不是二选一。

三、WebSocket King：浏览器 WebSocket 调试插件

3.1 安装

Chrome/Edge 应用商店搜 WebSocket King 安装即可（也可以用同类竞品 Smart WebSocket Client，功能相近）。它的优势是零安装依赖、打开浏览器就能用，前端同学联调推送尤其顺手。

3.2 基本使用

① URL 栏输入 ws://192.168.1.10:8080/realtime/order（或 wss:// 加密）
   可选：勾选子协议填 Sec-WebSocket-Protocol
② 点 Open 建立连接
③ 请求编辑器发消息：支持 Text / JSON / Binary 多种格式
④ 下方面板收消息：每条消息带时间戳，按帧展示

3.3 杀手锏功能

3.4 实战示例：调试订单状态推送

场景：验证"订单状态变更实时推送到客户端"

① Open: ws://dev.example.com/realtime
② 发送订阅消息（模板已保存）：
   {"type": "SUBSCRIBE", "topic": "order.status.O10086"}
③ 服务端 ACK：
   {"type": "SUBSCRIBED", "topic": "order.status.O10086"}
④ 触发订单状态变更（调用 grpcurl 改订单状态）：
   grpcurl -plaintext order-service:50051 \
     order.OrderService/ConfirmOrder -d '{"orderId":"O10086"}'
⑤ WebSocket King 面板收到推送：
   {"type": "STATUS_CHANGED", "orderId": "O10086", "status": "CONFIRMED", "ts": 1724400000}
⑥ Repeat 模式开 30s 心跳，挂半小时验证长连接稳定性

一个常见坑提前说：wss 自签证书在浏览器插件里会被拒——先用浏览器访问一次 https://同域名 手动信任证书，插件就能连了。

四、MQTT Explorer：主题订阅/发布可视化

4.1 安装与连接配置

官网下载桌面版（Windows/macOS/Linux 齐全）：https://mqtt-explorer.com

连接配置（新建 Connection）：

4.2 杀手锏：主题树可视化

其他 MQTT 工具（如 mosquitto_sub）是"命令行刷屏"式的，MQTT Explorer 的核心差异是整棵主题树 + 每个节点的最新值 + 变化曲线：

连接后左侧出现树形结构（加载历史消息后全量展开）：
home/
├── livingroom/
│   ├── temperature    24.5  ℃   ← 点开右侧有历史曲线图
│   ├── humidity       56    %
│   └── light          on / off     ← 布尔值切换可视化
├── bedroom/temperature 23.1 ℃
└── gateway/status     online

三个高频场景：

① 排查"设备没上报"：主题树里直接看目标主题最后更新时间和值
   ——比在命令行里订阅等半分钟直观得多
② 找"幽灵主题"：搜索框输关键字，立刻定位拼写错误的主题
   （设备端把 home/livingroom 写成 home/living_room 的故事谁都遇到过）
③ 观察 retained 消息：图标区分 retained 消息，一眼看出
   "为什么新订阅一上来就收到旧数据"

4.3 发布测试

顶部 Publish 面板：填 Topic → 选格式（Text/JSON/Base64）→ 填内容 → 选 QoS（0/1/2）→ 勾 Retain 可发保留消息。

调试"下发指令"场景：
Topic: home/livingroom/light/set
Payload: {"state": "on", "brightness": 80}
QoS: 1（至少一次，确保指令必达）
Retain: ❌（指令类消息不要 retain，否则设备重连会执行旧指令）

发送后主题树里 immediately 看到设备回报的 light 状态变为 on

Retain 的使用纪律：状态类主题（传感器当前值、设备在线状态）用 retain，指令类主题严禁 retain——这是团队里最容易出事故的配置点。

五、Kafka UI：开源 Kafka 管理界面

5.1 部署（Docker 一行起）

选型用的是 Provectus 出品的 kafka-ui（github.com/provectus/kafka-ui），部署最简单：

# docker-compose.yml
services:
  kafka-ui:
    image: provectuslabs/kafka-ui:latest
    ports:
      - "8080:8080"
    environment:
      KAFKA_CLUSTERS_0_NAME: prod-cluster
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka-1:9092,kafka-2:9092,kafka-3:9092
      # SASL 认证的集群加这段
      KAFKA_CLUSTERS_0_PROPERTIES_SECURITY_PROTOCOL: SASL_PLAINTEXT
      KAFKA_CLUSTERS_0_PROPERTIES_SASL_MECHANISM: PLAIN
      KAFKA_CLUSTERS_0_PROPERTIES_SASL_JAAS_CONFIG: >
        org.apache.kafka.common.security.plain.PlainLoginModule
        required username="admin" password="pass";
      # 只读模式（给全团队开放时强烈建议）
      KAFKA_CLUSTERS_0_READONLY: "true"

docker compose up -d
# 浏览器打开 http://localhost:8080

部署位置建议：和 Kafka 集群同网络（能通 bootstrap 地址即可），按环境各部署一个实例，通过公司 SSO/网关加访问控制——管理台直接暴露公网是真实发生过的事故。

5.2 高频功能速查

5.3 实战示例：排查"积分没到账"

① Consumers 页搜积分服务 group：score-service-group
   → lag 显示 82 万：消费积压实锤（不是没收到消息）
② 下钻 partition 3：lag 集中在此分区 → 该分区的消费者实例可能卡死
③ 跳到对应消费者服务查日志/线程栈，确认是下游慢查询拖死消费
④ 恢复后 Messages 页按 key 过滤 orderId=O10086
   → 确认消息已重新消费，积分流水写入成功

没有 Kafka UI 的世界里，这些动作要敲 kafka-consumer-groups.sh --describe、kafka-console-consumer.sh 一串命令；有了它，测试和产品同学也能自己确认"消息到底发没发"，研发的打扰少了一半。

六、常见问题

6.1 grpcurl 提示 "server does not support the reflection API"？

服务端没开反射，两个选择：① 按第一章代码开反射（注意生产环境暴露服务清单的安全评估）；② 用本地 proto：grpcurl -import-path ./proto -proto xxx.proto ...。CI 环境推荐后者——不依赖服务端配置，proto 文件随仓库版本走。

6.2 BloomRPC 停止维护了还能用吗？团队该选什么？

能用，稳定版本功能没有明显缺陷。但新团队建议直接用 Postman 的 gRPC 请求（v9.7+ 原生支持，含流式调用），理由：① 工具栈统一，HTTP/gRPC/REST 全在一个工具；② 集合/环境/团队协作是现成的；③ BloomRPC 的 import 路径解析在复杂 proto 结构下容易报错。grpcurl 作为 CI 和深度调试的补充。

6.3 WebSocket King 连 wss 报错握手失败？

九成是证书问题。自签证书的解法：先用浏览器直接访问 https://host 手动信任，再回插件连接。仍是握手失败的：检查子协议（Sec-WebSocket-Protocol）是否与服务端约定一致、URL 是否带了错误的端口、以及网关（Nginx）是否配置了 proxy_set_header Upgrade $http_upgrade。

6.4 MQTT 的 QoS 0/1/2 怎么选？

调试工具里 QoS 选错了，可能出现"我以为必达但消息丢了"（QoS0）或"消费端重复执行"（QoS1 未做幂等）——联调时要和服务端约定的 QoS 保持一致。

6.5 Kafka UI 对集群性能有影响吗？

正常浏览几乎无影响（都是 metadata 请求）。会碰数据的是两处：Messages 页的实时流过滤（会向 broker 发起消费请求）、无限分页的深层翻页。注意三点：大 topic 查询加 key 过滤、集群负载高峰别重置 offset、给只读用户开 READONLY 模式。

6.6 这些工具怎么进团队规范？

按"谁用、在哪用"定：grpcurl 进 CI 冒烟脚本（仓库里统一维护）；Postman gRPC 请求进团队共享集合（和 HTTP 接口文档同待遇）；Kafka UI 按环境部署 + SSO + 只读权限，写操作（重置 offset、改配置）保留给平台组；MQTT Explorer 配置导出文件放团队仓库，新人导入即用。

七、总结

工具速查卡

┌─────────────────┬──────────┬────────────┬────────────────────────────┐
│ 工具             │ 协议      │ 形态        │ 杀手锏                      │
├─────────────────┼──────────┼────────────┼────────────────────────────┤
│ grpcurl         │ gRPC     │ CLI        │ list/describe 探查 + CI 冒烟 │
│ BloomRPC        │ gRPC     │ GUI        │ Postman 式点调（已停止维护）  │
│ WebSocket King  │ WebSocket│ 浏览器插件  │ Repeat 定时心跳 + 消息模板    │
│ MQTT Explorer   │ MQTT     │ 桌面客户端  │ 主题树 + 数值曲线 + retained  │
│ Kafka UI        │ Kafka    │ Web 服务    │ lag 排查 + 消息检索 + offset  │
└─────────────────┴──────────┴────────────┴────────────────────────────┘

选型一句话

Postman 统治的是 HTTP 时代，多协议微服务的调试工具箱应该是"每协议一个趁手家伙"：gRPC 用 grpcurl 探查 + GUI 点调，WebSocket 用浏览器插件测心跳，MQTT 用主题树看设备，Kafka 用管理台查 lag。工具不新潮没关系，关键是团队里人人都知道"调这个协议该打开哪个东西"。

给团队的建议

互动话题：你们调 gRPC/MQTT/Kafka 用的是什么工具？有没有被"消息到底发没发出去"折磨过的经历？评论区聊聊你的工具箱。

参考资料

• grpcurl GitHub
• gRPC Server Reflection Protocol
• BloomRPC GitHub（已归档）
• Postman gRPC 支持
• WebSocket King 官网
• MQTT 官网：MQTT Explorer
• MQTT QoS 官方说明
• Kafka UI (Provectus) GitHub
• Apache Kafka 文档