AWS 架構最佳實踐概述（十一）

時間 2019-11-08

標籤 aws 架構最佳實踐概述十一欄目系統架構简体版

原文原文鏈接

AWS 架構最佳實踐

AWS合理架構的框架支柱

安全性 - 保護並監控系統
- 可以保護信息、系統和資產
- 經過風險評估和緩解策略
可靠性 - 從故障中恢復並減小中斷
- 從基礎設施或服務故障中恢復
- 動態獲取計算資源以知足需求
- 減小配置錯誤和暫時性網絡問題來減小中斷
績效 - 謹慎使用資源
- 高效的使用計算資源以知足系統需求
- 在需求改變和技術發展時依舊保持效率
成本優化 - 消除沒必要要的費用
- 減小沒必要要的成本和次優資源
卓越操做

合理架構設計原則

中止猜測容量需求 - 傳統環境存在浪費
在生產層面測試系統 - 傳統環境下由於高昂的測試成本，因此一般都沒法真實模擬生產環境進行測試
下降架構改變風險 - 傳統環境中須要排隊等待的測試序列化，在測試過程當中的各類改變，可能影響後續測試。
經過自動化讓部署更簡單 - 低成本經過腳本建立並複製系統，追蹤變動和恢復
支持架構的不斷髮展 - 傳統環境受產品生命週期限制，前期決策也可能成爲阻礙，沒法響應不斷變化的業務需求
數據驅動型架構 - 在雲環境中，能夠經過CloudWatch收集相關數據，來了解架構負載狀況。雲基礎架構以代碼的形式存在，所以能夠利用這些數據來改善架構。
經過模擬大型流量實現改進 - 經過模擬大型流量，來改進架構中的不足之處，而且積累應對的經驗和方案。

高可用和冗餘

發現當前架構中的單點故障，引入冗餘來消除
選擇最適合的備份和恢復方案最高效的冗餘
使用不一樣的可用區實現地域高可用
利用Route53和ELB主動切換來實現主動的冗餘機制減小中斷時間

彈性設計

彈性系統是隨時間推移或響應業務需求忽然變化以應對增加的負載，隨用戶、流量、數據大小的增加而不會影響性能
資源增加應該引入規模經濟效益，成本應遵循童謠你給的維度從而使該系統創造商業價值
- 垂直縮放
  - 經過中止實例調整更多的CPU、RAM、IO、網絡等功能實現
  - 垂直縮放有其上限、且不容易實現
- 水平縮放
- 無狀態應用程序
- 全部操做不須要知道過去的上下文，會話也不會被存儲
- 能夠進行任意的水平擴展且可隨意的安全終止，由於系統資源間不會共享會話數據
- 全部節點不須要意識到其餘節點的存在，只須要處理分配給他的工做量便可
Autoscaling是最佳實踐
- 無狀態組件
  - 大多數應用程序都須要維護某些狀態信息，如登陸信息等。
  - 方案一：
    - 應用程序能夠經過用戶會話標識存儲在客戶端本地（如HTTP Cookie）實現必定程度的無狀態，可是會存在兩個問題：
    - 放在客戶端本地Cookie的信息容易被篡改，每次都須要傳送用戶會話狀態佔用資源增長延遲
  - 方案二：
    - 用戶會話信息存儲在服務器關聯的數據庫中，如DynamoDB，從而實現服務器組件的無狀態化
- 有狀態組件
  - 不少應用程序和體系結構都沒法轉變成無狀態的
  - 許多遺留系統設置被設計成必須依靠本地單獨計算資源運行的

自動化部署

公有云最大的好處就是可以利用API來自動化部署過程，建議從一開始就進行自動化部署
自動化和可重複部署將有效的減小錯誤並促使高效的可擴展更新過程
Bootstrap 實例
- 利用自動化動做Bootstrap實例
  - 在初始化過程當中用於只是簡單的指定如名稱、角色信息，其餘都有腳本自動完成，對不一樣的選項提供全部必要的自動化啓動資源，包括code、script和configuration等。
- 重複建立相同環境
- 對雲基礎架構保持抽象
- 減小人工部署錯誤機會
- 建立一個自我發現和自我修復的環境

選擇合適的存儲

S3
- Web須要大規模存儲容量和性能
- 高耐久性數據，以及支持災難恢復的備份
Glacier
- 數據歸檔和長期備份
Cloudfront
- 利用內容交付網絡在全球邊緣位置部署靜態、動態、流媒體和交互式內容
DynamoDB
- 快速且靈活的NoSQL數據庫，靈活的數據模型和可靠的性能
- 能夠用來解耦有狀態應用，將用戶狀態存儲在DynamoDB中使應用程序能夠實現無狀態組件
EBS
- 可靠地塊存儲運行關鍵程序，如Oracle，SAP，Exchange等
RDS
- 高可用的SQL數據庫
Redshift
- PB級數據倉庫，支持業務分析
ElasticCache
- Redis集羣內存緩存
EFS （彈性文件系統）
- 多個EC2實例之間共享應用程序的通用文件系統

在每一層創建安全

