什么是应用程序弹性？

从处理客户交易和管理供应链到实现员工协作和分析实时数据，应用程序几乎为现代业务的各个方面提供支持。

当这些应用程序出故障时，后果可能很严重。停机时间（应用程序不可用或无法正常运行的时间段）可能会导致声誉受损、用户体验下降和重大的财务损失。

事实上，目前有 98% 的组织报告称，停机时间成本超过每小时 100,000 美元，其中三分之一的组织估计损失在 100 万美元至 500 万美元之间。

通过设计和实施弹性应用程序，组织可以避免和减轻这些中断。

应用程序弹性取决于两个核心原则：

• 容错能力：当应用程序部分出现故障时，应用程序继续运行的能力。

• 高可用性：系统在接近 100％ 的时间内可访问且可靠的能力。

弹性应用程序有助于减少应用程序架构中的漏洞，提高运营效率，并确保即使在遇到意外中断时也能提供一致的用户体验。

为了创建和部署弹性应用程序，开发人员和 IT 团队可以在应用程序的整个生命周期内运用多种工具和实践。

弹性应用程序的常见组件包括：

• 冗余
• 负载均衡
• 故障遏制
• 可观察性
• 自动化
• 适度降级
• 可扩展性

冗余意味着存在关键系统的备份版本。如果系统出现故障，备份将接管系统，以确保其继续运行。

例如，支付处理服务可能在不同服务器上运行该服务的多个副本。如果一台服务器崩溃，其他服务器上的副本可以自动接管工作负载，因此客户不会注意到问题。

组织经常在关键领域建立冗余：

• 数据库：在不同位置存储数据的多个副本，以帮助确保在一个系统发生故障时不会丢失任何内容。

• 数据中心：跨多个物理站点托管应用程序，以便即使一个位置出现故障仍可继续运营。

• 云环境：跨区域或提供商（例如 Amazon Web Services (AWS)、Microsoft Azure 和 IBM® Cloud）分布应用程序，以消除单点故障。

• 网络连接：利用多个互联网或电信提供商在中断期间保持连接。

负载均衡涉及在多台服务器之间有效地分配网络流量，以帮助优化应用程序可用性。它对于应用程序弹性至关重要，因为即使在单个组件发生故障或过载时，系统也能保持性能和可用性。

例如，如果一台服务器响应迟缓，负载均衡器可以将流量自动重定向至其他正常的服务器，从而确保应用程序始终在线。

故障遏制是一种设计实践，可隔离分布式系统中的关键组件，防止局部问题引发系统范围的中断。

遏制在微服务架构中尤为重要，如果没有正确遏制，一项服务中的故障可能会迅速影响许多其他依赖项。

服务网格对于控制错误尤为实用。这些基础设施层有助于管理分布式应用程序中微服务间的通信，并提供：

• 自动重试：当请求由于临时问题（例如短暂的网络故障）而失败时，网格会自动重试，而不是立即放弃。

• 断开电路：网格监控服务健康状况，暂时停止向出现故障的服务发送请求，确保其及时恢复以预防系统级崩溃。

• 分布式跟踪：网格会跟踪在不同服务之间移动的请求，帮助团队发现速度下降并准确查明问题发生的位置。

将这些能力结合使用，有助于确保一项服务中的故障不会传播到其他服务。例如，假设电子商务网站上的产品推荐引擎出现故障。服务网格可以检测到这种故障，阻止请求到达损坏的服务，并相应地重新路由流量。用户可以继续浏览和购买而不会受到干扰。

可观测性使团队能够使用三种关键类型的数据实时监控系统健康状况：指标（响应时间等性能指标）、日志（错误或崩溃等事件记录）和跟踪（请求通过系统的完整旅程）。

通过捕获和分析这些信号，团队可以检测异常、快速诊断问题并减少停机时间。例如，如果客户报告网页加载缓慢，可观测性工具可以帮助工程师跟踪该请求，找到导致延迟的服务，并在问题影响更多用户之前修复问题。

自动化使系统无需人工干预即可响应问题，在应用程序弹性中发挥着关键作用。

例如，可观测性工具可以检测问题，而冗余可以提供备份资源。自动化将这些功能连接起来，协调恢复过程。有效的自动化可以显著缩短恢复时间，将可能需要数小时的手动故障诊断缩短为数秒的自动响应。

