萬字長文：雲架構設計原則

譯者序

AWS用戶普遍，產品線複雜，AWS發佈的白皮書《Architecting for the Cloud-AWS Best Practices》介紹了常見場景下雲架構的最佳實踐，不只對於使用AWS的用戶，對於廣大使用雲的用戶都有參考意義，新鈦雲服工程師特地翻譯了本白皮書，供廣大使用雲的用戶參考。

 

請點擊輸入圖片描述

 

1. 摘要

本白皮書適用於在Amazon Web Services（AWS）上的構建解決方案的架構師和開發人員。本白皮書提供有關技術設計模型的架構指導和建議，以及如何應用於雲計算環境中。本白皮書提供了在AWS上設計解決方案時的關鍵概念和差別。本白皮書還討論瞭如何利用特定於雲計算動態特性的屬性，如彈性和基礎設施自動化。這些模型能夠爲對選擇、操做狀態和實現狀態進行更詳細的審查提供上下文，就像《AWS Well-Architected Framework》中詳細描述的那樣.

2. 介紹

將應用程序遷移到AWS，即便沒有重大更改（稱爲直接遷移的方法），也可爲組織提供安全且經濟高效的基礎架構優點。可是，爲了充分利用雲計算可能帶來的彈性和靈活性，工程師必須改進其架構以利用AWS功能。

對於新應用程序，基於雲的IT體系架構模型能夠幫助提升效率和可伸縮性。這些新架構能夠支撐從互聯網規模數據的實時分析到具備數千個鏈接的物聯網（IoT），或移動設備的不可預測流量的應用程序的任何內容。

不管是從新架構在本地環境中運行的當前應用程序以在AWS上運行，仍是設計雲原生應用程序，你都必須考慮傳統環境與雲計算環境之間的差別。這包括體系架構選擇，可伸縮性，資源類型，自動化以及靈活的組件，服務和數據庫。若是你不熟悉AWS，咱們建議你查看「 About AWS」頁面上的信息，以便基本瞭解AWS服務。

3. 傳統環境和雲計算環境之間的差別

雲計算在許多方面不一樣於傳統的本地環境，包括靈活，全局和可擴展的容量，託管服務，內置安全性，成本優化選項以及各類操做模型。

3.1 IT資產做爲可配置資源

在傳統計算環境中，能夠基於理論最大峯值的估計來提供容量。這可能致使階段性昂貴的資源閒置或容量不足。藉助雲計算，能夠根據須要訪問儘量多的容量，並動態擴展以知足實際需求，同時只需爲使用的資源付費。

在AWS上，能夠在幾秒鐘內實例化服務器，數據庫，存儲和更高級別的應用程序組件。能夠將這些視爲臨時資源，而不受固定和有限IT基礎架構的不靈活性和限制。這會重置處理變動管理，測試，可靠性和容量規劃的方式。這種方法的改變經過引入流程中快速失敗和快速迭代的能力來鼓勵體驗。

3.2 全球，可用和可擴展的容量

使用AWS的全局基礎架構，能夠將應用程序部署到最符合你要求的AWS可用區域（例如，與最終用戶的接近程度，合規性，數據駐留限制和成本）。對於全局應用程序，可使用Amazon CloudFront內容交付網絡（CDN）在全球範圍內減小到終端用戶的延時。這也使得跨多個數據中心操做生產應用程序和數據庫變得更加容易，從而實現高可用性和容錯性。AWS的全球基礎架構以及根據須要配置容量的能力，使你能夠根據對應用程序的需求和服務範圍的擴展，來對你的基礎架構進行不一樣的思考。

3.3 更高級的託管服務

除了Amazon Elastic Compute Cloud（Amazon EC2）的計算資源外，還能夠訪問各類存儲，數據庫，分析，應用程序和部署服務。因爲這些服務可當即供開發人員使用，所以可減小對內部專業技能的依賴，並使組織可以更快地交付新解決方案。管理的AWS服務能夠下降運營複雜性和成本。它們還具備可擴展性和高可用性，所以能夠下降實施風險。

3.4 內置安全性

在傳統IT環境中，基礎架構安全審覈能夠是按期和手動過程。相比之下，AWS Cloud提供的治理功能能夠持續監控IT資源的配置更改。AWS的安全性是最高優先級，這意味着能夠從爲知足大多數安全敏感組織的要求而構建的數據中心和網絡體系結構中受益。

因爲AWS資源可以使用工具和API進行編程，所以能夠將安全策略正式化並嵌入基礎架構設計中。因爲可以啓動臨時環境，安全測試如今能夠成爲持續交付流水線的一部分。最後，能夠利用各類雲原生的AWS安全和加密功能，這些功能能夠幫助你實現更高級別的數據保護和合規性。

3.5 成本架構

內部部署解決方案的傳統成本管理一般不與提供服務緊密耦合。在配置雲計算環境時，優化成本是架構師的基本設計租戶。選擇解決方案時，不只應關注功能架構和功能集，還應關注所選解決方案的成本配置文件。

AWS提供細粒度計費，使你可以跟蹤與解決方案的全部方面相關的成本。有一系列服務可幫助你管理預算，提醒你產生的費用，並幫助你優化資源使用和成本。

3.6 AWS上的運維

在AWS上運行服務時，有幾種常見的運維模型：

• 遷移的應用程序，維護現有的傳統操做模型，利用經過API管理基礎架構做爲代碼的能力，從而實現可靠且可重複的構建過程，從而提升可靠性。
• 重構的解決方案利用更高級別的操做流程自動化做爲支持服務，例如， AWS Auto Scaling和自我修復架構。
• 針對雲運營從新構建和設計的解決方案一般經過DevOps流程實現全面自動化，以實現交付管道和管理。

支持這些轉變不只會改變所使用的技術，還會改變開發和運維團隊管理方式的文化變化。

AWS提供工具，流程和最佳實踐，以支持運維實踐的轉變，從而最大限度地利用雲計算帶來的收益。

4. 設計原則

AWS 包含許多可應用於各類用例的設計模式和體系結構選項。AWS的一些關鍵設計原則包括可擴展性，可支配資源，自動化，用鬆耦合管理服務，以及靈活的數據存儲選項。

4.1 可擴展性

預計隨着時間的推移而增加的系統須要創建在可擴展的架構之上。這樣的體系架構能夠支持用戶，流量或數據大小的增加，而不會下降性能。應該以線性方式按比例提供資源，添加額外資源至少致使成比例增長提供額外負載的能力。增加應引入規模經濟，成本應遵循從該系統產生商業價值的相同維度。雖然雲計算提供幾乎無限的按需容量，但你的設計須要可以無縫地利用這些資源。

一般有兩種擴展IT架構的方法：縱向擴展和橫向擴展。

4.1.1 縱向擴展

縱向擴展經過增長單個資源的規模來實現，例如升級具備更大硬盤驅動器或更快CPU的服務器。使用Amazon EC2，你能夠中止實例並將其調整爲具備更多RAM，CPU，I/O或網絡功能的實例類型。這種縮放方式最終將達到極限，而且它並不老是具備成本效益或高度可用的方法。可是，它很容易實現，而且對於許多用例來講已經足夠了，特別是在短時間內。

4.1.2 橫向擴展

經過增長資源數量來橫向擴展，例如向存儲陣列添加更多硬盤驅動器，或添加更多服務器以支持應用程序。這是構建利用雲彈性的互聯網規模應用程序的好方法。並不是全部體系結構都旨在將其工做負載分配給多個資源，所以讓咱們檢視一些可能的狀況。

1) 無狀態應用

當用戶或服務與應用程序交互時，一般會執行一系列造成會話的交互。會話是用戶在使用應用程序時在請求之間保持不變的惟一數據。無狀態應用程序是不須要先前交互知識，且不存儲會話信息的應用程序。例如，給定相同輸入，向任何最終用戶提供相同響應的應用程序是無狀態應用程序。無狀態應用程序能夠橫向擴展，由於任何可用的計算資源（例如EC2實例和AWS Lambda函數）均可覺得任何請求提供服務。若是沒有存儲會話數據，能夠根據須要添加更多計算資源。當再也不須要該容量時，能夠在運行任務耗盡後安全地終止這些單獨的資源。這些資源不須要知道同伴的存在，所須要的只是將工做負載分配給它們的方法。

2) 將負載分配給多個節點

