总结如何利用云平台构建容错的APP

Posted 邱洋inCloud

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了总结如何利用云平台构建容错的APP相关的知识,希望对你有一定的参考价值。

1. 邱洋总结

  1. 随着云平台的不断发展,利用云的服务来支撑应用变为常态

  2. 在AWS上设计容错架构的APP需要掌握5个设计模式

    • 假定失效的设计 (利用AWS原生容错的服务,如:ELB、EIP、S3等来增强EC2、EBS、RDS等承载业务应用服务的容错能力)
    • 多可用区设计 (跨数据中心的云服务使用方法)
    • 自动扩展设计 (使用弹性组来自动扩展)
    • 自我修复设计 (使用弹性组来自动修复)
    • 松耦合设计 (拆分应用,并使用SQS来传递消息)
  3. AWS还有另外的7大架构设计原则(针对应用设计),可以参考张侠的7大设计原则 参考文章:【总结】初创公司用AWS搭建高扩展性架构 实用性会更强一些,涉及服务会更多

2. 定义

2.1. 容错性的定义

  • 可用性

    • 在应用工作周期中可用时间的百分比
  • 不可用

    • 应用无法访问,服务中断
    • 应用访问非常缓慢
    • 计划中和非计划中
  • 目标

    • 在部分组件失效的情况下,保持系统,应用的可用

2.2. 与容错相关的事情

  • 扩展性

    • 不进行应用设计调整,应用能否满足访问增长?
    • 可能会影响可用性
  • 高可用能力

    • 建立高可用能力,有更多的备份恢复机制
    • 容错能力对高可用很关键
  • 灾备

    • 业务的连续性

3. AWS的基础设施

  • 全球分布式的基础设施

    • 大区(Region,美国东部、美国西部、美国政府、亚太东京……等11个)
    • 可用区(AZ,美国东部–4个、美国西部–2个……)
  • 天然高可用和容错的服务

    • S3
    • DynamoDB
    • SQS
    • Route53
    • ELB
    • ……
  • 可通过适当的架构设计实现高可用

    • EC2
    • EBS
    • RDS
    • VPC
    • ……

4. AWS中应用的设计原则

4.1. 设计原则一:假定失效的设计

  • 避免单点故障(SPoF)
  • 假定任何环节都有可能出问题,然后倒推依次设计
  • 目标是应用能够连续工作(如:EIP,EBS,ELB等)

4.1.1 EIP的例子

架构设计:Router53→EIP→EC2→RDS

如果EC2实例#1出现问题,那么可以启动另一个EC2实例#2,并将实例#1 的IP绑定给实例#2

图1

图2

4.1.2 EBS的例子

架构设计:Router53→EIP→EC2(+EBS)→RDS

如果EC2实例#1出现问题,那么可以启动另一个EC2实例#2,并将实例#1 的EBS卷绑定给实例#2

图3

图4

4.1.3 ELB的例子

架构设计:Router53→ELB→EC2(more then 1)→RDS

ELB后端有N个EC2实例,无论任何实例出现问题,那么ELB的流量将会停止分发流量到其他健康实例

如果配置了弹性组,那么当实例宕机,那么“弹性组”会自动补齐EC2实例的总数量

图5

图6

图7

4.2. 设计原则二:多可用区(AZ)设计

为了避免整个机房都宕掉,AWS设计了可用区AZ

架构设计(高可用设计):
- Router53→ELB→AZ(A)【EC2实例#1→RDS#master(multi-AZ架构)】
- Router53→ELB→AZ(B)【EC2实例#2→RDS#master→RDS#slave】

ELB后端有N个EC2实例,分别部署在AZ(A)和AZ(B),同时RDS采用了multi-AZ部署架构(master和slave也分别部署在AZ(A)和AZ(B)),这种情况下无论任何实例、RDS数据库、还是数据中心AZ(A)或AZ(B)单独出现问题,那么服务也将可以访问

图8

  • RDS的multi-AZ部署
    • 如果AZ(A)的master数据库出现问题,那么AZ(B)中的slave会自动升级为master,同时也会启动一个新的slave

图9

图10

图11

4.3. 设计原则三(自动扩展设计 )、四(自我修复设计)

架构设计(弹性设计):
- Router53→ELB→弹性组→AZ(A)【EC2实例#1→RDS#master(multi-AZ架构)】
- Router53→ELB→弹性组→ AZ(B)【EC2实例#2→RDS#master→RDS#slave】

相比于“高可用设计”例子,在这里ELB后端采用了弹性组(Auto Scaling Group —支持跨AZ扩展),这样实例数量增加就可以自动化【这里说的就是自动扩展设计】,且如果有实例出现问题,ASG也会自动补齐【这里说的就是自我修复设计】。

同时到达低谷期时也会自动缩减EC2实例的数量

图12

图13

图14

图15

图16

4.4. 设计原则五:松耦合设计

耦合度与灵活性相反
- 举例:动车载客的设计,如果有1000人,怎么设计车厢?A和B两种设计
- A:把车做的足够大,1000人都在里面,耦合大(坏掉一个都不可用了),管理不灵活
- B:每节车厢100人,要做10个车厢。耦合小(坏掉一个还有其余可用),但是足够灵活

媒体数据处理的场景:

架构设计#1(数据处理):Router53→ELB→弹性组【数据接收的EC2实例】→视频数据存入S3 AND 元数据存入DynamoDB→弹性组【转码的EC2实例】

架构设计#2(消息通知):数据接收服务(SQS)→转码服务(SQS)→发布&通知

架构设计#3(弹性设计):
- 未来在增加用户访问量的情况下,弹性组会增加EC2实例的数量,来处理数据接收
- 未来在SQS中处理的消息越来越多的时候(说明转码数量增加),弹性组也会增加EC2实例数量,来处理转码工作
- 如果某台EC2实例宕机,那么弹性组也会补齐数量

图17

图18

图19

5. 总结

容错应用的设计原则
- 假定失效的设计
- 多可用区设计
- 自动扩展设计
- 自我修复设计
- 松耦合设计

更多参考资料
- AWS参考架构:http://aws.amazon.com/architecture/
- AWS白皮书:http://aws.amzon.com/whitepapers/

用工具测试一下高可用&容错架构

使用开源的工具CHAOS Money
它会随机将服务中的某个环节宕机,从而测试应用是否能够保证健壮性

图20

以上是关于总结如何利用云平台构建容错的APP的主要内容,如果未能解决你的问题,请参考以下文章

如何构建企业级的容器云PaaS平台

如何搭建一个小型的云计算平台

如何在云中构建大规模分布式系统

Java生鲜电商平台-云平台架构设计与服务治理平台架构设计(小程序/APP)

有容云:实战总结之 利用DockerDocker Compose &Rancher构建持续部署

如何利用云原生技术构建现代化应用