程序员人生 网站导航

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

栏目:服务器时间:2016-06-25 08:34:40

1. 邱洋总结

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

    • 这类专门针对云平台进行利用架构设计,有1个专属名词CDP(Cloud Design Pattern)
    • 可以访问:http://aws.amazon.com/architecture/ 查看更多
  2. 在AWS上设计容错架构的APP需要掌握5个设计模式

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

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. 设计原则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. 设计原则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,同时也会启动1个新的slave

图9

图10

图11

4.3. 设计原则3(自动扩大设计 )、4(自我修复设计)

架构设计(弹性设计):
- 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. 设计原则5:松耦合设计

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

媒体数据处理的场景:

架构设计#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/

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

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

图20

------分隔线----------------------------
------分隔线----------------------------

最新技术推荐