北京
两个月前，我接了一张看似平平无奇的支持工单：一套通过EWS从微软365读取邮箱数据的程序，平稳运行一年多，突然在某个租户的部分邮箱上批量报错。同样的应用注册、同一套代码、同一个服务账号，唯独这组邮箱反复失败。日志里的错误信息直指“限流”，管理员已经照着这个方向排查了整整三天。
方向完全错了。真实病因与限流预算几乎没有任何关系。这种情况眼下正在大量发生，而且值得深入拆解——因为把一种问题的解药灌给另一种病，不但完全无效，还可能白白烧掉好几个工作日。
一句话先说结论：如果你的EWS失败数没有随着请求量同步放大，就不要再调优限流策略了，请立即去检查你的“应用程序访问策略作用域组”。
真正的EWS限流长什么样？Exchange Online对EWS的限流机制一直没变，核心是预算制。每个账户会分配一个策略（默认策略就叫EwsDefaultThrottlingPolicy，但很多租户会在上面叠加自定义策略），系统追踪的不是简单的调用次数，而是一个缓慢回充的预算。一旦超支，服务器会返回HTTP 503或429，并在X-MS-Diagnostics头中明确告知是哪个预算被耗尽，最常见的是连接数预算或并发请求上限。
真实限流的最显著特征是“可复制性”。失败率会随着负载同步上升，与并发数、批量大小紧密相关。一旦主动退避，几分钟内就能自行恢复。如果你画出失败率对请求量的曲线，会看到一条清晰的关联线：批量加倍，失败数随之增加；主动进行自我限流（遵守Retry-After、将FindItem调用控制在EWSFindCountLimit以内），问题几乎消失。这种强关联就是整个诊断的试金石。如果你的失败数跟请求量完全不成比例，那么不管表面错误消息怎么嚷嚷“被限了”，你面对的都不是限流问题。
那真正的改变出在哪里？大约在过去一年里，微软在两条线上同步收紧了强制措施，而这两类措施会抛出一模一样的错误。很多团队就是这样被误导的。应用程序访问策略（Application Access Policy）的作用域现在被严格验证：如果某个邮箱不在策略指定的一组安全组（即scope groups）的覆盖范围之内，EWS调用会直接失败，并返回一个很容易被解读为限流的错误。它不讲预算，不看请求频率，对退避毫无反应——因为它本质上是一个权限问题，只是打扮成了限流的模样。
更让运维人员抓狂的是，这个“权限缺口”经常在毫无征兆的情况下出现。可能只是某个管理员在一次日常清理中调整了组员身份，或者将某个邮箱从作用域组中移出，过了三个月，相关应用开始报错，而所有线索都指向一个从未变更的限流配置，从而把排查方向牢牢拽死在新旧混在一起的限流日志上。排查越努力，离真相越远。只需一次简单的权限作用域检查，就能终结这场耗时数日的猫鼠游戏。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
