程序员人生 网站导航

【总结】如何利用云平台构建容错的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

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

上一篇 操作系统：内存管理（概念）

下一篇 Linux下1号进程的前世(kernel_init)今生(init进程)----Linux进程的管理与调度（六）

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

最新技术推荐

1Linux sed编辑器 2[置顶] Mesos+Marathon对比Kubernetes 3如何获取Azure Tenant的Tenant Id? 4使用Ganglia监控Zookeeper 5Hadoop启动、作业提交及错误修改 6《跟老男孩学Linux运维：Shell编程实战》--互动出版网 7centos安装kubernetes1.3(一)