COVID-19流感大流行重新定义了工作、学习和社交的意义。像我们很多人一样，我已经开始依赖微软团队作为我与同事之间的纽带。在这篇文章中，我们来自微软团队产品组Rish Tandon（公司副总裁）、Aarthi Natarajan（集团工程经理）和Martin Taillefer（架构师）的朋友们分享他们在管理和扩展企业级安全生产应用程序方面的一些经验。"-Mark Russinovich，CTO，Azure 规模、弹性和性能不是一朝一夕就能实现的--它需要持续和深思熟虑的投资，日复一日，以及以性能为先的心态来构建令用户满意的产品。自推出以来，团队经历了强劲增长：从2017年发布到2019年7月的1300万日用户，到2019年11月的2000万。今年4月，我们分享到团队拥有超过7500万的每日活跃用户、2亿的每日会议参与者和41亿的每日会议记录。我们认为，鉴于团队迄今为止经历的快速增长，我们已经习惯了以这种速度扩展服务所需的持续工作。COVID-19对这一假设提出了挑战；这一经验是否能让我们在一个以前无法想象的增长期内保持服务的运行？坚实的基础团队建立在一个微服务架构之上，几百个微服务协同工作，提供我们产品的许多功能，包括消息、会议、文件、日历和应用程序。使用微服务可以帮助我们的每个组件团队独立地工作和发布更改。Azure是支撑微软所有云服务（包括微软团队）的云平台。我们的工作负载在Azure虚拟机（VMs）中运行，我们的旧服务通过Azure云服务部署，较新的服务部署在Azure服务结构上。我们的主要存储堆栈是azurecosmosdb，有些服务使用azureblob存储。我们依靠azurecacheforredis来提高吞吐量和恢复能力。我们利用流量管理器和Azure前门将流量路由到我们希望的位置。我们使用队列存储和事件集线器进行通信，我们依赖azureactivedirectory来管理租户和用户。  虽然这篇文章主要关注我们的云后端，但值得强调的是，Teams客户端应用程序也使用了现代设计模式和框架，提供了丰富的用户体验，并支持离线或间歇连接体验。快速更新客户机并与服务同步的核心能力是快速迭代的关键。如果您想深入了解我们的体系结构，请查看Microsoft Ignite 2019的本期课程。敏捷开发我们的CI/CD管道构建在Azure管道之上。我们使用基于环的部署策略，基于自动端到端测试和遥测信号的结合。我们的遥测信号与事件管理管道集成，提供服务和客户定义的指标警报。我们非常依赖azuredataexplorer进行分析。此外，我们还使用了一个带有记分卡的实验管道，根据关键的产品指标（如崩溃率、内存消耗、应用程序响应能力、性能和用户参与度）评估功能的行为。这有助于我们了解新功能是否按我们希望的方式工作。我们所有的服务和客户机都使用集中的配置管理服务。此服务提供配置状态以打开和关闭产品功能，将缓存时间调整为活动值，控制网络请求频率，并将网络端点设置为联系API。这提供了一个灵活的框架来"暗启动"，并进行a/B测试，这样我们就可以准确地测量我们的更改的影响，以确保它们对所有用户都是安全和高效的。关键弹性策略我们在整个服务团队中采用了多种弹性策略：主动-主动容错系统：主动-主动容错系统定义为两条（或更多）独立于操作的异构路径，每个路径不仅在稳定状态下提供实时流量，而且还能够提供100%的预期流量，同时利用客户端和协议路径选择实现无缝故障切换。我们采用这种策略的情况下，有一个非常大的失败领域或客户影响合理的成本，以证明建设和维护异构系统。例如，我们将Office 365 DNS系统用于所有外部可见的客户端域。此外，静态CDN类数据托管在Azure Front Door和Akamai上。弹性优化缓存：为了提高性能和恢复能力，我们广泛地利用组件之间的缓存。缓存有助于减少平均延迟，并在下游服务不可用的情况下提供数据源。将数据长时间保存在缓存中会带来数据新鲜度问题，但将数据长时间保存在缓存中是防止下游故障的最佳方法。我们关注缓存数据的刷新时间（TTR）和生存时间（TTL）。通过设置一个长的TTL和一个较短的TTR值，我们可以微调数据保存的新鲜度，而不是在下游依赖性失败时希望数据保留多长时间。断路器：这是一种常见的设计模式，可防止服务执行可能失败的操作。它为下游服务提供了一个恢复的机会，而不会被重试请求淹没。当服务的依赖项出现问题时，它还可以改善服务的响应，帮助系统对错误情况有更大的容忍度。隔板隔离：我们将一些关键服务划分为完全隔离的部署。如果在一个部署中出现问题，隔板隔离旨在帮助其他部署继续运行。这种缓解措施为尽可能多的客户保留了功能。API级别的速率限制：我们确保我们的关键服务可以在API级别限制请求。这些速率限制通过上述集中配置管理系统进行管理。这种能力使我们能够在COVID-19激增期间对非关键api进行速率限制。高效的重试模式：我们确保并验证所有API客户端都实现了高效的重试逻辑，这可以在网络发生故障时防止流量暴增。超时：一致地使用超时语义可以防止当下游依赖项遇到一些问题时工作停止。妥善处理网络故障：我们进行了长期投资，以改善离线或连接不良时的客户体验。这一领域的重大改进就在COVID-19激增开始之际投入生产，使我们的客户无论网络质量如何都能提供一致的体验。如果你看过Azure云设计模式，你可能会对其中的许多概念很熟悉。我们还在微服务中广泛使用Polly库，它为其中一些模式提供了实现。我们的架构一直运行良好，团队使用量逐月增长，平台很容易扩展以满足需求。然而，可伸缩性并不是一个"一劳永逸"的考虑因素，它需要持续关注在任何复杂系统中表现出来的突发行为。当COVID-19居家订单开始在全球范围内流行时，我们需要利用我们系统中内置的架构灵活性，并尽我们所能，有效地应对快速增长的需求。产能预测与任何产品一样，我们构建并不断迭代模型，以预测在哪里会出现增长，包括原始用户和使用模式。这些模型是基于历史数据、循环模式、新进入的大客户和各种其他信号。随着激增的开始，很明显我们以前的预测模型很快就过时了，因此我们需要建立新的预测模型，将全球需求的巨大增长考虑在内。我们看到了来自现有用户的新使用模式，来自现有但处于休眠状态的用户的新使用情况，以及许多新用户开始使用该产品，所有这些都是同时发生的。此外，我们必须加快资源配置决策，以应对潜在的计算和网络瓶颈。我们使用多种预测建模技术（ARIMA、加法、乘法、对数）。除此之外，我们增加了每个国家的基本上限，以避免过度预测。我们通过尝试了解每个行业和地理区域的使用情况来理解拐点和增长模式，从而对模型进行了调整。我们整合了外部数据源，包括Johns Hopkins对COVID-19影响日期的研究，以增强瓶颈地区的峰值负荷预测。在整个过程中，我们犯了一个谨慎的错误，倾向于提供，但是随着使用模式的稳定，我们也在必要时缩减了规模。扩展我们的计算资源一般来说，我们设计团队能抵御自然灾害。使用多个Azure区域有助于我们降低风险，不仅来自数据中心问题，还来自于对主要地理区域的中断。然而，这意味着我们将提供额外的资源，以便在这种情况下随时准备承担受影响区域的负荷。为了扩大规模，我们迅速将每个关键微服务的部署扩展到每个主要Azure地理区域的其他区域。通过增加每个地理区域的总区域数，我们减少了每个区域为吸收紧急负载所需的闲置容量总量，从而降低了我们的总容量需求。在这种新的规模下处理负载让我们对如何提高效率有了一些见解：我们发现，通过重新部署我们的一些微服务来支持更多的小型计算集群，我们能够避免一些针对每个集群的扩展考虑，有助于加快部署速度，并为我们提供更细粒度的负载平衡。以前，我们依赖于特定的虚拟机类型