Microsoft Teams 中的服务复原能力

Microsoft Teams 是针对云从头开始设计的;自成立以来，它采用云优先、移动优先、跨平台的方法。 Teams 使用高度复原的微服务体系结构构建，该体系结构可将任务拆分到多个异地冗余系统，以确保世界各地的高可用性和性能。 Microsoft Teams 还利用 Azure 的内置复原能力，使其能够抵御故障。

服务配置

在提供 Microsoft Teams 的地理位置中，它至少在两个地理上相距遥远的 Azure 区域运行，并尽可能在更多区域运行。 该服务在 Active/Active/n 配置中运行，其中用户可从地理位置中的所有可用区域主动提供服务。 容量管理和规划使得即使在仅运行至少两个区域的地理位置中，每个区域都能够处理来自整个地理位置的完整服务负载（如果一个 Azure 区域不可用）。

微服务体系结构意味着 Teams 服务更可靠，因为微服务在主动/主动状态下运行，但不需要同时位于同一 Azure 区域中。 此设计允许我们在给定地理位置使用容量，以便在站点部分不可用时，我们可以迁移某些微服务，而无需强制迁移所有微服务。 微服务还利用 Azure 的本机复原功能。

故障转移

故障转移操作用作日常服务管理过程的一部分，用于负载均衡和维护任务，以及在服务事件期间进行恢复，因此会定期执行这些操作。 如果认为合适，则由事件管理团队做出故障转移决策，并利用自动化快速大规模执行操作。 我们一直在努力改进基于事后事件学习的故障转移过程，将来我们正研究如何基于机器学习实现自动故障转移决策。

限制服务事件的影响

故障隔离

Microsoft Teams 服务基础结构是高度分段的，这严重限制了大多数类型的影响范围。 根据设计，Teams 由 140 多个微服务组成，部分用于限制单组件降级的影响。 因此，大多数服务事件仅限于单个组件或一小部分用户。 即使 DNS 事件也存在这种有限的影响，因为许多 Teams 微服务不仅依赖于 Azure 流量管理器 (ATM) ，还依赖于第三方 (Akamai) 进行 DNS 和负载均衡。

正常降级

Microsoft Teams 引入了多项功能来限制服务降级的实际影响，包括由第三方提供商（如 ISP，甚至客户自己的内部网络）造成的影响。 示例包括：

• 使媒体路径保持简短 - Teams 利用智能路由来减少网络跃点数和网络遍历距离，以减少潜在故障点的数量。
• 正常处理降级 - Teams 在操作不正常时会收到应用内用户通知，以及关闭视频以提高性能（如果连接不合格）等建议。 如果用户的连接在线路上引起反馈或噪音，Teams 会提示用户将音频静音。
• 临时网络丢失 - 恢复网络连接后，Teams 会自动重新连接到会议或呼叫。
• 回退到 PSTN - 如果由于网络连接不佳而从呼叫中断开，Teams 会自动提供通过公用电话交换网 (PSTN) 重新加入的选项。 此功能具有不需要会议号码或密码的额外优势，因此随时随地的用户可以更轻松地保持联系。
• 设备 & 切换失败 – Teams 会检测音频设备是否已断开连接，并尝试切换到备用设备（如果可用）。

代码部署

Teams 在更新服务端组件时使用分步部署圈，从一小群内部测试用户开始，然后是更广泛的Microsoft公司网络。 在每个步骤中，工程师都会收集有关功能和性能的反馈，并在生产环境中部署之前尽一切努力检测任何问题。 部署到生产环境时，我们从一小部分系统开始，然后开始在不断扩大的环中进行部署，直到所有用户都连接到运行最新代码的系统。 同样，任何与更新相关的问题报告都触发事件响应，并可能导致停止更新、回滚到最新版本，以及从活动轮换中删除降级的系统，直到问题得到解决。 Teams 还能够在必要时禁用特定代码路径，这使我们能够快速识别和禁用有问题的代码，并将系统返回到正常状态，而无需等待新的更新推出。