Azure.com 是如何跑在 Azure 上的（二）：技术与架构

原文：Aaron Hogue

翻译：汪宇杰

在本系列文章的第二篇中，我们共享我们的蓝图，因此您可以借鉴我们在建立行世界级网站方面的经验，并继续转型自己的网站。

这篇文章将帮助您从技术角度了解组成 Azure.com 的基础结构和资源。有关我们的设计原则的详细信息，请阅读《Azure.com 是如何跑在 Azure 上的（一）：设计原则与最佳实践》。

本文探讨了主要服务的角色，例如将 HTTP 请求路由到Web 前端的 Azure Front Door，以及用于创建和部署云应用程序的完全托管平台 Azure App Service。

下图向您展示了全局 Azure.com 体系架构。

Azure.com 全局架构图：认识高层Azure服务和数据流

下图显示了App Service中托管的区域体系结构的特写。我们使用部署插槽来部署到开发，测试和生产环境。部署槽是具有自己的主机名的实时应用程序。我们可以在插槽之间交换内容和配置，同时保持应用程序的可用性。

Azure.com 区域架构：App Service 在插槽中托管区域实例

Azure DNS 支持自助快速编辑 DNS 记录，具有100％可用性的全局域名服务器以及通过 Anycast 寻址实现快速 DNS 响应时间。我们对 CNAME 和 ANAME 记录类型都使用Azure DNS 别名。

https://docs.microsoft.com/en-us/azure/dns/dns-alias

Azure Front Door 服务支持低延迟TCP拆分，HTTP / 2复用和并发以及基于性能的全局路由。我们看到每个请求的RTT减少到不到100毫秒，因为客户端只需要连接到边缘节点，而不必直接连接到源。

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-architecture#splittcp
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-http2
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-lb-with-azure-app-delivery-suite#global-load-balancing

为了业务连续性，Azure Front Door 支持后端运行状况探测（一种弹性模式），实际上可在行为不当时删除不健康的区域。此外，要启用备份站点，Azure.com 使用基于优先级的流量路由。如果我们的主要服务后端脱机，则此方法使 Azure Front Door 服务支持环形故障转移。

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-health-probes
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-methods#priority

Azure Front Door 服务还充当反向代理，支持基于模式的 URL重写或请求转发以处理动态流量更改。

Web应用程序防火墙（WAF）阻止恶意机器人的负载，并在应用程序层防御 OWASP 十大攻击，帮助改善平台的安全性。WAF迫使开发人员更加关注其数据有效负载，例如cookie，请求URL，表单发布参数和请求标头。

https://docs.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview#bot-protection-rule-set-preview
https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=owasp31

我们使用WAF自定义规则来阻止对某些地理位置，IP，URL和其他请求属性的访问。规则将网络边缘的流量分流到您的源。

https://docs.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-custom-rules

为了减少加载时间，Azure.com 使用内容传递网络（CDN）来减少到源的负载。CDN 帮助我们降低消耗的带宽并降低成本。CDN 还通过在存在点（POP）边缘节点上缓存静态资源并减少 RTT 延迟来提高性能。没有 CDN，我们的原始节点将不得不处理对静态资产的所有请求。

https://docs.microsoft.com/en-us/azure/cdn/cdn-how-caching-works

CDN 还支持 DDoS 保护，提高了应用程序的安全性。我们启用 CDN 压缩和 HTTP/2，以优化静态有效负载的传递。使用 CDN 也是优化网络流量的可持续方法，因为它减少了网络中的数据流动。

https://docs.microsoft.com/en-us/azure/cdn/cdn-ddos
https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance
https://docs.microsoft.com/en-us/azure/cdn/cdn-http2
https://principles.green/principles/applied/n-tier/#heading-optimize-your-network-traffic

我们使用应用程序服务水平自动缩放来处理突发流量。Autoscale 功能易于使用，并且基于 Azure Monitor 指标来确定每个节点的每秒请求数（RPS）。我们还通过使用弹性计算将Azure 支出减少了50％，这是直接减少碳消耗的好处。

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-get-started
https://principles.green/principles/carbon/

Azure.com 使用其他一些方便的应用程序服务功能：

App Service也是PaaS服务，这意味着我们不必担心虚拟机（VM）基础架构，操作系统更新，应用程序框架以及与管理这些相关的停机时间。在选择数据中心时，我们遵循配对区域的概念，以缓解任何滚动基础架构的更新并确保改善的隔离性和弹性。

https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/february/azure-inside-the-azure-app-service-architecture

https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