要將工做負載分配到環境中的多個節點，能夠選擇推模型或拉模型。

使用推模型，可使用Elastic Load Balancing（ELB）來分配工做負載。ELB跨多個EC2實例路由傳入的應用程序請求。在路由流量時，網絡負載均衡器在開放系統互連（OSI）模型的第4層運行，以處理每秒數百萬個請求。經過採用基於容器的服務，還可使用應用程序負載均衡器。應用程序負載均衡器提供OSI模型的第7層，並支持基於應用程序流量的基於內容的請求路由。或者，可使用Amazon Route 53實施DNS輪詢。在這種狀況下，DNS響應以循環方式從有效主機列表中返回IP地址。雖然易於實施，但這種方法並不總能很好地適應雲計算的彈性。這是由於即便你能夠爲DNS記錄設置低生存時間（TTL）值，緩存DNS解析器也不在Amazon Route 53的控制範圍內，而且可能並不老是遵循你的設置。

能夠爲異步，事件驅動的工做負載實現拉模型，而不是負載平衡解決方案。在拉模型中，須要執行的任務或須要處理的數據可使用Amazon Simple Queue Service（Amazon SQS）做爲消息存儲在隊列中，也能夠做爲流數據解決方案存儲

好比亞馬遜Kinesis，多個計算資源能夠提取和使用這些消息，以分佈式方式處理它們。

3) 無狀態組件

實際上，大多數應用程序都維護某種狀態信息。例如，Web應用程序須要跟蹤用戶是否已登陸，以即可以基於先前的操做呈現個性化內容。自動化的多步驟過程還須要跟蹤先前的活動，以肯定其下一步應該是什麼。仍然能夠經過不在本地文件系統中存儲須要多於一個請求的任何內容，來使這些體系結構的一部分無狀態。

例如，Web應用程序可使用HTTP cookie在Web客戶端緩存中存儲會話信息（如購物車項目）。瀏覽器在每一個後續請求時將該信息傳遞迴服務器，以便應用程序不須要存儲它。可是，這種方法有兩個缺點。首先，HTTP cookie的內容可能會在客戶端被篡改，所以你應始終將其視爲必須通過驗證的不可信數據。其次，HTTP cookie隨每一個請求一塊兒傳輸，這意味着你應該將其大小保持在最小，以免沒必要要的延遲。

考慮僅在HTTP cookie中存儲惟一的會話標識符，並在服務器端存儲更詳細的用戶會話信息。大多數編程平臺都提供以這種方式工做的本機會話管理機制。可是，默認狀況下，用戶會話信息一般存儲在本地文件系統中，從而造成有狀態架構。此問題的常看法決方案是將此信息存儲在數據庫中。Amazon DynamoDB是一個很好的選擇，由於它具備可擴展性，高可用性和耐用性特徵。對於許多平臺，有一些開源替代庫，容許你在Amazon DynamoDB中存儲本機會話。

其餘方案須要存儲較大的文件（例如用戶上載和批處理的中間結果）。經過將這些文件放在共享存儲層（如Amazon Simple Storage Service，Amazon S3；或Amazon Elastic File System，Amazon EFS））中，能夠避免引入有狀態組件。

最後，複雜的多步驟工做流是另外一個必須跟蹤每一個執行的當前狀態的示例。可使用AWS步驟功能集中存儲執行歷史記錄，並使這些工做負載無狀態。

4) 有狀態組件

不可避免地，你的架構層將不會變成無狀態組件。根據定義，數據庫是有狀態的。有關更多信息，請參閱後面的「數據庫章節"。此外，許多遺留應用程序設計爲依靠本地計算資源在單個服務器上運行。其它用例包括可能須要客戶端設備長時間保持與特定服務器的鏈接。例如，實時多人遊戲必須以很是低的延遲爲多個玩家提供一致的遊戲世界視圖。在非分佈式實現中實現這一點要簡單得多，其中參與者鏈接到同一服務器。

仍然能夠經過將負載分配到具備會話親緣關係的多個節點來水平擴展這些組件。在此模型中，將會話的全部事務綁定到特定的計算資源。可是，這個模型確實有一些侷限性。現有會話不會直接受益於新啓動的計算節點的引入。更重要的是，沒法保證會話親和力。例如，當節點終止或變得不可用時，綁定到該節點的用戶將斷開鏈接並遇到特定於會話的數據丟失，這些數據不會存儲在共享資源，如Amazon S3，Amazon EFS或a數據庫。

5) 實現會話親和性

對於HTTP和HTTPS流量，你可使用應用程序負載均衡器的粘性會話功能，將用戶的會話綁定到特定實例。使用此功能，應用程序負載均衡器將嘗試在該持續時間內爲該用戶使用相同的服務器會議。另外一個選項，若是你控制在客戶端上運行的代碼，是使用客戶端負載平衡。這會增長額外的複雜性，但在負載均衡器不符合你的要求的狀況下很是有用。例如，你可能正在使用ELB不支持的協議，或者你可能須要徹底控制如何將用戶分配給服務器（例如，在遊戲場景中，可能須要確保遊戲參與者匹配並鏈接到相同的服務器）。在此模型中，客戶端須要一種方法來發現有效的服務器端點以直接鏈接。可使用DNS，或者你能夠構建一個簡單的發現API，以便將該信息提供給客戶端上運行的軟件。在沒有負載均衡器的狀況下，還須要在客戶端實現健康檢查機制。應該設計客戶端邏輯，以便在檢測到服務器不可用時，設備從新鏈接到另外一臺服務器，而對應用程序幾乎沒有中斷。

6) 分佈式處理

涉及處理大量數據的用例，沒法及時處理單個計算資源的任何事物，須要採用分佈式處理方法。經過將任務及其數據劃分爲許多小的工做片斷，能夠跨一組計算資源並行執行它們。

7）實施分佈式處理

經過使用AWS Batch，AWS Glue和Apache Hadoop等分佈式數據處理引擎，能夠水平擴展脫機批處理做業。在AWS上，可使用Amazon EMR在一組EC2實例之上運行Hadoop工做負載，而無需運維複雜性。對於流數據的實時處理，Amazon Kinesis將數據分紅多個分片，而後由多個Amazon EC2或AWS Lambda資源使用，以實現可擴展性。

有關這些類型工做負載的更多信息，請參閱《Big Data Analytics Options on AWS 》和《Core Tenets of IoT》白皮書。

4.2 一次性資源而不是固有服務器

在傳統的基礎架構環境中，因爲引入新硬件的前期成本和前置時間，必須使用固定資源。這推進了諸如手動登陸服務器以配置軟件或修復問題，硬編碼IP地址以及按順序運行測試或處理做業等實踐。

在爲AWS設計時，能夠利用雲計算的動態配置特性。能夠將服務器和其餘組件視爲臨時資源。能夠根據須要啓動任意數量實例，而且只在須要時使用它們。

長期運行的服務器的另外一個問題是配置誤差。隨時間推移應用的更改和軟件修補程序可能會致使跨不一樣環境的未經測試和異構配置。可使用不可變的基礎架構結構模型模式解決此問題。使用這種方法方式，服務器一旦啓動永遠不會更新。相反，當出現問題或須要更新時，問題服務器將替換爲具備最新配置的新服務器。這使資源始終處於一致（和測試）狀態，並使回滾更容易執行。使用無狀態體系結構更容易支持這一點。

4.2.1 實例化計算資源

不管是部署新環境進行測試，仍是增長現有系統的容量來應對額外負載，你都不但願使用其配置和代碼手動設置新資源。重要的是，你要使其成爲一個自動化且可重複的過程，以免較長的交付週期，而且不會出現人爲錯誤。有幾種方法能夠實現這一目標。

1）引導

啓動AWS資源（如EC2實例或AmazonRelational Database Service（Amazon RDS）數據庫實例）時，將啓動默認配置。而後，能夠執行自動引導操做，這些操做是安裝軟件或複製數據以將該資源帶入特定狀態的腳本。能夠參數化在不一樣環境（例如生產或測試）之間變化的配置詳細信息，以即可以重複使用相同的腳本而無需進行任何修改。

可使用用戶數據腳本和cloud-init指令設置新的EC2實例。可使用簡單的腳本和配置管理工具，例如Chef或Puppet。此外，經過自定義腳本和AWS API，或AWS AWS支持的自定義資源的AWS CloudFormation支持，能夠編寫幾乎適用於任何AWS資源的配置邏輯。

