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 还能够在必要时禁用特定代码路径,这使我们能够非常快速地识别和禁用有问题的代码,并将系统返回到正常状态,而无需等待新的更新推出。