傳統的安全審計是按期和審計的，可是在雲端能夠提供持續監控和治理，同事利用代碼將安全策略嵌入基礎設施設計
最佳實踐
- 對數據進行清點和優先級排序，在傳輸和存儲時應用適當的加密級別
- AWS功能實現多級防護
  - 網絡層面： VPC 、子網、安全組、路由控制
  - 主機層面： WAF、 IAM
- 將安全交給AWS
  - 使用AWS 託管服務，由AWS進行補丁和安全管理
  - 減小特權訪問
  - 應用程序使用臨時安全令牌在EC2上運行
- 使用IAM進行帳戶和權限管理
  - 使用臨時令牌提供聯合訪問
  - 對憑據進行自動分發和輪換
  - 授予最小權限的標準安全慣例
- 利用代碼實現安全
  - 利用CloudFormation腳本進行可靠地安所有署稱爲"Golden Environment"
  - 最佳安全實踐將會被很容易的在不一樣環境中重用而且集成到CICD pipeline中
  - 能夠利用安全測試自動發現與安全策略基線的誤差
  - CloudFormation 能夠做爲產品導入AWS Service Catalog 中進行一致性治理
- 實時審計
  - AWS實現持續監控和控制自動化，最大限度下降安全風險
  - 藉助Config Rules 能夠知道某個組件是否在短期內不合規
  - CloudWatch提供普遍的日誌記錄、
  - CloudTrail 實現實際的API調用
  - 全部日誌能夠備Lambda、EMR等自動處理

並行化處理思惟

雲中能夠輕鬆實現並行處理
如檢索和存儲數據時，雲被設計成處理大規模並行操做，因此爲了提升性能和吞吐率，應該儘量使用並行請求設計
Web應用程序，應該設計成支持ELB負載均衡的傳入請求分佈的並行處理
批處理場景下更多的使用擁有多從屬節點的hadoop架構

鬆耦合設計

將系統設計成多個獨立組建的系統體系，組件越鬆散，相互依賴性越低，系統規模就能更大
Amazon API Gateway提供了公開定義接口的方法，是徹底託管的服務
支持開發人員建立、發佈、維護和監控以及保護各類規模API
能夠處理所涉及的數十萬併發的API調用，包括流量管理、受權和訪問控制
異步集成是鬆耦合的經常使用模式，利用SQS或者Kinesis進行鬆耦合集成
利用異步集成耦合能夠引入額外的彈性，能夠對處理失敗的消息進行再次處理

AWS最佳實踐

實現擴展架構 - 以應對需求變化
自動部署環境 - 消除手工操做提升系統的穩定性和一致性，並提升組織效率
使用一次性資源 - 將服務器和其餘組件視爲臨時資源
鬆耦合組件 - 下降相互依賴，當一個組件變化或出故障時，其餘組件不受影響，ELB和SQS是主要解耦解決方案
設計服務而不是設計服務器 - 託管方案和無服務架構讓環境實現更高的可靠性和環境，如Lambda, SQS,SNS,DynamoDB
更合適的數據庫解決方案 - 技術與工做負載相匹配，選擇關係型數據庫，NoSQL數據庫，數據倉庫以及針對搜索優化過的數據存儲
避免單點故障 - 實施冗餘以免單點故障破壞整個系統，能夠選擇停機啓動的自動化解決方案或者託管服務在故障時自動對底層進行替換
優化成本 - 確保資源規模適當、能夠根據需求進行自動縮減和擴展，充分利用不一樣的訂價方案. 將資本性支出轉變爲可變支出。
使用緩存 - 儘量減小冗餘數據檢索操做
在各個位置保護基礎設施安全 - 能夠在外圍和資源內部或資源之間實現安全性

事件驅動架構

概述

雲計算的優點就是快速對資源需求方面的變化做出響應，以應對變化。
傳統模式下，即使是在雲計算平臺中，當服務器滿負荷也會致使沒法響應訪問，雖然手工擴展只須要幾分鐘時間，可是也是不能接受的

基於事件驅動的架構

監控解決方案CloudWatch
- 利用CloudWatch監控服務器隊列，經過設置多樣的閾值來觸發擴展，閾值規則設置能夠設定到特定的應用程序自定義指標。
AutoScaling
- 經過收到CloudWatch的告警進行實例擴展，在應用服務達到全容量前就準備就緒來提供無縫體驗
- 垂直擴展
  - 對實例規格進行變化，如CPU、內存等
  - 垂直擴展始終有其天花板，並且可能會存在更多的性能問題，如Java堆棧過大形成的回收時長，並且可能須要重啓服務器
- 水平擴展
  - 對實例數量進行變化，添加和刪除實例
  - 幾乎沒有任何能力限制，只是應用程序設計的過程當中須要考慮對水平擴展的支持

EC2 Auto Recovery
- 當EC2出現問題時，對受損的實例自動恢復功能或自動替換
- 經過CloudWatch 檢測可能由於網絡鏈接丟失、系統電源損耗、主機軟硬件問題致使的EC2受損
- 替換實例是能夠保持相同的實例ID，元數據、IP地址，可是內存數據將會丟失
- 在中國區尚不支持
- 不能使用實例存儲必須是EBS支持的存儲