2）黃金鏡像

某些AWS資源類型（例如EC2實例，AmazonRDS數據庫實例和Amazon Elastic Block Store，Amazon EBS）能夠從黃金鏡像啓動，黃金鏡像是該資源的特定狀態的快照。與引導方法相比，黃金鏡像能夠縮短啓動時間並消除對配置服務或第三方存儲庫的依賴性。這在自動擴展環境中很是重要，在這種環境中，你但願可以快速可靠地啓動其餘資源，以響應需求變化。

能夠自定義EC2實例，而後經過建立Amazon Machine Image（AMI）來保存其配置。能夠根據須要從AMI啓動任意數量的實例，而且它們都將包括這些自定義項。每次要更改配置時，都必須建立一個新的黃金鏡像，所以必須具備版本控制約定來管理你的黃金鏡像。建議你使用腳本爲你用於建立的EC2實例建立引導程序的AMI。這爲你提供了一種靈活的方法來測試和修改這些鏡像。

或者，若是你具備現有的本地虛擬化環境，則可使用AWS的VM導入/導出將各類虛擬化格式轉換爲AMI。你還能夠查找和使用AWS或AWS中的第三方提供的預封裝共享AMI。

雖然啓動新EC2實例時最常使用黃金鏡像，但它們也能夠應用於Amazon RDS數據庫實例或Amazon EBS卷等資源。例如，當啓動新的測試環境時，你可能但願經過從特定的Amazon RDS快照實例化數據庫來預填充其數據庫，而不是從冗長的SQL腳本中導入數據。

3）容器

開發人員喜歡的另外一個選擇是Docker，一種開源技術，容許你在軟件容器內構建和部署分佈式應用程序。Docker容許你將一個軟件封裝在Docker鏡像中，這是一個軟件開發的標準化單元，包含軟件運行所需的全部內容：代碼，運行時，系統工具，系統庫等。AWS Elastic Beanstalk，Amazon ElasticContainer 服務（Amazon ECS）和AWSFargate容許你跨EC2實例集羣部署和管理多個容器。你能夠構建黃金Docker鏡像並使用ECS容器註冊表來管理它們。

另外一種容器環境是Kubernetes和Kubernetes的亞馬遜彈性容器服務（Amazon EKS）。藉助Kubernetes和Amazon EKS，你能夠輕鬆部署，管理和擴展容器化應用程序。

4）混合

你還可使用這兩種方法的組合：配置的某些部分在黃金鏡像中捕獲，而其餘部分則經過引導操做動態配置。

不常常更改或引入外部依賴項的項目一般是你的黃金鏡像的一部分。一個好的候選者的例子是你的Web服務器軟件，不然每次啓動實例時都必須由第三方存儲庫下載。

能夠經過引導操做動態設置在不一樣環境之間常常更改或不一樣的項目。例如，若是要常常部署應用程序的新版本，則爲每一個應用程序版本建立新的AMI可能不切實際。你也不但願將數據庫主機名配置硬編碼到AMI，由於測試和生產環境之間會有所不一樣。用戶數據或標籤容許你使用可在啓動時修改的更通用的AMI。例如，若是你爲各類小型企業運行Web服務器，則它們均可以使用相同的AMI，並從啓動時在用戶數據中指定的S3存儲桶位置檢索其內容。

AWS Elastic Beanstalk遵循混合模型。它提供預配置的運行時環境，每一個環境都是從其本身的AMI11啓動的，但容許你經過ebextensions配置文件運行引導操做，並配置環境變量以參數化環境差別。

4.2.2 基礎架構即代碼

咱們討論的原則的應用沒必要限於單個的資源水平。因爲AWS資源是可編程的，所以你能夠應用軟件開發中的技術，實踐和工具，使你的整個基礎架構可重用，可維護，可擴展和可測試。

AWS CloudFormation模板爲你提供了一種簡單的方法來建立和管理相關AWS資源的集合，並以有序和可預測的方式提供和更新它們。你能夠描述運行應用程序所需的AWS資源，以及任何關聯的依賴項或運行時參數。你的CloudFormation模板能夠與你的版本控制存儲庫中的應用程序一塊兒使用，這樣你就能夠重用架構並可靠地克隆生產環境以進行測試。

4.3 自動化

在傳統的IT基礎架構中，你一般必須手動對各類事件作出反應。在AWS上部署時，你能夠進行自動化。

爲了提升系統的穩定性和組織的效率，考慮將一種或多種這類自動化引入你的應用程序體系結構，以確保更高的彈性，可伸縮性和性能。

4.3.1 無服務器管理和部署

採用無服務器模式時，操做重點是部署自動化流水線。AWS管理基礎服務，規模和可用性。AWS CodePipeline，AWS CodeBuild和AWS CodeDeploy支持這些流程部署的自動化。

4.3.2 基礎架構管理和部署

AWS Elastic Beanstalk：你可使用此服務在熟悉的服務器（如Apache，Nginx，Passenger和服務器）上部署和擴展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker開發的Web應用程序和服務。IIS開發人員能夠簡單地上傳他們的應用程序代碼，該服務自動處理全部細節，例如資源配置，負載平衡，自動擴展和監視。

Amazon EC2自動恢復：你能夠建立監控EC2實例的Amazon CloudWatch警報，並在其受損時自動恢復。恢復的實例與原始實例相同，包括實例ID，私有IP地址，彈性IP地址，和全部實例元數據。可是，此功能僅適用於適用的實例配置。有關這些前提條件的最新說明，請參閱Amazon EC2文檔。此外，在實例恢復期間，實例將經過實例從新引導進行遷移，而且內存中的全部數據都將丟失。

AWS Systems Manager：你能夠自動收集軟件清單，應用操做系統補丁，建立系統鏡像以配置Windows和Linux操做系統，以及執行任意命令。提供這些服務簡化了操做模型並確保了最佳的環境配置。

Auto Scaling：你能夠根據你定義的條件自動維護應用程序可用性，並自動擴展Amazon EC2，Amazon DynamoDB，Amazon ECS，適用於Kubernetes的Amazon Elastic Container Service，（Amazon EKS）容量。你可使用Auto Scaling幫助確保跨多個可用區運行所需數量的健康EC2實例。Auto Scaling還能夠在需求峯值期間自動增長EC2實例的數量，在不太繁忙的時期保持性能並下降容量以優化成本。

4.3.3 警報和事件

Amazon CloudWatch警報：你能夠建立CloudWatch警報，當特定指標超過指定閾值達指定數量的時段時，該警報會發送AmazonSimple Notification Service（Amazon SNS）消息。這些Amazon SNS消息能夠自動啓動執行訂閱的Lambda函數，將通知消息排入Amazon SQS隊列，或者對HTTP或HTTPS端點執行POST請求。

Amazon CloudWatchEvents：提供近乎實時的系統事件流，描述AWS資源中的變動.使用簡單規則，你能夠將每種類型的事件路由到一個或多個目標，例如Lambda函數，Kinesis流和SNS主題。

AWS Lambda預約事件：你能夠建立Lambda函數並配置AWS Lambda以按期執行它。

AWS WAF安全自動化：AWS WAF是一種Web應用程序防火牆，使你可以建立自定義的特定於應用程序的規則，以阻止可能影響應用程序可用性，危及安全性或消耗過多資源的常見攻擊模式。你能夠經過API徹底管理AWS WAF，從而簡化安全自動化，實現快速規則傳播和快速事件響應。

4.4 鬆耦合

隨着應用程序複雜性的增長，IT系統的理想屬性是能夠將其分解爲更小，鬆耦合的組件。這意味着IT系統的設計應該可以減小相互依賴性，一個組件中的更改或故障不該該級聯到其餘組件。

4.4.1 定義明確的接口

減小系統中相互依賴性的一種方法是容許各類組件僅經過特定的，與技術無關的接口（例如RESTful API）相互交互。經過這種方式，隱藏了技術實現細節，以便團隊能夠修改底層實現而不影響其餘組件。只要這些接口保持向後兼容性，差別組件的部署就會分離。這種粒度設計模式一般被稱爲微服務架構。

Amazon API Gateway是一種徹底託管的服務，使開發人員能夠輕鬆地以任何規模建立，發佈，維護，監控和保護API。它處理接受和處理多達數十萬個併發API調用所涉及的全部任務，包括流量管理，受權和訪問控制，監控和API版本管理。

