使用 Microsoft Graph 获取数据更改的实时更新
本文介绍适用于业务方案的常见Microsoft Graph 集成模式，该模式为移动应用提供企业协作增强功能，以便近乎实时地接收来自 Microsoft Teams 的共享消息的只读源。
此方案是一种非交互式用例，它依赖于外部事件触发的数据更改，并具有以下体系结构要求：
- 数据集成类型。
- 从 Microsoft 365 边界到应用的出站数据流。
- 每次人工交互的数据量较低，但数据量可能很高，具体取决于用户数量。
- 用于生成最新源的准实时数据延迟。
此方案的最佳集成选项是使用 Microsoft Graph 更改通知，它可以传递事件通知以及共享消息的内容，并实现 Webhook。 客户端应用提供客户端密码和加密密钥，并公开Microsoft Graph 通知服务发布更改的 HTTP 终结点。 客户端应用可以接受并及时响应同步Microsoft Graph 请求，并且可以缩放以处理由生成消息的其他客户端触发的事件。 这种类型的应用交互称为推送模式。
下图显示了此解决方案的体系结构。
解决方案组件
解决方案体系结构包括以下组件：
- Azure 应用服务允许你使用首选编程语言生成和托管 Web 应用、移动后端和 RESTful API，而无需管理基础结构。 它提供自动缩放和高可用性，支持 Windows 和 Linux，并支持从 GitHub、Azure DevOps 或任何 Git 存储库进行自动部署。
- Microsoft Entra ID，这是管理Microsoft Graph API 的身份验证所必需的，并支持启用 OAuth 流的委托权限和应用程序权限。
- 函数应用是一个无服务器组件，可用于缩放大量通知，并具有处理通知并将其发送到目标服务的业务逻辑。
- 简单存储队列，它通过在函数应用实例的异步处理之前保留通知来帮助减轻应用服务中的负载。
- Azure 应用程序网关，它提供 Web 安全性和路由功能。
- Microsoft Graph 通知服务，该服务管理通知订阅并将更改通知传递到客户端。
注意事项
以下注意事项支持使用此集成模式：
可用性：每当共享频道或聊天中发布新消息时，Microsoft Graph 将调用客户端 Webhook。 Webhook 必须全天保持高可用性，甚至 24 小时保持高可用性。
延迟：Webhook 必须在三秒内确认Microsoft Graph 通知请求。 如果Microsoft Graph 在此期间未收到 200 个类代码，它将多次重新发送更改通知，最长为 4 小时。
可伸缩性：客户端 Webhook 必须能够在一天中的任何时间缩放大量通知。 它可以通过向应用服务添加更多实例并实例化更多函数应用实例来及时更新目标服务来执行此操作。
解决方案复杂性：Webhook 解决方案还需要自定义代码来维护订阅，以及加密密钥来处理数据。 由于涉及的组件数量以及可伸缩性和可用性要求，此解决方案非常复杂。