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

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. 設計原則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，同時也會啟動1個新的slave

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實例的數量

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實例宕機，那末彈性組也會補齊數量

5. 總結

容錯利用的設計原則
- 假定失效的設計
- 多可用區設計
- 自動擴大設計
- 自我修復設計
- 松耦合設計

更多參考資料
- AWS參考架構：http://aws.amazon.com/architecture/
- AWS白皮書：http://aws.amzon.com/whitepapers/

用工具測試1下高可用&容錯架構

使用開源的工具CHAOS Money
它會隨機將服務中的某個環節宕機，從而測試利用是不是能夠保證硬朗性