4.4.2 服務發現

部署爲一組較小服務的應用程序取決於這些服務相互交互的能力。由於每一個服務均可以跨多個計算資源運行，因此須要有一種方法來解決每一個服務。例如，在傳統基礎結構中，若是你的前端Web服務須要與後端Web服務鏈接，則能夠對運行此服務的計算資源的IP地址進行硬編碼。雖然這種方法仍然適用於雲計算，但若是這些服務是鬆耦合的，那麼它們應該可以在不事先了解其網絡拓撲細節的狀況下使用。除了隱藏複雜性以外，這還容許基礎架構細節隨時更改。若是你想利用雲計算的彈性，能夠在任什麼時候間點啓動或終止新資源，那麼鬆耦合是一個相當重要的因素。爲了實現這一目標，你須要一些實現服務發現的方法。

實施服務發現

對於Amazon EC2託管的服務，實現服務發現的一種簡單方法是經過Elastic LoadBalancing（ELB）。因爲每一個負載均衡器都有本身的主機名，所以你能夠經過穩定的endpoint使用服務。這能夠與DNS和私有Amazon Route 53區域結合使用，以即可以隨時抽象和修改特定負載均衡器的endpoint。

另外一種選擇是使用服務註冊和發現方法來容許檢索任何服務的endpoint IP地址和端口號。因爲服務發現成爲組件之間的粘合劑，所以高度可用且可靠性很是重要。若是未使用負載平衡器，則還應該進行服務發現容許健康檢查等選項。Amazon Route 53支持自動命名，以便更輕鬆地爲微服務配置實例。自動命名容許你根據定義的配置自動建立DNS記錄。其餘示例實現包括使用標籤組合的自定義解決方案，高可用性數據庫，調用AWSAPI的自定義腳本，或Netflix Eureka，AirbnbSynapse或HashiCorp Consul等開源工具。

4.4.3 異步集成

異步集成是服務之間鬆耦合的另外一種形式。此模型適用於任何不須要當即響應的交互，以及已經註冊請求的確認就足夠了。它涉及一個生成事件的組件和另外一個消耗它們的組件。這兩個組件不經過直接的點對點交互進行集成，而是經過中間持久存儲層進行集成，例如SQS隊列或流式數據平臺（如Amazon Kinesis），級聯Lambda事件，AWS步驟功能或AmazonSimple Workflow服務。

 

圖1：緊耦合和鬆耦合

這種方法將兩個組件分離，並引入了額外的彈性。所以，例如，若是正在從隊列中讀取消息的進程失敗，則仍能夠將消息添加到隊列中並在系統恢復時進行處理。它還容許你保護不太可擴展的後端服務免受前端尖峯的攻擊，並找到正確的成本和處理滯後之間的權衡。例如，你能夠決定不須要擴展數據庫以適應偶爾的寫入查詢峯值，只要你最終以一些延遲異步處理這些查詢。最後，經過從交互式請求路徑中刪除慢速操做，你還能夠改善最終用戶體驗。

異步集成的示例包括：

• 前端應用程序將做業插入隊列系統（如Amazon SQS）。後端系統檢索這些做業並按照本身的進度處理它們。
• API生成事件並將其推送到Kinesis流中。後端應用程序批量處理這些事件以建立存儲在數據庫中的聚合時間序列數據。
• 多個異構系統使用AWS步驟函數來傳達它們之間的工做流，而無需直接相互交互。
• Lambda函數可使用來自各類AWS源的事件，例如Amazon DynamoDB更新流和Amazon S3事件通知。你沒必要擔憂實現排隊或其餘異步集成方法，由於Lambda會爲你處理此問題。

4.4.4 分佈式系統最佳實踐

增長鬆耦合的另外一種方法是構建以優雅方式處理組件故障的應用程序。你能夠肯定減小對最終用戶的影響的方法，並提升你在脫機過程當中取得進展的能力，即便在某些組件發生故障時也是如此。

實踐中優雅的應對失敗

失敗的請求可使用指數退避和抖動策略重試，也能夠存儲在隊列中以供之後處理。對於前端接口，能夠提供替代或緩存的內容，而不是徹底失敗，例如，你的數據庫服務器變得不可用。Amazon Route 53 DNS故障轉移功能還使你可以監控你的網站，並在主站點不可用時自動將訪問者路由到備份站點。你能夠將備份站點做爲Amazon S3上的靜態網站託管，也能夠做爲單獨的動態環境託管。

4.4.5 服務，而不是服務器

開發，管理和運維應用程序，尤爲是大規模應用程序，須要各類各樣的底層技術組件。對於傳統的IT基礎架構，公司必須構建和運行全部這些組件。

AWS提供普遍的計算，存儲，數據庫，分析，應用程序和部署服務，可幫助組織更快地移動並下降IT成本。

不利用這種廣度的架構（例如，若是它們僅使用AmazonEC2）可能沒法充分利用雲計算，而且可能錯失了提升開發人員生產力和運營效率的機會。

4.4.5.1 管理服務

AWS託管服務提供開發人員可使用的構建塊來爲其應用程序供電。這些託管服務包括數據庫，機器學習，分析，排隊，搜索，電子郵件，通知等。例如，使用Amazon SQS，你能夠減輕運維和擴展高可用性消息傳遞羣集的管理負擔，同時僅爲你使用的內容支付低價。Amazon SQS自己也具備可擴展性和可靠性。這一樣適用於Amazon S3，它使你能夠根據須要存儲儘量多的數據，並在須要時訪問它，而無需考慮容量，硬盤配置，複製和其餘相關問題。

爲你的應用程序提供支持的託管服務的其餘示例包括：

• 用於內容交付的AmazonCloudFront
• 用於負載平衡的ELB
• 用於NoSQL數據庫的Amazon DynamoDB
• 用於搜索工做負載的AmazonCloudSearch
• 用於視頻編碼的Amazon ElasticTranscoder
• 用於發送和接收電子郵件的AmazonSimple Email Service（Amazon SES）

4.4.5.2 無服務器計算架構

無服務器計算架構能夠下降運行應用程序的操做複雜性。無需管理任何服務器基礎架構，就能夠爲移動，Web，分析，CDN業務邏輯和物聯網構建事件驅動和同步服務。這些體系結構能夠下降成本，由於你無需管理或支付未充分利用的服務器，也無需配置冗餘基礎架構來實現高可用性。

例如，你能夠將代碼上載到AWS Lambda計算服務，而且該服務可使用AWS基礎結構表明你運行代碼。使用AWS Lambda，你須要爲代碼執行的每100毫秒以及觸發代碼的次數付費。經過使用Amazon API Gateway，你能夠開發由AWS Lambda支持的幾乎無限可擴展的同步API。與Amazon S3結合使用以提供靜態內容資產時，此模式能夠提供完整的Web應用程序。

在移動和Web應用程序方面，你可使用Amazon Cognito，這樣你就無需管理後端解決方案來處理用戶身份驗證，網絡狀態，存儲和同步。Amazon Cognito爲你的用戶生成惟一標識符。

能夠在訪問策略中引用這些標識符，以基於每一個用戶啓用或限制對其餘AWS資源的訪問。Amazon Cognito爲你的用戶提供臨時AWS憑證，容許設備上運行的移動應用程序直接與受AWS身份和訪問管理（IAM）保護的AWS服務進行交互。例如，使用IAM，你能夠將對S3存儲桶中的文件夾的訪問權限限制爲特定的最終用戶。

對於物聯網應用，組織傳統上必須配置，操做，擴展和維護本身的服務器做爲設備網關，以處理鏈接設備與其服務之間的通訊。AWS IoT提供徹底受管理的設備網關，可根據你的使用狀況自動擴展，無需任何操做開銷。

無服務器計算架構還使得在邊緣計算運行響應式服務成爲可能。

 

4.5 數據庫

對於傳統的IT基礎架構，組織一般僅限於可使用的數據庫和存儲技術。可能存在基於許可成本和支持各類數據庫引擎的能力的約束。在AWS上，這些約束由託管數據庫服務解除，這些服務以開源成本提供企業性能。所以，應用程序在多語言數據層之上運行併爲每一個工做負載選擇正確的技術並不罕見。

4.5.1 爲每項業務負載選擇正確的數據庫技術

