写点什么

规避云服务宕机的架构设计方法

  • 2021-01-18
  • 本文字数:1499 字

    阅读完需:约 5 分钟

规避云服务宕机的架构设计方法

本文最初发表于For Else网站,经原作者 Jeff Carter 许可,由 InfoQ 中文站翻译分享。


前段时间,AWS 发生宕机事故,很多服务中断。从架构角度,我们如何去应对这种宕机,网上有很多相关讨论。但是这些讨论太复杂,并且在成本、复杂性和权衡方面差异很大。所以,我决定简要介绍其中的一种方法。

多云


首先,就是关于多云价值的讨论。它的理念就是在多个云中运行你的应用。



通过将负载分散到多个供应商,我们就能在其中的某一个供应商出现故障的时候得以幸免于难。在理论上,这种方式听起来很不错!当然,两家云厂商不会同时宕机。但是,在实践中,由于种种原因,在应用层面这样做是很困难的:


  • 每种云的基础设施是不同的

  • 部署的复杂性会大幅度增加

  • 两者之间的带宽费用相当高昂


鉴于此,多云架构并不是高可用的可行方案(少数的边缘情况除外)。

多 Region


接下来,是关于多 Region 的讨论。AWS Region 是由多个可用区(availability zone,AZ)组成的,每个 AZ 是一个或多个的数据中心,它们具有独立的电源、网络和连接。在一个 Region 的多个 AZ 中运行能提供高可用性,但是无法提供灾难恢复(Disaster Recovery,DR)功能。为实现这一点,我们需要多个 Region。一个非常简略的多 Region 结构如下所示:



这种方式解决了多云架构的多个问题:


  • 应用依然在同一个云中运行,所以基础设施保持不变

  • Region 是完全独立的,因此能获得同样的可用性优势

  • Region 之间的带宽费用要比云之间的费用低得多


但令人遗憾的是,大多数的评论都是围绕 Active-Active 的多 Region。也就是将负载同时分布到多个 Region,这带来了很多关于持久化同步方面的复杂性。同时,这种方式也会增加部署方面的复杂性,并且很多地方都很容易出错,甚至它本身的停机时间比 AWS 导致的宕机时间可能还要长。

多 Region DR


这是一种常被忽视的方案。它的理念是在同一时间只有一个 Region 处于活跃状态,在发生灾难的时候,另外一个备用的 Region 能接管系统的功能(因此是 DR)。这种方式和上面所述方案的收益是一样的,但是它能极大地规避全 Active-Active 架构的复杂性。在这种架构下,备用 Region 不用完全构建,只需要复制持久化数据即可。



但是,稍等,在发生灾难时,部署完整的应用栈难道不需要一段时间吗?是的,是这样的,不过这是允许的!对大多数常见的中断场景来说,高可用是通过使用多 AZ 实现的,这种方式就足够了。如果整个 Region 出现问题,就像我们前段时间在 AWS 上所看到的那样,花费小于一个小时的时间从备份中建立一个新的应用栈,仍然要比大于八个小时的中断更可取。这个过程可以通过自动化的方式来进行简化,但即便是手动的(但经过了实践检验)操作,有可选的备用方案也是很重要的。


所以,我们更深入地探讨一下这种架构:


  • 应用程序像平常那样部署在主 Region 中

  • 使用 AWS 托管的服务、备份和副本实现数据持久化,这通常只需要一两个配置即可:

  • 在不同的 Region 中为 RDS 添加一个读副本

  • 创建 Dynamo DB global 表

  • 启用 S3 bucket 副本

  • 在进行故障恢复的时候,将应用程序部署在其他的 Region 上,并更新 DNS 的设置

  • 这一过程要定期进行测试


这是一个银弹吗?绝不是。它并不适用于任何类型的工作负载,也绝对不可能适用于任何类型的宕机。然而,它是一个相对简单的方案,并且有一定的成本效益。


总结


总之,中断肯定是会发生的,这丝毫不会降低 AWS 的价值,但是这确实表明了良好架构和规划的重要性。我们可以设计一些非常昂贵和复杂的系统来缓解这些中断,但这对大多数客户来说是过犹不及和不切实际的。幸运的是,我们还有一些其他的选择,它们可能会提供一个“足够有效”的解决方案,并有合理的权衡,这应该成为在 AWS 上开展工作时的“最佳实践”。


