"继续我们的Azure可靠性系列，以尽可能透明地介绍正在进行的关键计划，以不断提高可用性，今天我们将注意力转向Azure Active Directory。Microsoft Azure Active Directory（Azure AD）是一种云身份服务，可为每月超过2.5亿的活动用户提供安全访问，连接140多万个独特的应用程序，并处理超过300亿个每日身份验证请求。这使得azuread不仅是最大的企业身份和访问管理解决方案，而且很容易成为世界上最大的服务之一。下面的帖子是由Nadim Abdo撰写的，他是工程部的合伙人主管，他领导着这些工作 我们的客户信任Azure AD来管理对其所有应用程序和服务的安全访问。对我们来说，这意味着每个身份验证请求都是一个任务关键型操作。鉴于服务的关键性质和规模，我们的身份识别团队的首要任务是服务的可靠性和安全性。azuread是为可用性和安全性而设计的，它使用真正的云原生、超规模、多租户架构，我们的团队有一个不断提高可靠性和安全性标准的计划。Azure AD：核心可用性原则设计一个如此规模、复杂度和任务关键性的服务，使之在一个我们所建立的一切都可能失败的世界中高度可用，这是一项复杂的任务。我们的弹性投资围绕以下一套可靠性原则进行组织：我们的可用性工作采用分层防御方法，尽可能降低客户可见故障的可能性；如果确实发生故障，则尽可能缩小故障的影响范围，最后，尽可能减少恢复和减轻故障所需的时间。在接下来的几周和几个月里，我们将深入探讨每一个原则是如何在实践中设计和验证的，并提供它们如何为我们的客户工作的例子。高度冗余azuread是一种具有多层次内部冗余和自动恢复能力的全局服务。Azure AD部署在全球30多个数据中心，利用Azure可用性区域（如有）。随着部署更多的Azure区域，这个数字正在迅速增长。为了持久性，写入azuread的任何数据块都将复制到至少4个数据中心，最多13个数据中心，具体取决于您的租户配置。在每个数据中心内，数据至少重复9次以保持持久性，但也要扩展容量以满足身份验证负载。为了说明这意味着，在任何时间点，在我们最小的区域内，我们的服务中至少有36个目录数据的副本。为了持久性，对Azure AD的写入在成功提交到区域外数据中心之前不会完成。这种方法为我们提供了数据的持久性和大量冗余多个网络路径和数据中心可以服务于任何给定的授权请求，并且系统自动和智能地在数据中心内部和跨数据中心之间重试和路由。为了验证这一点，我们定期进行故障注入，并验证系统对构建azuread的系统组件故障的恢复能力。这一直延伸到定期删除整个数据中心，以确认系统能够容忍数据中心的丢失，而不会对客户造成任何影响。无单点故障（SPOF）如前所述，azuread本身的架构具有多个级别的内部弹性，但我们的原则进一步扩展到在所有外部依赖性中都具有弹性。这体现在我们的无单点故障（SPOF）原则中。鉴于我们服务的重要性，我们不接受关键外部系统中的SPOF，如分布式名称服务（DNS）、内容交付网络（CDN）或传输多因素身份验证（MFA）的电信提供商，包括SMS和语音。对于这些系统中的每一个，我们使用多个冗余系统，这些系统配置为完全主动-主动配置。在这一原则上的大部分工作已经在过去的一年中完成，并且为了说明，当一个大型DNS提供商最近出现故障时，Azure AD完全不受影响，因为我们有一个到备用提供商的主动/主动路径。弹性鳞片azuread已经是一个运行在超过300000个CPU核心上的大型系统，能够依赖Azure云的巨大可伸缩性来动态、快速地扩展以满足任何需求。这既包括流量的自然增长，比如某个地区的认证在上午9点达到峰值，也包括我们的Azure AD B2C所提供的新流量的巨大激增，它为世界上一些大型活动提供动力，并经常看到数百万新用户的涌入。作为一种额外的弹性级别，azuread over提供了其容量，设计要点是整个数据中心的故障转移不需要任何额外的容量供应来处理重新分配的负载。这使我们能够灵活地知道，在紧急情况下，我们已经拥有了手头所需的所有能力。安全部署安全部署可确保更改（代码或配置）逐步从内部自动化进展到内部，再到Microsoft自托管环再到生产。在生产中，我们采用了一种渐进式的缓慢上升的方式，通过自动化的健康检查来控制从一个部署环到下一个环的变化。整个过程需要一周时间才能在整个生产过程中全面展开更改，并且可以随时快速回滚到上一个众所周知的健康状态。这个系统会定期捕捉到我们称之为"早期环"的潜在故障，这些故障完全是微软内部的，并阻止它们出现在可能影响客户/生产流量的环上。现代验证为了支持闸门安全部署的健康检查，并让我们的工程团队深入了解系统的健康状况，Azure AD会发出大量内部遥测、度量和信号，用于监控系统的运行状况。以我们的规模来看，这是每周超过11PB的信号，为我们的自动健康监测系统提供信息。这些系统反过来会触发自动化警报，以及我们的24/7/365工程师团队，他们会对任何潜在的可用性或服务质量（QoS）下降作出响应。我们在这里的旅程是扩展遥测，不仅提供服务的运行状况的光学特性，而且提供真正代表给定租户的给定场景的端到端运行状况的度量。我们的团队已经在内部提醒这些指标，我们正在评估如何在Azure门户中直接向客户公开每个租户的健康数据。分区和细粒度容错域更好地理解azuread的一个很好的类比是潜艇中的舱室，设计成能够在不影响其他舱室或整艘船完整性的情况下进行洪水淹没。azuread的等价物是一个容错域，为容错域中的一组租户服务的规模单元被设计成与其他容错域的规模单元完全隔离。这些故障域提供了许多故障类别的硬隔离，使得故障的"爆炸半径"包含在给定的故障域中。到目前为止，azuread已经由五个独立的容错域组成。在过去的一年中，到明年夏天完成，这个数字将增加到50个容错域，许多服务，包括Azure多因素身份验证（MFA），正逐渐在这些容错域中完全隔离。这种硬分区工作被设计成一个最终的解决方案，它将任何停机或故障的范围限定为不超过1/50或~2%的用户。我们的目标是在接下来的一年里进一步增加到数百个容错域。预告即将发生的事上述原则旨在强化核心Azure广告服务。鉴于Azure AD的关键性，我们不会就此停止，未来的帖子将涵盖我们正在进行的新投资，包括在生产中推出第二个完全故障解除相关的身份服务，该服务可以在主Azure AD服务出现故障时提供无缝的回退身份验证支持。可以将其视为备用发电机或不间断电源（UPS）系统，在主电网受到影响时提供覆盖和保护。该系统对最终用户是完全透明和无缝的，现在已投入生产，为一组M365工作负载保护一部分关键的身份验证流。我们将迅速扩展它的适用性，以涵盖更多的场景和工作负载。我们期待着在我们的azureactivedirectorydirectoryidentity博客上分享更多内容，听取您的问题和感兴趣的主题，以便将来发表文章。