下面的問題能夠幫助你決定在架構中包含哪些解決方案：

• 這是一個讀多，寫多或讀寫平衡的業務負載嗎？你須要每秒多少次讀寫操做？若是用戶數量增長，這些值將如何變化？
• 你須要存儲多少數據以及存儲多長時間？會增加多快？在不久的未來是否有上限？每一個對象的大小（平均值，最小值，最大值）是多少？如何訪問這些對象？
• 數據持久性方面的要求是什麼？這個數據存儲是否「真實來源？」
• 你的延遲要求是什麼？你須要支持多少併發用戶？
• 你的數據模型是什麼以及如何查詢數據？你的查詢本質上是關係型的（例如，多個表之間的JOIN）？你能夠對模型進行非規範化，以建立更容易擴展的更平坦的數據結構嗎？
• 你須要什麼樣的功能？你是否須要強大的完整性控制，或者你是否在尋求更大的靈活性（例如，無架構數據存儲）？你須要複雜的報告或搜索功能嗎？你的開發人員是否比NoSQL更熟悉關係數據庫？
• 相關的數據庫技術許可成本是多少？這些成本是否會考慮應用程序開發投資，存儲和使用成本？許可模式是否支持預計的增加？你是否可使用Amazon Aurora等雲原生數據庫引擎來得到開源數據庫的簡單性和成本效益？

4.5.2 關係數據庫

關係數據庫（也稱爲RDBS或SQL數據庫）將數據規範化爲稱爲表的明確表格結構，表格由行和列組成。它們提供強大的查詢語言，靈活的索引功能，強大的完整性控制，以及快速有效地組合來自多個表的數據的能力。Amazon RDS能夠輕鬆地在雲中設置，操做和擴展關係數據庫，並支持許多熟悉的數據庫引擎。

4.5.2.1 可擴展性

關係數據庫能夠經過升級到更大的Amazon RDS數據庫實例或添加更多更快的存儲來垂直擴展。此外，請考慮使用Amazon Aurora，它是一種數據庫引擎，與在同一硬件上運行的標準MySQL相比，可提供更高的吞吐量。對於讀取繁重的應用程序，你還能夠經過建立一個或多個只讀副原本橫向擴展超出單個數據庫實例的容量限制。

只讀副本是異步複製的單獨數據庫實例。所以，它們會受到複製滯後的影響，可能會丟失一些最新的事務。應用程序設計人員須要考慮哪些查詢對稍微陳舊的數據具備容忍度。這些查詢能夠在只讀副本上執行，而其他查詢應該在主節點上運行。只讀副本也不能接受任何寫入查詢。

須要將其寫入容量擴展到單個數據庫實例的約束以外的關係數據庫工做負載須要使用稱爲數據分區或分片的不一樣方法。使用此模型，數據分別跨多個數據庫模式在本身的主要數據庫實例中運行。儘管Amazon RDS消除了運行這些實例的操做開銷，但分片會爲應用程序帶來一些複雜性。須要修改應用程序的數據訪問層，以瞭解數據的分割方式，以便將查詢定向到正確的實例。此外，必須跨多個數據庫模式執行模式更改，所以值得投入一些精力來自動執行此過程。

4.5.2.2 高可用性

對於任何生產關係數據庫，咱們建議使用Amazon RDS MultiAZ部署功能，該功能在不一樣的可用區中建立同步複製的備用實例。若是主節點發生故障，Amazon RDS會自動故障轉移到備用節點，而無需手動管理干預。執行故障轉移時，會有一段短期內沒法訪問主節點。經過使用只讀副本提供減小的功能（例如只讀模式），能夠爲彈性應用程序設計彈性應用程序。Amazon Aurora提供多主機功能，能夠在可用區域之間擴展讀取和寫入，還支持跨區域複製。

4.5.2.3 非標準模型

若是你的應用程序主要索引和查詢數據而不須要鏈接或復瑣事務，特別是若是你但願寫入吞吐量超出單個實例的約束，請考慮使用NoSQL數據庫。若是你有大型二進制文件（音頻，視頻和圖像），則在Amazon S3中存儲實際文件並僅保存數據庫中文件的元數據會更有效。

4.5.3 NoSQL數據庫

NoSQL數據庫交換關係數據庫的一些查詢和事務功能，以得到更靈活的數據模型，能夠無縫地水平擴展。NoSQL數據庫使用各類數據模型，包括圖形，鍵值對和JSON文檔，而且因易於開發，可擴展性能，高可用性和彈性而廣受承認。Amazon DynamoDB是一種快速靈活的NoSQL數據庫服務，適用於任何規模都須要一致，一位數，毫秒級延遲的應用程序.它是一個徹底託管的雲數據庫，支持文檔和鍵值存儲模型。

4.5.3.1 可擴展性

NoSQL數據庫引擎一般會執行數據分區和複製，以便以水平方式擴展讀取和寫入。它們透明地執行此操做，而且不須要在應用程序的數據訪問層中實現的數據分區邏輯。特別是Amazon DynamoDB自動管理表分區，隨着表的大小增長或者讀取配置和寫入配置容量更改而添加新分區。Amazon DynamoDB Accelerator（DAX）是DynamoDB的託管，高可用內存緩存，可充分利用性能提高。

4.5.3.2 高可用性

Amazon DynamoDB在AWS區域中的三個設施之間同步複製數據，在服務器發生故障或可用區域中斷時提供容錯功能。Amazon DynamoDB還支持全局表，以提供徹底託管的多區域，多主數據庫，爲大規模擴展的全局應用程序提供快速，本地，讀取和寫入性能。全局表在所選AWS區域中複製。

4.5.3.3 非標準模型

若是你的模型沒法規範化，而且你的應用程序須要鏈接或復瑣事務，請考慮使用關係數據庫。若是你有大型二進制文件（音頻，視頻和圖像），請考慮將文件存儲在Amazon S3中，並將文件的元數據存儲在數據庫中。

4.5.4 數據倉庫

數據倉庫是一種特殊類型的關係數據庫，它針對大量數據的分析和報告進行了優化。它可用於組合來自不一樣來源的交易數據（例如Web應用程序中的用戶行爲，來自財務和計費系統的數據，或客戶關係管理或CRM），以使其可用於分析和決策。

傳統上，設置，運行和擴展數據倉庫既複雜又昂貴。在AWS上，你能夠利用Amazon Redshift，這是一種託管數據倉庫服務，其運行成本僅爲傳統解決方案的十分之一。

4.5.4.1 可擴展性

Amazon Redshift經過大規模並行處理（MPP），列式數據存儲和目標數據壓縮編碼方案的組合實現了高效存儲和最佳查詢性能。它特別適用於針對超大型數據集的分析和報告工做負載。Amazon Redshift MPP體系結構使你能夠經過增長數據倉庫集羣中的節點數來提升性能。Amazon Redshift Spectrum支持Amazon RedshiftSQL查詢，以防止Amazon S3中的數據數據，從而將AmazonRedshift的分析功能從存儲在數據倉庫中本地磁盤上的數據擴展到非結構化數據，而無需加載或轉換數據。

4.5.4.2 高可用性

Amazon Redshift具備多種功能，可加強數據倉庫集羣的可靠性。咱們建議你在多節點羣集中部署生產工做負載，以便將寫入節點的數據自動複製到羣集中的其餘節點。數據也會持續備份到Amazon S3。Amazon Redshift持續監視羣集的運行情況，並自動從新啓動故障驅動器中的數據，並根據須要替換節點。

4.5.4.3 非標準模型

因爲Amazon Redshift是基於SQL的關係數據庫管理系統（RDBMS），所以它與其餘RDBMS應用程序和商業智能工具兼容。雖然Amazon Redshift提供典型RDBMS的功能，包括在線事務處理（OLTP）功能，但它並不是針對這些工做負載而設計。若是你指望高併發工做負載一般涉及一次讀取和寫入少許記錄的全部列，則應考慮使用Amazon RDS或Amazon DynamoDB。

4.5.5 搜索

搜索常常與查詢混淆。查詢是正式的數據庫查詢，以正式術語表示特定數據集。搜索能夠查詢未精確構建的數據集。所以，須要複雜搜索功能的應用程序一般會超出關係數據庫或NoSQL數據庫的功能。搜索服務可用於索引和搜索結構化和自由文本格式，而且能夠支持其餘數據庫中不可用的功能，例如可自定義的結果排名，過濾的分面，同義詞和詞幹。