原文链接:


https://www.forelse.io/posts/architectures-for-mitigating-aws-outages

2021-01-18 12:002881
用户头像
张卫滨 业精于勤,行成于思。

发布了 591 篇内容, 共 437.2 次阅读, 收获喜欢 763 次。

关注

评论 1 条评论

发布
用户头像
成本为王,不做备份
2021-01-20 10:49
回复
没有更多了
发现更多内容

【墨菲安全实验室】Microsoft Teams 远程代码执行漏洞 (CVE-2023-29330)

墨菲安全

安全 漏洞 网络安全、 Microsoft Teams

值得收藏!堪称神器的30个插件

Finovy Cloud

插件 渲染 建模 maya 3d建模

【华秋干货铺】电源PCB设计汇总

华秋电子

UE虚幻引擎游戏开发:游戏鼠标双击判定方法!

3DCAT实时渲染

UE虚幻引擎 UE教程 3D游戏制作教程

【墨菲安全实验室】WPS Office 存在代码执行漏洞

墨菲安全

网络安全 安全 漏洞 WPS Office

腾讯云大数据ES:结合AI大模型与向量检索的新一代云端检索分析引擎

腾讯云大数据

ES

【低代码预研】通过低代码平台开发应用程序

互联网工科生

软件开发 低代码 应用开发 JNPF

百度、NVIDIA、Intel……各大厂商集结,共话文心与飞桨共享生态下的大模型训推部署创新实践计划

飞桨PaddlePaddle

人工智能 百度飞桨 硬件生态 WAVE SUMMIT

IoTDB 小白“踩坑”心得:入门安装部署篇

Apache IoTDB

面部表情识别在医疗领域的应用

数据堂

【墨菲安全实验室】Microsoft Exchange Server 远程代码执行漏洞(CVE-2023-38182)

墨菲安全

网络安全 安全 漏洞 Microsoft Exchange

PP-ChatOCR:基于文心大模型的通用图像关键信息抽取利器,开发提效 50%!

飞桨PaddlePaddle

人工智能 百度飞桨

甭提ChatGPT了,这个新的AI助手将永远改变人们的工作方式

互联网工科生

人工智能 AI 机器人

面部表情识别技术的挑战与解决方案

数据堂

确保数据一致性:单一可信数据源(SSOT)的概念与5个应用示例

龙智—DevSecOps解决方案

ssot single source

嵌入式软件开发为什么需要DevOps?

DevOps和数字孪生

DevOps 嵌入式软件

大型集团公司如何打破“信息孤岛”问题?

优秀

打破信息孤岛 消除信息孤岛 信息孤岛

【墨菲安全实验室】Zoom Desktop Client for Windows <5.14.5 权限升级漏洞(CVE-2023-36541)

墨菲安全

网络安全 安全 Zoom 漏洞 墨菲安全

如何在Confluence上设置到期日提醒?Confluence到期日提醒插件重要更新发布,优化表格提醒,增加屏蔽提醒功能

龙智—DevSecOps解决方案

confluence插件

〔支付接入〕微信的 h5 支付和 jsapi 支付

江户川码农

微信支付 支付 经验分享 H5支付 jsapi支付

实现分布式事务:Java与MySQL的XA事务协调

树上有只程序猿

Java MySQL 数据库 分布式 XA

【墨菲安全实验室】Microsoft Office Visio 远程执行代码漏洞(CVE-2023-36865)

墨菲安全

网络安全 安全 漏洞 Microsoft Office Visio

Dragonfly 发布 v2.1.0 版本!

SOFAStack

AI 算法 后端 基础设施 分发

面部表情识别技术在安全领域的应用

数据堂

从推动到拉动:研发效能提升的第一性原理

CODING DevOps

电动汽车安全概述

DevOps和数字孪生

电动汽车 汽车安全

巧用Maya轴心操作小技巧,工作事半功倍!

3DCAT实时渲染

maya制作技巧 3D软件教程

规避云服务宕机的架构设计方法_架构_Jeff Carter_InfoQ精选文章