最后一点，选择正确的 App Service 计划层很重要，这样您就可以正确调整垂直缩放的大小。您选择的计划还会影响可持续的能源比例，这意味着以更高的利用率运行实例以最大化碳效率。

https://principles.green/principles/energy-proportionality/

https://principles.green/principles/applied/n-tier/#heading-increase-your-compute-utilization

DaaS-.NET Profiler：确定代码瓶颈并评估改进。在此处，我们发现我们的HTML空格“ minifier”使我们的计算节点饱和。禁用它之后，我们验证了响应时间，并且CPU使用率显着提高。

Azure Monitor启用了对 Application Insights，Log Analytics 和 Azure Data Explorer 数据源的被动运行状况监视。我们依靠这些查询监视器警报来基于遥测日志构建基于配置的运行状况模型，这样我们就可以在客户告诉我们之前知道应用程序的行为异常。

https://azure.microsoft.com/en-us/services/monitor/

https://azure.microsoft.com/en-us/services/data-explorer/

https://docs.microsoft.com/en-us/azure/azure-monitor/app/alerts

例如，如以下截屏所示，我们按数据中心监视CPU消耗。如果我们的应用程序指标看到持续的高CPU使用率，则Monitor可以向我们的响应团队触发通知，该团队可以快速响应，对问题进行分类并帮助提高MTTR。如果客户端浏览器行为异常或引发控制台错误，例如Safari更改特定的推送和替换状态模式，我们也会收到主动通知。

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/app-insights-metrics#process-cpu-performancecountersprocesscpupercentage

https://trac.webkit.org/changeset/198687/webkit

性能计数器：如果CPU峰值持续超过五分钟，我们会收到警报。

Monitor 的一项功能 Application Insights 用于客户端和服务器端的应用程序性能管理（APM）遥测日志记录。它监视页面性能，异常，缓慢的依存关系，并提供跨平台分析。客户通常在中断修复方案中使用 Application Insights来提高 MTTR 并快速分类失败的请求和应用程序异常。

https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview

https://docs.microsoft.com/en-us/azure/azure-monitor/app/profiler

我们建议启用遥测采样，以免耗尽数据量存储配额。我们设置了每日存储配额警报，以捕获遥测饱和度，然后再关闭日志记录管道。

https://docs.microsoft.com/en-us/azure/azure-monitor/app/sampling

https://docs.microsoft.com/en-us/azure/azure-monitor/app/pricing#create-alerts-for-the-daily-cap

Application Insights 还提供 OpenTelemetry 支持，以跨应用程序域边界和依赖项进行分布式跟踪。此功能可实现从客户端一直到后端数据或服务层的可追溯性。

数据量容量警报：显示超出数据存储阈值的示例，这对于跟踪失控的遥测日志很有用。

一个巨大的团队为 Azure.com 工作，我们使用 Azure DevOps Services 协调我们的工作。我们使用 Azure Wiki创建内部技术文档，使用 Azure Boards 跟踪工作项，使用 Azure Pipelines 构建 CI / CD 工作流，并使用 Azure Artifacts 管理应用程序包。对于软件配置管理和质量控制，我们使用GitHub，它与Azure Board 配合使用良好。

https://azure.microsoft.com/en-us/services/devops/

https://docs.microsoft.com/en-us/azure/devops/project/wiki/about-readme-wiki?view=azure-devops

https://azure.microsoft.com/en-us/services/devops/boards/

https://azure.microsoft.com/en-us/services/devops/pipelines/

https://azure.microsoft.com/en-us/services/devops/artifacts/

作为构建过程的一部分，我们每天提交数百个PR，并且CI / CD管道每天都会将多个更新部署到生产站点。拥有一个用于管理整个软件开发生命周期（SDLC）的工具，可以简化工程团队和内部客户的学习曲线。

为了掌握最新消息，我们在 Delivery Plans 中做了很多计划。它是查看增量任务并为影响 Azure.com 流量的重大事件（例如 Microsoft Build，Microsoft Ignite 和 Microsoft Ready）创建预测的出色工具。

https://docs.microsoft.com/en-us/azure/devops/boards/plans/review-team-plans?view=azure-devops

随着 Azure 平台的发展，Azure.com 也在发展。但是有些事情保持不变，即需要一个可靠，可扩展，可持续且具有成本效益的平台。这就是为什么我们信任 Azure。

微软为云开发人员提供了许多资源和最佳实践，请参阅下面的其他资源。首先，立即创建您的 Azure 免费帐户。

https://azure.microsoft.com/en-us/free/

有关组成 Azure.com 的服务的更多信息，请查看以下资源。