在AWS上，你能夠選擇Amazon CloudSearch和Amazon ElasticsearchService（Amazon ES）。AmazonCloudSearch是一項託管服務，幾乎不須要配置，而且會自動擴展。Amazon ES提供開源API，使你能夠更好地控制配置詳細信息。亞馬遜ES也已經發展成爲一個不只僅是一個搜索解決方案。它一般用做日誌分析，實時應用程序監控和點擊流分析等用例的分析引擎。

4.5.5.1 可擴展性

Amazon CloudSearch和Amazon ES都使用數據分區和複製來橫向擴展。不一樣之處在於，使用Amazon CloudSearch，你無需擔憂須要多少分區和副本，由於該服務會自動處理該分區和副本。

4.5.5.2 高可用性

Amazon CloudSearch和Amazon ES都包含跨可用區冗餘存儲數據的功能。

4.5.6 圖數據庫

圖形數據庫使用圖形結構進行查詢。圖形被定義爲由邊（關係）組成，其直接與商店中的節點（數據實體）相關。這些關係使商店中的數據能夠直接連接在一塊兒，從而能夠快速檢索關係系統中複雜的層次結構。出於這個緣由，圖形數據庫是專門用於存儲和導航關係的，一般用於社交網絡，推薦引擎和欺詐檢測等用例中，你須要可以在數據之間建立關係並快速查詢這些關係。

Amazon Neptune是一個徹底託管的圖形數據庫服務。

4.5.6.1 可擴展性

Amazon Neptune是專爲處理圖形查詢而優化的專用高性能圖形數據庫。

4.5.6.2 高可用性

Amazon Neptune具備高可用性，具備只讀副本，時間點恢復，連續備份到Amazon S3以及跨可用區複製。海王星是安全的，支持靜止和傳輸中的加密。

4.5.7 管理不斷增長的數據量

傳統的數據存儲和分析工具沒法再提供提供相關業務洞察所需的靈活性和靈活性。這就是爲何許多組織正在轉向數據湖架構。數據湖是一種架構方法，容許你將大量數據存儲在中央位置，以便你能夠隨時對組織內的不一樣組進行分類，處理，分析和使用。因爲數據能夠按原樣存儲，所以你無需將其轉換爲預約義的架構，而且你再也不須要事先了解有關數據的問題。這使你能夠選擇正確的技術來知足你的特定分析要求。

4.5.8 消除單點故障

生產系統一般具備定義或隱含的正常運行時間目標。當系統可以承受單個組件或多個組件（例如硬盤，服務器和網絡鏈路）的故障時，該系統具備高可用性。爲了幫助你建立具備高可用性的系統，你能夠考慮自動化恢復的方法，並減小架構每一層的中斷。

4.5.8.1 引入冗餘

經過引入冗餘能夠消除單點故障，這意味着你能夠爲同一任務提供多個資源。冗餘能夠在待機或主動模式下實現。

在主備冗餘中，當資源發生故障時，將使用故障轉移過程在備用資源上恢復功能。故障轉移一般須要一些時間才能完成，在此期間資源仍然不可用。備用資源既能夠在須要時自動啓動（以下降成本），也能夠已經空閒運行（以加速故障轉移並最大限度地減小中斷）。主備冗餘一般用於有狀態組件，例如關係數據庫。

在主主冗餘中，請求被分發到多個冗餘計算資源。當其中一個失敗時，其他的能夠簡單地吸取更大份額的工做量。與備用冗餘相比，主動冗餘能夠實現更好的使用，並在出現故障時影響較小的人口。

4.5.8.2 檢測失敗

你應該在檢測和響應故障時儘量多地構建自動化。你可使用ELB和Amazon Route 53等服務經過將流量路由到健康端點來配置運行情況檢查和屏蔽故障。此外，你可使用Auto Scaling或使用Amazon EC2自動恢復功能或AWS Elastic Beanstalk等服務自動替換不健康的節點。沒法在第一天預測每種可能的故障狀況。確保收集足夠的日誌和指標以瞭解正常的系統行爲。瞭解以後，你將可以設置警報以進行手動干預或自動響應。

設計良好的健康檢查

爲應用程序配置正確的運行情況檢查有助於肯定你是否可以正確，及時地響應各類故障狀況。指定錯誤的運行情況檢查實際上可能會下降應用程序的可用性。

在典型的三層應用程序中，你能夠在ELB上配置運行情況檢查。設計你的運行情況檢查，目的是可靠地評估後端節點的運行情況。簡單的TCP運行情況檢查不會檢測實例自己是否正常但Web服務器進程是否已崩潰。相反，你應該評估Web服務器是否能夠針對某個簡單請求返回HTTP 200響應。

在此層，配置深層運行情況檢查可能不是一個好主意，這是一種依賴於應用程序的其餘層成功的測試，由於可能會致使誤報。例如，若是你的運行情況檢查還評估實例是否能夠鏈接到後端數據庫，則當該數據庫節點很快不可用時，你可能會將全部Web服務器標記爲不健康。分層方法一般是最好的。深度健康檢查可能適合在亞馬遜Route53級實施。經過運行更全面的檢查來肯定該環境是否可以實際提供所需的功能，你能夠將Amazon Route 53配置爲故障轉移到網站的靜態版本，直到數據庫啓動並再次運行。

4.5.8.3 可靠的數據存儲

你的應用程序和用戶將建立和維護各類數據。你的體系結構保護數據可用性和完整性相當重要。數據複製是引入冗餘數據副本的技術。它能夠幫助水平擴展讀取容量，但它也提升了數據的耐用性和可用性。複製能夠在幾種不一樣的模式下進行。

同步複製僅在主要位置及其副本中持久存儲以後才確認事務。它是保護主節點發生故障時數據完整性的理想選擇。同步複製還能夠擴展須要最新數據（強一致性）的查詢的讀取容量。同步複製的缺點是主節點耦合到副本。在全部副本執行寫入以前，沒法確認事務。這可能會影響性能和可用性，尤爲是在運行不可靠或高延遲網絡鏈接的拓撲中。出於一樣的緣由，不建議維護許多同步副本。

不管你的解決方案的耐用性如何，這都不能替代備份。同步複製冗餘地存儲你的數據的全部更新，甚至是那些由軟件錯誤或人爲錯誤致使的更新。可是，特別是對於存儲在Amazon S3上的對象，你可使用版本控制來保留，檢索和還原其任何版本，經過版本控制，你能夠從非預期的用戶操做和應用程序故障中恢復。

異步複製以引入複製延遲爲代價將主節點與其副本解耦。這意味着主節點上的更改不會當即反映在其副本上。異步副本用於水平擴展系統對能夠容忍複製延遲的查詢的讀取容量。當故障轉移期間能夠容忍某些最近事務丟失時，它還可用於提升數據持久性。例如，你能夠在單獨的AWS區域中維護數據庫的異步副本做爲災難恢復解決方案。

基於Quorum的複製結合了同步和異步複製，以克服大規模分佈式數據庫系統的挑戰。

能夠經過定義必須參與成功寫入操做的最小數量的節點來管理到多個節點的複製。詳細討論分佈式數據存儲超出了本文檔的範圍。有關分佈式數據存儲的更多信息以及超可擴展且高度可靠的數據庫系統的核心原則。

瞭解你使用的每種技術在這些數據存儲模型中的位置很是重要。在各類故障轉移或備份/還原方案期間，它們的行爲應與恢復點目標（RPO）和恢復時間目標（RTO）保持一致。你必須肯定你但願丟失的數據量以及恢復操做所需的速度。例如，AmazonElastiCache的Redis引擎支持使用自動故障轉移進行復制，但Redis引擎的複製是異步的。在故障轉移期間，極可能會丟失一些最近的事務。可是，具備多可用區功能的Amazon RDS旨在提供同步複製，以使備用節點上的數據與主節點保持同步。

4.5.8.4 自動化的多數據中心恢復能力

業務關鍵型應用程序還須要針對不只影響單個磁盤，服務器或機架的中斷方案進行保護。在傳統基礎架構中，你一般須要一個災難恢復計劃，以便在主要數據中心發生重大中斷時容許故障轉移到遠程第二個數據中心。因爲兩個數據中心之間的距離很遠，所以延遲使得維護數據的同步跨數據中心副本變得不切實際。所以，故障轉移確定會致使數據丟失或數據恢復過程很是昂貴。這使故障轉移成爲一種風險而且不老是通過充分測試的程序。儘管如此，這種模型能夠提供出色的保護，防止低機率但具備巨大的影響風險，例如長期影響整個基礎設施的天然災害。

