使用服务账户解决Office 365中的请求限制问题

我之前帮客户处理过类似的Office 365批量数据导出场景，结合你用到的EWS、Microsoft Graph和SharePoint API，用服务账户解决请求限制问题可以从这几个核心方向入手：

服务账户在Azure AD里对应的是服务主体，和普通用户的委派权限不同，它用的是应用权限——这种权限是租户级的，请求限制是按你的应用（服务主体）来计算，而不是绑定到单个用户的配额。这意味着你批量操作时，不会因为某个用户的配额耗尽而卡住，整体的应用级配额通常比单个用户的高很多，更适合大规模数据获取。

举个实际配置例子：

• 要读取指定用户的Outlook邮件/日历，给服务主体申请Mail.Read（应用权限），而非委派模式的Mail.Read；
• 访问OneDrive数据用Files.Read.All，Planner用Planner.Read.All，SharePoint用Sites.Read.All；
• 这些权限需要租户管理员在Azure AD控制台里同意，记得遵循最小权限原则，别申请超出需求的权限，既安全也更容易通过审核。

EWS本身有严格的请求节流限制，用服务账户的核心是配置应用模拟（Application Impersonation）：

• 给服务账户在Exchange Admin Center里分配ApplicationImpersonation角色，这样它可以模拟指定用户访问其邮箱、日历数据；
• 如果单个服务账户的EWS配额不够，可以让租户管理员创建自定义节流策略，给服务账户单独调高请求配额（比如增加并发连接数、降低请求间隔限制）；
• 另外，EWS支持批量请求（BatchRequest），把多个用户的请求打包成一个批量操作，能大幅减少请求次数，降低触发节流的概率。

对于Graph和SharePoint，服务账户的应用权限模式天生更适合批量操作：

• 批量请求：用Graph的$batch端点，把多个Graph请求打包成一个HTTP请求；SharePoint REST API也支持批量操作，这样能把请求数降到最低；
• 速率控制：一定要处理API返回的节流响应头（比如Retry-After），实现指数退避——如果收到429错误，就按指定时间重试，而且每次重试的间隔翻倍，这是官方推荐的规避节流的标准做法；
• 如果单个服务主体的配额还是不够，可以创建多个服务账户，把任务拆分成多个批次，让不同的服务账户分别处理一部分用户/群组，分摊请求负载。

如果你的组织是大型租户，默认的应用级配额还是满足不了需求：

• 可以联系Microsoft支持申请调高租户级的API配额，但通常需要提供详细的使用场景和业务证明；
• 对于EWS，租户管理员可以通过PowerShell创建自定义节流策略，针对服务账户放宽限制（比如设置EWSMaxConcurrency、EWSPercentTimeInAD等参数）。

• 审计日志：服务账户访问的数据会留下审计记录，确保你符合组织的合规要求，必要时开启详细的审计跟踪；
• 权限审核：定期检查服务账户的权限，移除不再需要的权限，避免安全风险；
• 测试：在正式环境部署前，先在测试租户里验证服务账户的权限和请求配额，确保不会触发意外的限制。

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