1. 邱洋总结
- 随着云平台的不断发展，利用云的服务来支撑应用变为常态
- 这种专门针对云平台进行应用架构设计，有一个专属名词CDP（Cloud Design Pattern）
- 可以访问：http://aws.amazon.com/architecture/ 查看更多
- 在AWS上设计容错架构的APP需要掌握5个设计模式
- 假定失效的设计 （利用AWS原生容错的服务，如：ELB、EIP、S3等来增强EC2、EBS、RDS等承载业务应用服务的容错能力）
- 多可用区设计 （跨数据中心的云服务使用方法）
- 自动扩展设计 （使用弹性组来自动扩展）
- 自我修复设计 （使用弹性组来自动修复）
- 松耦合设计 （拆分应用，并使用SQS来传递消息）
- 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
它会随机将服务中的某个环节宕机，从而测试应用是否能够保证健壮性