更可能的狀況是數據中心中斷時間更短。對於預計故障持續時間不長的短暫中斷，執行故障轉移的選擇是困難的而且一般被避免。在AWS上，能夠採用更簡單，更有效的保護來防止此類故障。每一個AWS區域包含多個不一樣的位置或可用區。每一個可用區都設計爲獨立於其餘可用區中的故障。可用區是數據中心，在某些狀況下，可用區由多個數據中心組成。區域內的可用區域提供廉價，低延遲的網絡鏈接到同一地區的其餘區域。這容許你以同步方式跨數據中心複製數據，以便故障轉移能夠自動化並對用戶透明。

也能夠實現主動冗餘。例如，一組應用程序服務器能夠分佈在多個可用區中，並附加到ELB。當特定可用區的EC2實例未經過運行情況檢查時，ELB將中止向這些節點發送流量。此外，AWS Auto Scaling可確保正確數量的EC2實例可用於運行你的應用程序，根據需求啓動和終止實例，並由你的擴展策略定義。若是你的應用程序因爲可用區故障而不須要短時間性能降低，那麼你的體系結構應該是靜態穩定的，這意味着它不須要更改工做負載的行爲以容忍故障。在這種狀況下，你的體系結構應該提供多餘的容量來承受一個可用區的丟失。

AWS上的許多高級服務都是根據多可用區（多可用區）原則設計的。例如，AmazonRDS使用多可用區部署爲數據庫實例提供高可用性和自動故障轉移支持，而對於Amazon S3和Amazon DynamoDB，你的數據跨多個設施進行冗餘存儲。

4.5.8.5 故障隔離與傳統水平擴展

雖然主主冗餘模式很是適合平衡流量和處理實例或可用區中斷，但若是對請求自己有任何不利影響是不夠的。例如，可能存在每一個實例都受到影響的狀況。若是某個特定請求碰巧觸發致使系統故障轉移的錯誤，則調用者可能會經過反覆嘗試針對全部實例的相同請求來觸發級聯故障。

隨機分片

你能夠對傳統的水平縮放進行隔離改進，這稱爲分片。與傳統上與數據存儲系統一塊兒使用的技術相似，你能夠將實例分組爲分片，而不是在每一個節點上傳播來自全部客戶的流量。例如，若是你的服務有八個實例，則能夠建立四個分片，每一個分片包含兩個實例（每一個分片中有兩個實例用於冗餘），並將每一個客戶分配到特定分片。

就這樣，你可以與你擁有的分片數量成正比地減小對客戶的影響。可是，一些客戶仍然會受到影響，所以關鍵是要使客戶端容錯。若是客戶端能夠嘗試一組分片資源中的每一個端點，直到成功，那麼你將得到顯着的改進。這種技術稱爲隨機分片。

4.6 優化成本

當你將現有架構遷移到雲中時，因爲AWS的規模經濟，你能夠減小資本支出並節省成本。經過迭代和使用更多AWS功能，你能夠有機會實現建立成本優化的雲架構。

4.6.1 正確的實例

AWS爲許多用例提供了普遍的資源類型和配置。例如，Amazon EC2，Amazon RDS，Amazon Redshift和Amazon ES等服務提供了許多實例類型。在某些狀況下，你應該選擇最適合你工做負載要求的類型。在其餘狀況下，使用較少實例類型的較少實例可能會下降總成本或提升性能。你應該對應用程序環境進行基準測試，並根據工做負載使用CPU，RAM，網絡，存儲大小和I / O的方式選擇正確的實例類型。

一樣，你能夠經過選擇適合你需求的存儲解決方案來下降成本。例如，Amazon S3提供各類存儲類，包括標準，簡化冗餘和標準 - 不常訪問。其餘服務（如Amazon EC2，Amazon RDS和Amazon ES）支持你應評估的不一樣EBS卷類型（磁性，通用SSD，預配置IOPS SSD）。

隨着時間的推移，你能夠經過持續監控和標記來繼續下降成本。就像應用程序開發同樣，成本優化是一個迭代過程。由於，你的應用程序及其使用將隨着時間的推移而發展，而且因爲AWS常常迭代並按期發佈新選項，所以持續評估你的解決方案很是重要。

AWS提供的工具可幫助你識別這些節省成本的機會並使你的資源保持正確的大小。爲了使這些工具的結果易於理解，你應該爲AWS資源定義和實施標記策略。你可使用AWS管理工具（如AWS Elastic Beanstalk和AWS OpsWorks）將標記做爲構建過程的一部分進行自動化。你還可使用AWS Config提供的託管規則來評估特定標記是否應用於你的資源。

4.6.2 充分利用彈性

使用AWS節省資金的另外一種方法是利用平臺的彈性。計劃爲儘量多的Amazon EC2工做負載實施Auto Scaling，以便你在須要時橫向擴展並縮小規模並在再也不須要該容量時自動減小支出。此外，你能夠在不使用時自動關閉非生產工做負載。最後，考慮你能夠在AWS Lambda上實施哪些計算工做負載，以便你永遠不會爲空閒或冗餘資源付費。

儘量將AWS EC2工做負載替換爲不須要你作出任何容量決策的AWS託管服務（例如ELB，Amazon CloudFront，Amazon SQS，Amazon Kinesis Firehose，AWS Lambda，Amazon SES，Amazon CloudSearch或Amazon EFS ）或使你可以在須要時輕鬆修改容量（例如Amazon DynamoDB，Amazon RDS或Amazon ES）。

4.6.3 充分利用各類採購方案

Amazon EC2 On-Demand實例訂價爲你提供最大的靈活性，無需長期承諾。另外兩個能夠幫助你減小開支的EC2實例是預留實例和競價型實例。

4.6.3.1 預留實例

與按需實例訂價相比，Amazon EC2預留實例容許你保留Amazon EC2計算容量，以換取大幅折扣的小時費率。這是具備可預測的最小容量要求的應用的理想選擇。你能夠利用AWS Trusted Advisor或Amazon EC2使用狀況報告等工具來識別你最常使用且應考慮保留的計算資源。根據你的預留實例購買，折扣將反映在每個月賬單中。按需EC2實例和預留實例在技術上沒有區別。不一樣之處在於你爲預留的實例付費的方式。

其餘服務也存在預留容量選項（例如，Amazon Redshift，Amazon RDS，Amazon DynamoDB和Amazon CloudFront）。

提示：在對生產中的應用程序進行充分基準測試以前，不該提交預留實例購買。在你以後已購買預留容量，你可使用預留實例利用率報告確保你仍在充分利用預留容量。

4.6.3.2 競價實例

對於不太穩定的工做負載，請考慮使用競價實例。Amazon EC2 Spot實例容許你使用備用Amazon EC2計算容量。因爲與按需訂價相比，競價實例一般以折扣價格提供，所以你能夠顯着下降運行應用程序的成本。

競價實例使你能夠請求未使用的EC2實例，這能夠顯着下降你的Amazon EC2成本。競價實例（每一個可用區中的每一個實例類型）的每小時價格由Amazon EC2設置，並根據競價實例的長期供應和需求逐步調整。只要容量可用且你的請求的每小時最高價格超過競價價格，你的競價型實例就會運行。

所以，競價實例很是適合能夠容忍中斷的工做負載。可是，當你須要更可預測的可用性時，也可使用競價型實例。例如，你能夠將預留，按需和競價型實例組合在一塊兒，將可預測的最小容量與對其餘計算資源的機會訪問相結合，具體取決於競價市場價格。這是提升吞吐量或應用程序性能的一種極具成本效益的方法。

4.7 緩存

緩存是一種存儲先前計算的數據以供未來使用的技術。該技術用於提升應用程序性能並提升實現的成本效率。它能夠應用於IT架構的多個層。

4.7.1 應用程序數據緩存