应用程序弹性中的部分关键自动响应包括：

• 脚本化故障转移：预定的操作序列，自动将操作从故障系统转移到通过冗余规划确定的备份系统。例如，如果主数据库崩溃，系统会在数秒钟内自动切换到备份数据库并将所有流量重定向到那里。

• 重新配置资源：组件发生故障时自动配置新实例或重新分配资源，例如创建新虚拟机来替换损坏的虚拟机，而无需任何人工干预。

• 自我修复工作流：协调监控警报和恢复行动，无需人工介入即可恢复服务。例如，如果某个应用程序占用过多内存，系统会在用户察觉到响应迟缓之前自动重启该应用程序。

像 Kubernetes 这样的工具（一个用于管理容器化应用程序的开源系统）演示了自动化如何将弹性组件联系在一起。Kubernetes 可以通过内置的健康检查来检测故障，在健康的节点之间重新安排工作量，并通过自动化工作流保持服务连续性。

适度降级指在系统承受压力的情况下维持核心功能，同时舍弃不必要的功能。例如，在“黑色星期五”流量高峰期，零售商可能会暂时禁用顾客评论和愿望清单功能，以确保购物车和结账功能正常运行。

可扩展应用程序可以根据工作量需求自动调整资源。即使流量波动，此功能也有助于确保性能和可用性。

可扩展性可以通过多种方式实现。例如，基于云的平台通过内置负载均衡器、自动扩展和多区域复制等功能提供可扩展性，即跨多个地理位置复制数据和服务以提高性能和可靠性。这些功能使服务能够智能地分配流量、保持正常运行时间并最大限度地缩短响应不断变化的条件的恢复时间。

例如，云托管流式数据平台通常可以在 100 台服务器上运行。但在全球直播活动期间，它可以自动扩展到多个区域的 10,000 台服务器，从而为数百万并发观众提供流畅播放体验。

由于软件应用程序对于企业运营和消费者的日常生活都变得至关重要，因此这些应用程序必须能够承受意外中断并在几乎所有条件下保持正常运行。

有四个因素尤其推动了人们对应用程序弹性的日益重视。

• 消费者的高期望
• 停机时间的成本
• 架构复杂性
• 监管压力

客户期望数字服务始终有效。根据 Google 的数据，如果移动页面的加载时间超过三秒，53% 的访问者会放弃该页面。

无论是银行应用程序、电子商务平台还是医疗保健门户网站，停机都可能引发客户流失、社交媒体抗议和持久的品牌损害。应用程序可用性不仅是一项技术指标，也是一项基本业务要求。

对于各种规模的组织来说，应用程序中断都可能产生高昂的成本。设想一个常见场景：某个零售品牌推出高客流量销售活动，但结账服务因需求激增而失效。几分钟之内，数千笔交易就会陷入停滞，致使客户感到沮丧，而公司也会因此蒙受损失。

除了销售损失之外，中断还会引发连锁次级成本，包括修复费用、服务水平协议 (SLA) 违规、监管处罚、客户赔偿乃至长期品牌损害。

最近发生的一些备受瞩目的事件表明，这种影响可能有多重大：

• 运输：2016 年，数据中心中断使 2,000 架次航班停飞，据报道，一家大型航空公司损失了 1.5 亿美元。

• 电子商务：在 2018 年的一个高峰销售活动中，技术中断使一家在线零售商损失了约 7,200 万美元至 9,900 万美元的收入。

• 社交媒体：2021 年，六小时的服务中断使一家互联网巨头损失了约 1 亿美元的广告收入。
  

现代应用程序架构有许多活动部件：微服务、多云环境、代码库等。虽然这些组件提高了可扩展性，但它们也增加了潜在故障点的数量。

如果缺乏弹性设计和实施方案，即使是小问题也可能升级。单个微服务故障可能会波及数十个依赖项。例如，如果存储产品信息的数据库服务停止运行，可能会干扰其他功能，例如搜索、推荐或结账。

云区域之间的网络中断也会造成服务碎片化，并导致数据不一致。与组件完全停止工作的微服务故障不同，这些连接问题会造成“脑裂”场景：应用程序的不同部分继续运行，但无法相互通信。

例如，金融交易应用程序的订单系统可能会与实时定价数据脱节，导致用户看到错误的报价或遇到交易失败。

