Microsoft 365 Developer Blog
·
将EWS通知迁移到Microsoft Graph
内容提要
从EWS通知框架迁移到Microsoft Graph订阅模型，标志着向统一、无状态和事件驱动框架的过渡。Microsoft Graph通过webhooks简化通知，支持实时更新，减少延迟。迁移需结合近实时变更通知和增量查询，以确保云环境中的并发和可用性。Graph引入不可变ID，简化应用设计，避免在文件夹移动时更新标识符。与EWS相比，Graph的订阅模型更受限，需要新的架构设计以适应webhook通知。
关键要点
-
从EWS通知框架迁移到Microsoft Graph订阅模型，标志着向统一、无状态和事件驱动框架的过渡。
-
Microsoft Graph通过webhooks简化通知，支持近实时更新，减少延迟。
-
迁移需结合近实时变更通知和增量查询，以确保云环境中的并发和可用性。
-
Graph引入不可变ID，简化应用设计，避免在文件夹移动时更新标识符。
-
与EWS相比，Graph的订阅模型更受限，需要新的架构设计以适应webhook通知。
-
Microsoft Graph的变更通知通过webhooks发送HTTP POST请求，支持实时更新。
-
不可变ID为邮箱项目提供稳定的唯一标识符，简化了应用设计。
-
Microsoft Graph的订阅模型对文件夹类型的支持较EWS更为有限。
-
在Microsoft Graph中，流式订阅模型的缺失需要重新设计应用架构。
-
Microsoft Graph对通知端点的性能要求更严格，需快速确认接收以避免延迟。
延伸解读
迁移的架构挑战
从EWS迁移到Microsoft Graph需要重新设计应用架构，因为Graph的通知模型依赖webhooks，而EWS支持多种通知类型。开发者需考虑如何处理实时更新和并发请求，以确保应用在云环境中的稳定性和可用性。
不可变ID的优势
Microsoft Graph引入的不可变ID为邮箱项目提供了稳定的唯一标识符，简化了应用设计。开发者不再需要在文件夹移动时更新标识符，这降低了维护成本并提高了代码的健壮性。
通知端点的性能要求
Microsoft Graph对webhook通知端点的性能要求更严格，需快速确认接收以避免延迟。开发者应实现重试逻辑和流量控制，以确保在高负载情况下仍能有效处理通知，避免错过重要事件。
延伸问答
EWS通知框架与Microsoft Graph订阅模型有什么主要区别？
EWS支持推送、拉取和流式通知，而Microsoft Graph仅通过webhooks提供变更通知，简化了架构设计。
如何将应用程序从EWS迁移到Microsoft Graph？
迁移需要结合近实时变更通知和增量查询，同时重新设计架构以适应webhook通知。
Microsoft Graph的不可变ID有什么优势？
不可变ID为邮箱项目提供稳定的唯一标识符，简化了应用设计，避免在文件夹移动时更新标识符。
Microsoft Graph的变更通知是如何工作的？
变更通知通过webhooks发送HTTP POST请求，当订阅事件发生时，通知会被发送到应用程序的监听端点。
在Microsoft Graph中，如何处理高并发的通知请求？
应采用受控处理模型，排队处理事件，并实施去重逻辑，以避免超过每个邮箱的并发连接限制。
Microsoft Graph的订阅模型对文件夹类型的支持如何？
Microsoft Graph的订阅模型对文件夹类型的支持较EWS更为有限，仅支持特定的文件夹类型。