能夠設計應用程序，以便它們從快速，託管，內存中的緩存中存儲和檢索信息。緩存信息可能包括I / O密集型數據庫查詢的結果，或計算密集型處理的結果。當在緩存中找不到結果集時，應用程序能夠計算它，或者從數據庫或昂貴的，緩慢變化的第三方內容中檢索它，並將其存儲在緩存中以用於後續請求。可是，當在緩存中找到結果集時，應用程序能夠直接使用該結果，這能夠改善最終用戶的延遲並減小後端系統的負載。你的應用程序能夠控制每一個緩存項目保持有效的時間。在某些狀況下，對於很是受歡迎的對象，即便幾秒鐘的緩存也會致使數據庫負載的急劇降低。

Amazon ElastiCache是一種Web服務，能夠輕鬆部署，操做和擴展雲中的內存緩存。它支持兩個開源的內存緩存引擎：Memcached和Redis。

Amazon DynamoDB Accelerator（DAX）是DynamoDB的徹底託管，高可用性內存緩存，可提供從毫秒到微秒的性能改進，實現高吞吐量。DAX爲你的DynamoDB表添加了內存加速，而無需管理緩存失效，數據填充或集羣管理。

4.7.2 邊緣緩存

靜態內容（圖像，CSS文件或流媒體預錄製視頻）和動態內容（響應式HTML，實時視頻）的副本能夠緩存在Amazon CloudFront邊緣位置，這是一個在全球有多個存在點的CDN。邊緣緩存容許內容由更接近的基礎設施提供服務查看器，能夠下降延遲併爲你提供高大，持續的數據傳輸速率，從而爲大規模的最終用戶提供大型流行對象。

你的內容請求將智能地路由到Amazon S3或原始服務器。若是源在AWS上運行，請求將經過優化的網絡路徑傳輸，以得到更可靠和一致的體驗。你可使用Amazon CloudFront來交付整個網站，包括不可緩存的內容。在這種狀況下，好處是Amazon CloudFront重用Amazon CloudFront邊緣和源服務器之間的現有鏈接，這減小了每一個源請求的鏈接設置延遲。還應用其餘鏈接優化以免互聯網瓶頸並充分利用邊緣位置和觀看者之間的可用帶寬。這意味着，當你瀏覽Web應用程序時，Amazon CloudFront能夠加快你的動態內容的交付，併爲你的查看者提供一致，可靠，個性化的體驗。Amazon CloudFront還將上傳請求應用於與下載動態內容請求相同的性能優點。安全

4.8 安全

你可能已經在傳統IT基礎架構中熟悉的大多數安全工具和技術均可以在雲中使用。同時，AWS容許你以各類方式提升安全性。AWS是一個平臺，容許你在平臺自己中正式設計安全控制。它簡化了管理員和IT部門的系統使用，使你的環境更容易以連續的方式進行審計。

4.8.1 使用AWS功能進行深度防護

AWS提供了許多功能，能夠幫助你構建具備深度防護方法的體系結構。從網絡級別開始，你能夠構建VPC拓撲，經過使用子網，安全組和路由控制來隔離部分基礎結構。AWS WAF（Web應用程序防火牆）等服務能夠幫助保護你的Web應用程序免受SQL注入和應用程序代碼中的其餘漏洞的影響。對於訪問控制，你可使用IAM定義一組精細策略，並將其分配給用戶，組和AWS資源。最後，AWS Cloud提供了許多選項來保護你的數據，不管是在運輸途中仍是靜止狀態。

4.8.2 與AWS共享安全責任

AWS在共享安全責任模型下運行：AWS負責底層雲基礎架構的安全性，你負責保護你在AWS中部署的工做負載。這有助於你經過使用AWS託管服務減小你的職責範圍並專一於你的核心競爭力。例如，當你使用Amazon RDS和Amazon ElastiCache等服務時，安全補丁會自動應用於你的配置設置。這不只能夠下降團隊的運營開銷，還能夠減小你的漏洞風險。

4.8.3 減小特權訪問

當你的服務器是可編程資源時，你將得到許多安全優點。隨時隨地更改服務器的功能使你無需客戶操做系統訪問生產環境。若是實例遇到問題，你能夠自動或手動終止並替換它。可是，在替換實例以前，你應該收集並集中存儲日誌數據，這些數據能夠幫助你在開發環境中從新建立問題，並經過持續部署過程將它們部署爲修復程序。此方法可確保日誌數據有助於排除故障並提升安全事件的意識。這在服務器是臨時的彈性計算環境中尤其重要。你可使用Amazon CloudWatch Logs收集此信息。若是你沒有直接訪問權限，則能夠實施AWS Systems Manager 55等服務，以獲取統一視圖並自動對資源組執行操做。你能夠將這些請求與你的票務系統集成，以便僅在批准後跟蹤和動態處理訪問請求。

另外一個常見的安全風險是使用存儲的長期憑證或服務賬戶。在傳統環境中，服務賬戶一般會分配存儲在配置文件中的長期憑據。在AWS上，你可使用IAM角色經過使用自動分發和輪換的短時間憑據向EC2實例上運行的應用程序授予權限。對於移動應用程序，你可使用Amazon Cognito容許客戶端設備經過具備細粒度權限的臨時令牌訪問AWS資源。

做爲AWS管理控制檯用戶，你能夠相似地經過臨時令牌提供聯合訪問，而不是在你的AWS帳戶中建立IAM用戶。而後，當員工離開你的組織並從組織的身份目錄中刪除時，該員工也會自動失去對你的AWS帳戶的訪問權限。

4.8.4 安全代碼

傳統的安全框架，法規和組織策略定義了與防火牆規則，網絡訪問控制，內部/外部子網和操做系統強化等項目相關的安全要求。你也能夠在AWS環境中實現這些，但你如今有機會在定義黃金環境的模板中捕獲它們。AWS CloudFormation使用此模板，並根據你的安全策略部署資源。做爲持續集成管道的一部分，你能夠在多個項目中重用安全性最佳實踐。你能夠在發佈週期中執行安全測試，並自動發現應用程序差距並從安全策略中消失。

此外，爲了得到更好的控制和安全性，能夠將AWS CloudFormation模板做爲產品導入AWS Service Catalog.5。這使你能夠集中管理資源，以支持一致的治理，安全性和合規性要求，同時使你的用戶可以快速部署他們須要批准的IT服務。你應用IAM權限來控制能夠查看和修改產品的人員，並定義約束以限制能夠爲產品部署特定AWS資源的方式。

4.8.5 實時審計

測試和審覈你的環境是保持安全的快速移動的關鍵。涉及按期（一般是手動或基於樣本）檢查的傳統方法是不夠的，尤爲是在變化不變的敏捷環境中。在AWS上，你能夠實施控制的持續監控和自動化，以最大限度地下降安全風險。AWS Config，Amazon Inspector和AWS Trusted Advisor等服務會持續監控合規性或漏洞，從而清楚地瞭解哪些IT資源符合要求，哪些不符合要求。使用AWS Config規則，你還能夠了解資源是否在短期內不合規，從而使得時間點和時間段審覈很是有效。

你經過啓用AWS CloudTrail，能夠爲你的應用程序（使用Amazon CloudWatch Logs）和實際的AWS API調用實施普遍的日誌記錄AWS CloudTrail是一種Web服務，它記錄對AWS帳戶中受支持的AWS服務的API調用，並將日誌文件傳送到S3存儲桶。而後，日誌數據能夠以不可變的方式存儲，並自動處理以發送通知或表明你採起行動，從而保護你的組織免受不合規。你可使用AWS Lambda，Amazon EMR，Amazon ES，Amazon Athena或AWS Marketplace中的第三方工具掃描日誌數據，以檢測未使用權限，特權賬戶過分使用，密鑰使用，異常登陸，策略違規和系統等事件濫用。

5. 結論

在AWS中設計雲架構時，重要的是要考慮AWS中的重要原則和設計模型，包括如何爲應用程序選擇正確的數據庫，以及如何構建能夠水平擴展且具備高可用性的應用程序。因爲每項實現都是惟一的，所以你必須評估如何將此指南應用於你的實現。雲計算體系結構是一個普遍而不斷髮展的主題。您可使用AWS網站上提供的材料以及AWS培訓和認證產品，隨時瞭解AWS雲產品的最新更改和添加。

 

說明：

本文由新鈦雲服運維工程師傅雨斌翻譯，新鈦雲服擁有八名認證的AWS工程師，在AWS使用和維護方面擁有豐富的經驗，已經爲多家用戶提供AWS上雲支持。

 

原文連接：

https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf 

 

 

 

請點擊輸入圖片描述