应用程序编程接口 (API) 中断还会破坏关键功能。微服务故障会影响组织控制的内部组件，API 中断则涉及应用程序依赖却无法直接修复的第三方服务。例如，如果配送应用程序的地图服务出现故障，用户就无法跟踪配送人员的动态，配送人员也无法确定送货路线，即使核心应用程序仍在运行，也会破坏体验。

在某些行业和地区，监管机构对数据可用性、应用程序恢复功能、数据丢失缓解和运行时间提出了严格的要求。这些要求将应用程序弹性从技术目标提升为合规问题。

一些数据保护和隐私法律现在包括可用性标准和安全要求。例如，通用数据保护条例 (GDPR) 要求个人数据受到保护和可访问。如果系统出现故障，组织应恢复丢失的数据。

特别是，高度监管的行业面临一些最严格的标准。

尽管《萨班斯-奥克斯利法案》(SOX) 并未明确规定制定灾难恢复计划，但许多组织仍在维护备份系统和正式恢复程序，以确保遵守法案要求并验证其合规性。

金融机构还面临来自联邦金融机构检查委员会 (FFIEC) 等机构的针对特定行业的法规和建议；该委员会可提供有关业务连续性规划和恢复时间目标的详细指导。

根据《健康保险流通和责任法案》(HIPAA)，受保护实体必须实施管理、物理和技术保障措施，以帮助确保受保护的健康信息 (ePHI) 的可用性和完整性。虽然 HIPAA 并不要求全天候访问，但它要求医疗保健组织在治疗需要时保持对患者数据的访问。

HIPAA 安全规则对数据备份计划、灾难恢复程序和紧急模式运营提出了要求，这促使许多组织投资于先进的故障转移和数据复制策略。

为了帮助确保系统能够承受现实世界的中断，组织通过持续测量和主动测试相结合的方式验证应用程序的弹性。这些方法使团队能够监控性能、识别漏洞并确认应用程序是否可以快速有效地恢复。

尤其是 DevOps 开发运维团队，经常将弹性实践集成到持续集成/持续交付管道（CI/CD 管道）中。这样做可以让他们自动测试故障转移程序、验证配置更改并回滚不稳定的部署，从而及早发现问题并防止对用户造成干扰。

组织依靠多个关键指标来评估应用程序弹性。

各组织越来越多地转向测试，以获得更真实的视角。指标可以提供基础，测试可以帮助组织从理论就绪转到经过验证的弹性。

人工智能 (AI) 和机器学习 (ML) 正在重塑组织实现弹性的方式。这些技术为防止停机带来了强大的新工具，但也带来了独特的挑战。

最大的挑战之一是 AI 工作负载需要大量资源。许多模型依赖于图形处理单元 (GPU)，这些单元在云区域之间复制既昂贵又困难。这使得作为弹性重要组成部分的冗余更难实现。

AI 系统也可能以意想不到的方式出现故障。其准确性可能会随时间的推移而降低，这一问题称为“模型漂移”。或者，它们可能会遭遇对抗性输入，即旨在欺骗系统的恶意数据。这类故障可能更难预测和控制。

此外，当 AI 功能运行迟缓或停止运作时（因资源限制或延迟而导致的云环境常见问题），应用程序的其余部分仍应稳定运行，导致适度降级战略承受过多压力。

同时，AI 具有增强弹性的重要用例：

• 预测性分析预测通过分析历史模式和趋势来预测未来的故障。这有助于团队在问题发生之前主动更换硬件或调整资源，例如根据温度和错误率趋势提前几天预测磁盘故障。

• 智能修复利用 AI 制定更明智的恢复决策。虽然传统的自动化系统仅能重启失效服务，但人工智能驱动的修复可以分析模式以选择最佳恢复战略，例如将流量重新路由至负载较少的区域或根据预测需求扩展资源。

• 异常检测使 AI 能够识别基于规则的、监控可能遗漏的微妙的实时异常情况，例如即使单个指标看起来正常，但指标的异常组合也预示着新出现的问题。

• AI 驱动的测试允许开发运维 (DevOps) 团队在软件开发流程的初期阶段运用 AI 模拟更复杂的故障场景。

简而言之，虽然 AI 带来了新的复杂性，但它也可以实现更快的恢复、更智能的监控以及整体更具弹性的应用程序，尤其是在集成到云原生环境和 DevOps 开发运维管道中时。