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

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搭建高扩展性架构 实用性会更强一些，涉及服务会更多

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

4.1.2 EBS的例子

架构设计：Router53→EIP→EC2（+EBS）→RDS

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

4.1.3 ELB的例子

架构设计：Router53→ELB→EC2（more then 1）→RDS

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

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

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)单独出现问题，那么服务也将可以访问

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

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实例的数量

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实例宕机，那么弹性组也会补齐数量

5. 总结

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

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

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

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