使用MockChannel与BotServiceStressToolkit开展Bot Framework压测无法获取MockChannel回调数据问题咨询

核心问题定位方向 #

你遇到的“可正常发消息、Bot端能正常接收并响应，但从本地无法连接MockChannel拉取回传数据”的问题，和是否必须将压测节点部署在K8s集群内没有直接关联，优先排查以下几个高频踩坑点：

• 核对服务暴露规则：很多人部署时只配通了测试消息入口的对外路由，漏配了响应查询接口的访问规则。可以先从本地直接访问MockChannel公网地址下的响应查询路径，如果出现连接超时、404报错，说明Ingress/Service的路由没有把对应访问路径放通——哪怕把压测工具部署进集群，只要路由规则没配对，一样拿不到数据。
• 检查跨域访问限制：MockChannel默认开启的安全策略仅允许同集群来源的请求访问响应查询接口，从本地发起的跨域请求会直接被网关拦截。需要在MockChannel的配置中把本地测试机的公网出口IP加入允许访问列表，测试阶段可以临时放开CORS限制做连通性验证。
• 验证存储层隔离问题：默认MockChannel是用单Pod本地内存存储接收到的Bot响应的，如果部署了多个MockChannel Pod做负载均衡，会出现“测试消息从Pod A发出、Bot响应回传到Pod A存储，但查询请求被负载均衡路由到Pod B”的情况，哪怕网络全通也读不到对应数据。压测场景下必须把MockChannel的响应存储切换为公共外部存储（比如Redis、Azure Table Storage），保证所有Pod的存储数据全局共享，才能稳定取数。
• 先做集群内连通性基线验证：直接Exec进入K8s内运行的MockChannel Pod，通过localhost地址调用响应查询接口，如果能查到之前测试发送消息对应的Bot响应，说明核心业务逻辑是完全正常的，问题100%出在对外暴露的网络配置环节，和压测节点的部署位置没有关系。

关于压测执行节点的部署位置选择 #

• 常规低并发压测场景（并发量<500）完全不需要把JMeter等压测工具部署在K8s集群内部，只要MockChannel的网络、存储配置配通，从本地发起测试、拉取响应数据的链路可以正常跑通。
• 只有当压测并发量超过1000、本地到Azure的公网链路延迟抖动超过200ms、测试机出口带宽被打满的时候，才需要把压测节点部署在同区域的K8s集群内，降低网络因素带来的测试结果误差。
• 如果你当前从本地访问MockChannel公网地址的延迟稳定在100ms以内，完全没有必要调整压测节点的部署位置，优先把网络、配置、存储类的问题排查完成即可。

落地过程的实用配置经验 #

• 部署MockChannel时，承接外部访问的Service必须配置为LoadBalancer类型或挂接公网Ingress，不要用默认的ClusterIP类型Service——这种Service只有集群内部能访问，外部请求根本无法打通路由。
• 不需要额外开发自定义的取数服务，只要在JMeter测试计划中给每个发消息的取样器绑定唯一会话ID，后续通过固定频率的取样器调用MockChannel的查询接口，匹配会话ID拉取对应响应做结果校验即可，本地运行的JMeter对这个流程的兼容性没有任何问题。

内容的提问来源于stack exchange，提问作者Samolevar