写点什么

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

  • 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:003057
用户头像
张卫滨 业精于勤,行成于思。

发布了 625 篇内容, 共 464.2 次阅读, 收获喜欢 775 次。

关注

评论 1 条评论

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

极客时间学习心得:用分类和聚焦全面夯实技术认知

Anfernee Hu

学习

怎么用"设计思维"思考产品?

Yanel 说敏捷产品

产品 设计 产品设计 产品开发

我的事务为什么会失效

JFound

spring

小岑的架构学习笔记-架构设计的历史背景

程序员小岑

两边夹的应用三

孙苏勇

算法 两边夹

实战!我用 Wireshark 让你 “看得见“ TCP

小林coding

Linux TCP 计算机网络

k8s上运行我们的springboot服务之——简单的架构思考

柠檬

k8s springboot

云上数据库类产品的模式与发展趋势

韩超

数据库 redis 腾讯云 阿里云

健康饮食和定期运动带给我们的一点启示

董一凡

生活质量

乙己说:NUMA是个啥?

再见小飞侠

jdk G1 ZGC 内存

Spring注入的对象到底是什么类型

JFound

spring

k8s上运行我们的springboot服务之——热点数据

柠檬

redis

深入浅出SpringMVC系列~

程序员的时光

spring springmvc

Golang testing: “no test files”

北纬32°

Go 语言

永中云转换新升级 文档在线预览增添更多选择

DT极客

JVM源码分析之JVM启动流程

猿灯塔

KubeSphere权威指南(一)--------使用KubeSphere创建Percona Server,并对外暴露端口

赵欣

k8s percona server

乙己说:LRU实现思路整理

再见小飞侠

缓存 LeetCode Go 语言

[从零学习Spring Cloud]Nacos配置中心

玏佾

Spring Cloud nacos

要弄清楚if/switch的本质区别,以及优化方式

张驰

Java

程序员的晚餐 | 5 月 21 日 四季豆炒腊肠

清远

美食

科学理论的反思

美多丽可

学习

Android | Tangram动态页面之路(六)数据分离

哈利迪

android

语雀性感,印象迟暮。

彭宏豪95

学习 工具 在线办公

高内聚与低耦合

落英亭郎

面向对象 高内聚 低耦合

分布式数据库

Leiy

小岑的架构学习笔记-架构是什么?

程序员小岑

传统岗位新挑战:信息安全之路

nexpose

安全架构师 安全 安全管理

c++代码整洁之道

泰伦卢

c c++ C#

Python 如何随机打乱列表(List)排序

BigYoung

Python List random 随机

数据产品经理实战-开篇

第519区

产品经理

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