300并发场景下Microsoft Bot Framework结合QnaMaker的Teams聊天机器人性能咨询

1. QnaMaker 并发承载能力说明 #

• 针对你预计服务300用户、带稳定并发诉求的场景，QnA Maker不存在性能层面的硬瓶颈，完全可以满足正常查询需求。
• 其承载能力的本质依托底层Azure AI Search的配额体系，默认基础层配置下的每秒请求处理能力，已经可以覆盖这类中小规模并发，不会因为常规知识查询出现排队、超时。
• 日常使用中容易触发QnA Maker端超时的原因，通常和并发承载能力本身无关：比如单条QnA条目塞入超大体积文本、冗余配置无实际价值的多轮对话分支，这类无效配置反而会拉低响应速度。
• 若后续并发规模进一步提升，可以通过线性增加搜索服务的副本数、分区数，等比例抬高QnA Maker的整体承载能力，不需要替换整个服务架构。

2. Microsoft Bot Service 并发承载能力说明 #

• 只要托管机器人的底层应用配置匹配规格，Microsoft Bot Service本身完全可以支撑该规模的并发，不存在渠道层的硬性承载上限。
• 本质上Azure Bot Service是托管的消息路由层，自身不做业务计算，所有的请求处理压力全部落在你托管机器人业务代码的应用服务或容器实例上；如果之前低并发场景的基础配置在高并发下出现性能问题，是应用层规格不匹配导致的，和Bot Service本身的承载能力无关。
• Teams渠道自带消息队列削峰机制，不会出现瞬时上百个用户的请求直接打满机器人入口的极端情况，相比你之前接触的公开网站、Facebook渠道，对高并发场景的适配性更友好。

3. 应用服务计划、搜索计划选型实操建议 #

应用服务计划选型 #

• 基于Bot Framework SDK原生开发、无复杂实时推理/多媒体处理逻辑的机器人，300用户并发规模下，P1v3规格的应用服务计划（2vCore、8GB内存）就可以实现稳定承载，同时预留足够的突发请求冗余，不需要一开始就采购更高规格的生产层配置造成成本浪费。
• 规避代码层面的并发反模式：不要在单请求处理逻辑中加入同步阻塞的IO操作（比如串行循环调用外部API、同步加载大体积本地文件），这类逻辑缺陷哪怕搭配最高规格的应用服务，也会在高并发下出现请求超时。

QnA Maker 依赖的搜索计划选型 #

• 300用户并发的场景下，基础级搜索服务（1分区、1副本）就可以将常规知识查询的平均响应时间控制在100ms以内，满足日常使用要求。
• 如果预判后续会出现知识库扩容、多机器人共享同一搜索服务的诉求，可以直接选择支持弹性扩容的标准级搜索服务；不需要为了短期峰值并发，长期预留满额的高端资源配额，可通过开启空闲时段弹性缩容的功能平衡性能和成本。

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