近年來，對于打造高度可擴展的應用程序，軟件架構師們挖掘了若干相關理念，并以最佳實踐的方式加以實施。在今天的“信息時代”，這些理念更加適用于不斷增長的數據集，不可預知的流量模式，以及快速響應時間的需求。本文將強調并重申其中的一些傳統觀念，并討論他們如何在融合云計算的發展，還將討論由于云計算的動態性而產生的一些前所未有的概念(如彈性)。
本文的目標是面向云架構師，如何將移動企業級應用從一個固定的物理環境遷移到虛擬化云環境。本文的重點是如何構建一個新的云應用或現有應用程序遷移到云環境所涉及的概念，原則和最佳實踐。
背景介紹
作為云架構師，理解云計算的優勢非常重要。在本節中，我們將探討一些云計算的技術優勢和商業優勢以及各種各樣的AWS服務。
云計算的商業優勢
在云中構建應用程序有一些明顯的商業優勢，這里列出機構主要特點：
前期基礎設施投資幾乎為零：如果你要建立一個大型的系統，它可能需要大量投資用于于機房，物理安全，硬件(機架，服務器，路由器，備用電源)，硬件管理(電源管理，散熱)，和運維人員。由于高昂的前期成本，該項目通常甚至開始之前需要多輪的管理審批和論證?，F在，采用公有云環境，幾乎沒有固定成本或啟動成本。
基礎設施即時性：在過去，如果你的應用程序開始大規模上量，而你的系統或基礎設施沒有在規模上跟上來，將會極大影響應用的成功。相反，如果前期投入了大量資金，而應用沒有得到普及，你的系統或基礎設施又將成為失敗的犧牲品。通過在云環境自適應部署應用程序，就可以不必擔心是否要預先采購大型的系統。這增加了靈活性，降低了風險和運營成本，因為你可以根據用于成長的規模而按需支付費用。
更有效地利用資源：系統管理員通常會擔心新硬件的采購(資源耗盡的情況)和更高的基礎設施利用率(資源冗余余或閑置的情況)。在云環境中，我們可以根據該應用程序請求量更高效地管理資源以及有效地按需釋放資源。
根據使用計算成本：用工具式的定價，可以只對已使用的基礎設施付費而不必支付那些分配了但未使用的基礎設施。這增加了一個節省成本的新維度。當部署了優化補丁來更新云應用時，你可以立竿見影地看到成本節約(有時會提前出現在下個月的賬單里)。例如，如果一個緩存層可以減少70%的數據請求，你馬上就可以在下一個賬單里看到回報。此外，如果您正在云上構建一個平臺，同樣可以把這個靈活可變的基于使用的成本結構傳遞給自己的客戶。
縮短產品上市時間：并行化是加快處理速度的重要方式。如果一個計算密集型或數據密集型任務在一臺機器上并行處理需要運行500小時，通過云架構，能夠復制并運行500個實例來處理相同的任務，并在1小時內完成。具有彈性的基礎設施提供了利用并行化的成本效益來縮短產品上市時間的能力。
云計算的技術優勢：
云計算的技術優勢如下：
自動化：“腳本化的基礎設施”：可以通過充分利用可編程(API驅動的)基礎設施，可重用構建和部署系統。
自動擴展：無需任何人工干預，就可以根據需求對應用進行雙向擴展。自動縮放提高了自動化程度從而更加高效。
主動擴展：基于需求預期和流量模式的合理規劃，可以對應用進行雙向擴展讓從而保持低成本運營。
更有效的開發周期：可以很容易地克隆開發和測試環境到生產系統。不同階段的環境可以很容易地推廣到生產系統。
改進的可測性：不需要進行硬件耗盡的測試。注入和自動化測試能夠持續在開發過程的每一個階段。我們可以建立一個預配置環境——“即時測試實驗室”，僅用于一段時間的測試。
災難恢復和業務連續性：云服務為維護一系列DR服務器和數據存儲提高了低成本選擇。使用云服務，你可以在幾分鐘內完成將某一地點的環境復制到其他地域的云環境中。
流量溢出到云環境：通過幾次點擊和有效的負載均衡策略，可以創建路由將超出的訪問流量轉移到云環境中的一個完整的防溢應用程序。
AWS 云服務
AWS云服務以最小的支持和管理成本，通過高度可靠和可擴展的基礎設施，提供了Web應用部署的解決方案，其靈活性遠高于自建的基礎設施，無論這些設施是企業內部的部署環境還是在數據中心設施。
如今，AWS提供了各種基礎設施服務。下圖將為您介紹了AWS的術語，并幫助您了解應用程序可以用不同的AWS服務以及不同的服務間是如何交互。
AmazonEC2 是一個Web服務，提供容量可調整的云計算能力。你可以將操作系統，應用軟件和相關配置捆綁在一起，然后設置成亞馬遜機器映像(AMI)。然后，您可以使用這些AMI生成多個虛擬化實例，以及使用簡單的Web服務調用，快速雙向擴展容量，也可以根據容量需求的變化而去除他們。您可以購買點播實例以小時付費或按次付款并保留實例，在使用率較低時，可以申辦未使用的容量，并進一步降低成本。實例可以在一個或多個地域運行。每個地域都有多個可用區。可用區是被設計成與其他可用區的故障隔離，并提供了與同一地域其他可用區不同廉價低延遲的連接網絡。
彈性IP地址允許您通過編程的方式將一個靜態的IP地址分配給一個實例。您可以使用Amazon CloudWatch監控一個Amazon EC2實例的可見性資源利用率，運行性能和全部要求模(包括指標，如CPU利用率，磁盤讀取和寫入，以及網絡流量)。根據CloudWatch收集一定的條件指標，您可以創建Auto-scaling Group來使用自擴展特性來實現自動縮放。您也可以通過使用彈性負載均衡ELB服務創建一個彈性負載平衡器分發請求流量。彈性塊存儲(EBS)將持久性存儲通過網絡方式關聯到Amazon EC2實例中。對于EBS的一致性的卷快照，可以創建并存儲在亞馬遜簡單存儲服務Amazon S3中。
Amazon S3是高度耐用和分布式數據存儲。用一個簡單的Web服務接口，在任何時間，在網絡上的任何地方都可以使用標準的HTTP命令存儲和檢索大量在數據箱中的對象。作為Web服務的傳輸內容，對象的副本(靜態或流媒體內容)都可以通過創建并使用Amazon CloudFront的緩存服務來分布在世界各地的14個地域-。亞馬遜SimpleDB也是一個Web服務，它提供了一個數據庫的核心功能，無需復雜操作，就可以完成實時查詢和結構化數據的簡單查詢。域是由鍵值對所描述的條目集合，我們可以組織數據集到域，并對該特定域中的數據進行查詢(NoSql服務)。
Amazon RDS 提供了在云環境中建立，操作和擴展關系型數據庫的簡單方法。你可以發布一個DB Instance 就可以訪問 MySQL數據庫的全部特性，而不必擔心通用的數據庫管理任務例如 備份，補丁管理等。
Amazon SQS 是一個高可靠，高擴展的分布式消息隊列，通過消息隊列可以完成不同主機以及應用組件間的消息傳遞。
Amazon SNS 使用發布-訂閱協議并創建相關主題，提供了從云端通知應用或用戶的簡單方法。
Amazon EMR 提供了以EC2 和S3為基礎設施的 Hadoop 框架，可以創建自定義的作業流. 作業流就是 MapReduce 過程序列.
Amazon VPC allows能夠在AWS內部將企業網擴展為私有云。Amazon VPC 使用IPSec 管道模式在你的數據中心網關和AWS網關之間建立一個安全連接。
Amazon Route53 是一個高可擴展的 DNS 服務，你可以在每一個域創建一個HostedZone來管理所有的DNS記錄。
AWS IAM 在AWS賬戶內部通過唯一的安全準則可以創建多個用戶，并具有不同地權限。 IAM與AWS 云服務以原生方式集成在一起. 在使用IAM時，不需要退出應用和先關工具，就可以保持AWS的服務持續運行。
AWS 通過支付的基礎設施提供了各種各樣的支付方式和計費服務。
所有AWS 云服務都提供了按使用計費的方式，而不需要長期承諾或合同。 例如, 按小時支付 Amazon EC2 實例的使用，按照存儲量和傳輸量對Amazon S3付費. 更多信息可以關注AWS的網站。
注意，使用AWS云計算并不需要犧牲靈活性和也不改變你的使用習慣：
你可以隨意使用你選擇的編程模型，語言，或者操作系統(Windows, OpenSolaris or any flavor of Linux)
你可以隨意使用任何一個AWS服務或者任何服務的組合，只要最大限度地滿足你的需求就可以了。
由于 AWS提供了可以調整的資源 (存儲, 帶寬和技術能力),你可以自由地增減資源并安裝真正的使用付費。
可以繼續使用原來的系統管理工具，將你的數據中心擴展到云端。
云計算中的基本理念
云計算強化了構建高度可擴展互聯網架構的一些基本理念，同時引入了一些新的概念完全該變量應用的構建和部署方式。因此，當你在從概念設計到實施的過程中，你可能會感到“什么都變了，卻又沒什么不同”。云計算改變了處理方式，模式，實踐方式，甚至哲學理念，同時強化了傳統的SOA原則，這些原則比以前更加重要。在本節，你將看到云計算中的新概念以及對SOA原理的重申。
構建傳統應用時，權衡體系結構和經濟性之間的關系需要大量的開發經驗. 云計算帶來了新的理念，現探討如下:
構建可擴展架構：
為了獲得一個可擴展基礎設施的好處，構建一個可擴展的架構非常關鍵。
云計算在設計上提供了概念上的無限可擴展。但是，如果你的架構部署可擴展的，也無法使用到云計算的可擴展性帶來的優勢。
你必須確定架構中的瓶頸和單點組件，確定架構中哪些是不能按需部署的部分，然后重構應用來調整為可擴展的架構，從獲得云計算的益處。
一個真正可擴展應用的特點:
增加資源就可以按比例增加性能
一個可擴展的服務可以處理異構的兼容性
一個可擴展的服務可以有效的運營
一個可擴展的服務是彈性的
一個可擴展的服務能夠在業務增長時成本更低(單位成本隨著單元的增加而遞減)
這些特性應該是應用中的固有部分，在架構設計時要銘記于心，基礎設施和應用架構要協同工作完成可擴展性。
對彈性的理解
下圖解釋了一個云應用架構中按需擴展的不同方法。
放大擴展的途徑: 使用可擴展的應用架構不用擔心為了滿足需求而大規模投資以及購買更強大的服務器(垂直擴展)這種方法通常工作到一個點，但是在新設備部署前就可以降低成本 (見圖中的“Huge capital expenditure” )或者滿足業務增長的需要 (見圖中“You just lostyour customers”).
傳統向外擴展的途徑： 創建水平擴展的架構和投資小塊的基礎設施。大多數業務或大規模web應用都采用如下的模式，分布式應用組件，聯合數據集和SOA的設計。 這種方法通常比放大擴展更有效。然而，這需要準確的業務預期才能實現滿足需求的部署。經常會導致容量過剩(“燒錢”) 和持續人工監測 (“浪費人力成本”).此外，如果遇到業務的爆發式增長，系統將無法正常工作。
注意：這兩種方法具有初始啟動成本，而且在本質上是被動的。
傳統結構一般要預測幾年內系統所需資源的數量，如果預計不足，應用將沒有馬力處理預期外的流量，從而導致客戶的不滿。如果預計過高，又造成資源浪費。
按需部署和彈性是云計算的天然方式(自動彈性)，使基礎設施與真實需求盡量匹配，因而可以提供資源利用率及壓縮成本。
彈性是云計算的一個基礎屬性。彈性通過微量的調整即可實現計算資源的可擴展性增減。彈性給云計算帶來絕對的優勢，這非常重要。 作為云計算架構，要牢記這一概念，并應用到系統架構中，才能獲得云計算的最大利益。
傳統上，以一個固定的預部署的剛性基礎設施來構建應用，公司不需要每天都要進行安裝部署。結果使大多數軟件架構不適用快速部署和硬件縮減。既然獲取新資源需要較高的實施時間和追加投資，軟件架構也不會在硬件利用率的優化是投入時間和資源，應用在低使用率的硬件上運行時可以接受的。在分鐘級獲得新資源是不可能的，所以一個架構的彈性也是被忽略的。
在云計算中，這是觀念的改變。云計算以流水線處理的方式獲取所需資源，不再需要預先采購設備和保留閑置的硬件。云架構可以在幾分鐘內完成資源采購或者自動化采購，從而擁有了大量擴展和響應時間的優勢，同樣，也可以釋放掉那些閑置的或低利用率的資源。如果在你的系統架構中不能擁抱這樣的變化，就不能分享云計算的全部好處。
作為一個云應用架構師，你需要創造性地思考在應用系統中實現彈性。 例如,基礎設施被用來白天運行，晚上構建，在凌晨2點執行回歸和單元測試兩個小時 ，其他時間都是空閑的。現在，基礎設施有了彈性, 可以只支付晚上兩個小時的計算時間。類似的，內部故障經常出現在容量的峰值(例如5 服務器 24x7x365)，現在可以按照流量模式來按需配置(如5 服務器從9AM 到 5 PM 運行，而只用2個服務器在5 PM 到 9 AM運行)。
云架構的智能彈性設計使基礎設施能夠按需運行，這本身就是一門藝術。彈性應該是一種架構設計的需求或者系統屬性。你可能會問：系統架構中的哪些組件或者層次可以成為彈性的?用什么技術可以使這些組件變得有彈性? 實現彈性對系統架構的整體有何影響?
在下一章，將會展示在應用中實現彈性的相關技術。有效地利用云計算的彈性優勢，是架構中非常重要的觀念。
無懼約束
當你決定架構應用向云計算遷移的時候，或者將自己的系統規范映射成云服務時，要注意到云計算中沒有原來所需的準確資源定義。例如，云計算中一個服務器沒有RAM的數量，或者一個數據庫實例需要更多的IOPS。
要理解云計算提供的是抽象資源，這才使按需實施模式變得強大。當使用云資源時不用擔心不夠用，你的硬件沒有真正確切地復制在云環境中，這非常重要，你能夠獲得任何你所需要的資源。
例如，云計算沒有告訴你一個服務器中確切的內存數量，使用了向memcached的分布式緩存，或者將數據在多個服務器上做了分區。如果你的數據庫需要更多的IOPS，且不能映射到云中的服務，可以根據使用用例和數據類型選擇其他的云計算方案。如果是一個重度讀應用，你可以將這些讀請求分布到一組同步的從服務中。另一種方法是，采用分片算法來路由數據，或者采用各種數據庫集群解決方案。
回顧一下, 當你將靈活性和按需實施能力結合在一起的時候，就已經意識到資源約束的解除顯然提高了可擴展性，改善了系統的整體性能。
虛擬化管理
云計算的到來將系統管理員的角色變成了“虛擬系統管理員”。這意味著這些管理員們更關注應用本身那些有趣的事情，以及從整體上決定哪些對業務是最佳的。系統管理員不再需要部署服務器，安裝軟件以及連接網絡設備，所有這繁復的工作都可以通過幾下點擊和幾個命令行調用就完成了。基礎設施的可編程化使云計算自動化程度更高。系統管理員需要升級自己的技術結構來學習如何使用腳本管理抽象的云資源。
類似地，DBA的角色也變成了“虛擬DBA”，通過基于web的終端管理資源，執行腳本在容量用光時增加新的數據庫容量，以及每天的自動化處理。
虛擬DBA必須學習新的部署方法(通過虛擬機鏡像)，擁抱新的模型 (并行查詢，遠程災備和異步復制),反思數據的架構方法 (分片,水平分區,聯盟) 以及針對不同數據集采用不同的云存儲服務。
在傳統企業中，應用開發者沒有和網絡管理員在一起緊密的工作，網絡管理員也沒有關于應用的膠水。結果是，網絡層和應用架構層優化經常被忽略。 通過云計算，二者被凝聚在一起，在將來做應用架構的時候，公司將形成更多的跨團隊融合。
云架構最佳實踐
在本節,我們將學習到在云端構建應用的最佳實踐。
容錯性設計和零故障
大拇指原則：在云端進行架構設計時要保持悲觀，假設所有事物都會發生故障。換句話來說，要面向故障的自動化恢復來設計，實施和部署。
特別地，假設硬件會發生故障，斷電了，這些災難使應用不能工作了，某些天的每秒請求超出的限制，不得不停止服務， 軟件也發生了故障等。作為一個悲觀主義者，在設計時就要思考恢復策略，將使整個系統變得更好。
如果意識到了故障切換并且作為架構的一部分，通過可擴展的基礎設施來構建故障處理的機制，你將不再建一個容錯的架構，而是由云環境完成了。
你會問：系統中一個節點故障時發生了什么?如何識別故障?如何更換這個節點?我要規劃怎樣的場景?什么是我的單點故障?如果在一組服務器之前使用了負載均衡，那么均衡器掛了怎么辦? 如果架構中采用了主從結構，主節點掛了怎么辦?如何故障切換?一個與主服務器同步的新從設備如何被實例化?
和硬件故障設計一樣，必須進行軟件的故障設計。
你會問:如果一個依賴服務的接口變了，我的應用怎么辦?如果下行服務超時或者返回異常怎么辦?如果緩存的鍵值數量超出了一個實例的內存限制怎么辦?
建立處理故障的機制. 例如, 下面的策略可以為故障處理提供幫助:
1. 數據的連貫備份和恢復以及自動執行
2. 構建重啟的進程
3. 從隊列中重載消息來完成系統狀態的重新同步
4. 保留已經配置和優化好的虛擬鏡像來支持步驟2和3
5. 避免內存中的會話或者狀態化的上下文，把它們移到數據存儲中。
好的云架構可以減少重新加載或者重新啟動。例如使用 Amazon SQS 和Amazon SimpleDB的組合, 這個控制器的架構對這些故障非常有彈性。對實例而言，如果控制器上的實例線程假死，它可以恢復到以前的狀態就像什么都沒發生過似的。這是通過創建一個預先配置好的AMI完成的，它重啟動的時候從Amazon SQS隊列中讀取所有消息，并從SimpleDB讀取它們的所有狀態。
針對底層硬件故障的可能情況進行設計，可以做到有備無患。
這一設計原則能夠實現運營友好的應用[11]。如果你通過主動測量和動態負載均衡來擴展這一原理，由于云環境的多租戶特性，你可以實現各種各樣的網絡和硬盤性能。
AWS提供了特殊的策略來實施這一最佳實踐:
1.使用彈性IP來優雅地實現故障切換: 彈性IP是將一個靜態的IP動態地重新映射。你可以通過重新映射將故障切換到另外的一組服務器上，流量也將路由到新的服務器。這對應硬件故障或者應用升級都非常有效。
2.使用多可用區: 可用區是概念上的邏輯數據中心。在多可用區上部署你的系統架構，可以保證高可用性。使用 Amazon RDS Multi-AZ [21] 的部署功能可以在多可用區上自動復制數據庫。
3.維護一個AMI能夠在不同的可用區上輕松地克隆和恢復環境;在可用區間維護多個從數據庫從而實現熱備份。
4. 使用 Amazon CloudWatch(或各種實時的開源監測工具) 以可視化的方式對硬件故障或者性能下降采用合適的措施。建立一個自動可擴展組以便用新的實例替換那些不健康的 Amazon EC2實例。
5. 使用Amazon EBS，建立 cron jobs來實現將增量快照自動地上傳到AmazonS3，使數據與實例獨立開來。
6. 使用Amazon RDS ，設置為備份的保留期限，以便它可以執行自動備份。
組件解耦合
云計算強化了SOA的設計原理，系統組件的耦合越松，擴展起來越方便越好。
構建組件的關鍵是減少之間的依賴，如果一個組件死掉了，沒有響應，或者響應時間過長，系統中的其他組件應該可以繼續正常工作。 顯然，松耦合使組件間以及層次間相互獨立，這樣每個組件可以將其他組件作為黑盒子完成異步交互。例如
一個web應用架構的情況,將應用服務器，web服務器和數據分離開來，該應用程序服務器不知道你的Web服務器，反之亦然，這些層之間的解耦合，不存在代碼依賴或功能交叉。在批處理的系統架構中，可以創建相互獨立的異步組件。
你可能會問:哪些業務組件或特性可以從當前的單點應用中隔離出來，可以獨立運行么?那么，在不破壞當前系統的前提下能夠為這個組件增加更多的實例么，以及同時服務更多的用戶? 付出多大的努力才能封裝這些組件并使其異步通信呢?
組件解耦合，異步系統和水平擴展在云計算中是非常重要的。你不僅可以為同一組件增加多個實例實現擴展，而且允許你設計創新的混合模式，其中一些成分繼續私有部署運行，而其他組件可以利用云計算可擴展的優勢，使用云計算的計算能力和帶寬。這樣，以最小的代價，你可以通過實施智能負載均衡策略將在“溢出”多余的流量移動到云上。
建立松耦合系統的另一方式是使用消息隊列。如果兩個組件間通過隊列或者緩沖區連接的話，可以支持高并發，高可用和負載削峰。其結果是，即使元件部分功能暫時不可用，整個系統仍然繼續執行。如果一個組件死亡或暫時不可用時，系統將消息緩存起來，在組件恢復時再處理他們。
在GrepTheWeb的架構這篇文章中可以看到消息隊列的充分使用[6]。在 GrepTheWeb中,
如果忽然間有大量的請求到達服務器(互聯網引發的過載情況)或者正則表達式的處理花費了大量的時間(一個組件響應遲鈍)， Amazon SQS 將在一段時間內緩存這些請求，使這些延遲不會影響其他組件。
AWS提供了特殊的策略來實施這一最佳實踐:
1. 使用Amazon SQS來隔離組件
2. 使用Amazon SQS作為組件間的緩沖區
3. 設計的每個組件暴露其服務接口，負責其自己的可擴展性，并與其他組件異步交互
4. 綁定組件的邏輯結構并制成AMI，以便可以時常部署
5. 使應用盡可能無狀態化，將會話的狀態存儲在組件的外部(例如SimpleDB)
實現彈性
云計算為你的應用帶來了彈性的概念。有三種方法實現彈性：:
1. 周期性主動擴展: 固定時間將的周期性擴展(按天, 周, 月, 季度)
2. 基于事件的主動擴展:根據安排好的商務活動(新品發布，市場宣傳活動)所期望的請求流量爆發而做的擴展
3. 按需自動擴展 ：通過監控服務的使用，系統可以根據相關指標觸發適當的動作來擴容或減負 (例如一個實例的服務器或者網絡IO的使用情況)
為了實現彈性,首先要做到自動化部署，流水線配置和構建流程，這樣可以保證在沒有人工參與的情況下自動地實現系統的可擴展。這能導致即時節約成本，保證資源與需求高度匹配，而不需為了潛在需求運行的服務器在低利用率運行。
[page]基礎設施自動化
使用云環境最重要的優勢之一是能夠使用API完成自動化部署。在遷移的早期花時間考慮自動化部署是非常值得的。創建一個自動化和可重復的部署流程能夠減少錯誤，有效地擴展和升級。
自動化部署:
建一個庫：頻繁使用的小腳本(用于安裝和配置)
使用AMI內綁定的代理來管理配置和部署流程
實例自舉
實例自舉
讓你的實例在啟動的時候問你個問題 “我是誰，我的角色是什么?” 每個實例都應該在環境中扮演一個角色(“DB server”, “app server”, “slave server” 等) 。 這個角色可能是傳遞給啟動過程的參數，用來指示AMI實例化社的步驟。再啟動時,基于角色和所關聯集群的功能，實例可以獲取所需的資源 (代碼, 腳本, 配置)。
實例自舉的好處:
1. 少量操作即可完成環境重建(開發, 測試, 生成)
2. 實現對抽象云資源的更多控制
3. 減少人為部署的錯誤
4. 創建了一個自愈環境對硬件故障而言更有彈性
AWS 提供了基礎設施自動化的相關策略：
1. 使用Amazon EC2中的Auto-scalingfeature 為不同的集群定義Auto-scaling groups
2. 使用Amazon CloudWatch 來監控系統指標(CPU, Memory, Disk I/O, Network I/O) ，然后采取合適的操作(使用Auto-scalingservice動態啟用新的AMI)或者發通知 。
3. 動態存儲和恢復配置信息: 利用Amazon SimpleDB 在實例啟動時獲得配置數據。SimpleDB也可以用來存儲實例的信息如 IP 地址,機器名和角色.
4. 設計一個構建流程將最新版本存入AmazonS3; 從而在系統啟動的時候加載最新的版本
5. 構建資源管理工具(自動化腳本,配置好的鏡像 )或者使用開源的配置管理工具如 Chef18, Puppet19, CFEngine 20或Genome21.
6. 將裁減的操作系統和軟件依賴綁定并放入AMI中，這樣便于管理和維護。在啟動時傳遞配置文件和參數，啟動后獲得用戶和實例的相關數據.
7. 將一個實例管理一個或多個EBS卷可以減少綁定和啟動的時間。創建通用卷快照，可以在合適的時候共享這些快照。
8. 假定應用組件處于不良狀態。例如，動態綁定一個新節點的IP到集群中，自動故障切換以及故障發生時啟動一個新的克隆。
并行化思考
云計算能輕松實現并行化。無論是從云中請求數據，將數據存儲到云中，在云中處理數據(或執行的作業)，作為一個云服務架構師，在架構設計時一定要將并行化秉記于心。
由于云計算可以非常容易地創建可重復流程，所以不但要盡可能地實現并行化，而且使之自動化執行。
當數據訪問的時候,云環境可以處理大量的并行操作。為了得到最大的性能和吞吐量， 需要充分利用并行化請求。多線程并發處理要比順序化請求處理快得多。因此，盡可能地使用非共享原則來充分利用多線程來設計線程安全的云應用。
在云端處理請求的時候，并行處理就越發重要了。在web應用中，一個通常的最佳實踐是使用負載均衡將請求分布到多個異步的web服務器中。在批處理應用中，可以使用多個從服務節點來處理并行化任務。
當并行化和彈性相結合體現了云計算之美。云應用使用少量的API在幾分鐘內就可完成計算集群的部署，并行地處理任務、保存結果和終止實例。
AWS 面向并行化的相關策略:
1.對 Amazon S3 多線程化
2. 對 SimpleDB 的GET 和 BATCHPUT 請求多線程化 [3][4] [5]
3. 對每日的批處理任務(索引，日志分析等)，使用AmazonEMR 創建作業任務，能夠并行處理并節約時間。.
4. 使用彈性負載。
動靜分離：動態數據靠近計算，靜態數據貼近用戶
一般來說，讓數據盡可能靠近你的計算或處理單元，以減少延遲是一個很好的做法。在云計算中，由于必須經常處理互聯網延遲，這一實踐更加重要。此外，在云環境中，我們必須要為數據傳輸的千兆字節帶寬付費，成本開銷很大。
如果大量數據需要在云計算之外處理，先傳輸再計算可能比較便宜。例如，對于一個數據倉庫的應用而言，最好是數據集先移到云，然后執行并行數據查詢。對于一個從關系型數據庫存取數據的web應用，最好也是將數據庫和應用服務器一并移到云環境中。如果數據是在云端產生的，則消耗該數據的應用程序也應該部署在云中，以便它們可以享受在云環境內部的免費數據傳輸和低時延。例如，在一個電商的應用記錄點擊數據并生成日志的情況，最好在云中運行日志分析和報表引擎。
相反地，如果數據是靜態的，不經常改變(例如，圖像，視頻，音頻，PDF文件，JS，CSS文件)，最好是利用CDN服務的優點，內容分發服務提供更快的對象訪問，使得靜態數據被高速緩存在靠近最終用戶(請求者)的網絡位置，從而降低了訪問時延。
AWS針對這一最佳實踐的相關策略：
1. 使用 Import/Export 服務27.將數據盤遷移到云環境中，用 sneakernet28 tha比互聯網上傳更快捷而且便宜。.
2. 使用相同的可用區來發布集群
3. 創建一個Amazon S3數據發布版本， 充分利用 AmazonCloudFront 在全球14個地區的CDN服務
關于安全的最佳實踐
在多租戶環境中，云計算架構師經?？紤]的就是安全性。安全應在云應用體系結構的每
一層中都有體現實現。物理安全性通常是由服務提供商來處理(安全白皮書[7])，這是使用云的一個額外好處。網絡和應用級的安全是你的責任，應該適用業務實施最佳實踐。在本節中，您將了解如何保護云應用程序在AWS環境中的那些特定的工具，功能和準則。建議利用這些工具，實現基本安全功能，然后使用適當的標準方法，或其他認為合適的安全性最佳實踐。
保護在途數據
如果需要在服務器和瀏覽器中交互敏感或機密信息，最好在服務器實例中配置SSL，需要使用像VeriSign29 或Entrust30這樣的授權證書。 證書中的公鑰來驗證服務器和瀏覽器請求，并作為雙向會話數據加密的基礎。
通過少量的命令行調用就可以創建虛擬私有云 (using Amazon VPC)。 這樣可以在云環境內實現資源的邏輯隔離，然后使用業界標準的IPSec VPN 連接來直接訪問資源，也可以在Amazon EC2上建立一個OpenVPN服務器，然后在所有用戶PC上安裝OpenVPN的客戶端。
保護數據的存儲
如果關心云環境中存儲的敏感和機密數據，需要在在上傳文件是進行加密。例如，使用任何開源工具加密數據或者使用商用的PGP 工具在存儲到Amazon S3前進行加密，在下載后進行解密。在構建HIPAA兼容的應用程序時需要保存PHI,這通常是一個好的實現。
在 AmazonEC2上,文件加密依賴于操作系統 。運行在Windows 上的Amazon EC2 實例可以使用內置 EFS 特性 [16]. 該特性可以對文件或目錄自動加解密，對用戶而言是透明的[19]。此外，和名稱不符的是， EFS 不能加密整個文件系統而只加密單個文件。如果對這個文件系統加密，需要考慮開源的TrueCrypt33 產品; 它與NTFS格式 EBS卷集成的很好。運行在Linux上的Amazon EC2實例可以使用各種方式加密文件系統來掛載EBS卷 (EncFS34,Loop-AES35, dm-crypt36,TrueCrypt37). 類似的, 運行在OpenSolaris 上的Amazon EC2 實例可以試試 ZFS38 加密支持 [20].無論選擇的是什么，在Amazon EC2 上加密的文件和卷都可以保護文件和日志數據，從而只有用戶和服務器上進程可以看到明文，其他都只能看到密文。
不論你選擇了什么樣的技術或操作系統，加密數據都意味著一種挑戰: 管理用來加密的密鑰。. 如果密鑰丟失，將永遠失去你的數據，如果密鑰泄露，數據同樣存在風險. 因此，要認真研究所選產品的密鑰管理能力，最小化地減少密鑰丟失的風險。
除了保護數據不被竊聽，也要考慮如何保護其免受災難。對EBS卷定期快照，以確保它是高度耐用和可用性?？煺帐菨u進性的，存儲在Amazon S3(獨立的地理位置)上，并可以幾次點擊或命令行調用完成恢復。
保護AWS 憑據
AWS 提供了兩種類型的安全憑據： AWS 訪問密鑰和 X.509 證書。AWS訪問密鑰有兩部分: 密鑰 ID和安全密鑰 。當使用 REST 或 Query API時,必須使用安全密鑰在請求驗證中計算簽名。為了防止在傳輸中被篡改，所有的請求應通過HTTPS發送。
如果AMI需要與其他的AWS 云服務通信 (例如輪詢 Amazon SQS 或者從 Amazon S3中讀取數據), 一個典型錯誤是將AWS 憑據嵌入到AMI中，正確方法應該是在發送前傳遞參數[17].
如果安全密鑰被破壞,應該通過新的密鑰ID獲得新的安全密鑰。作為一個好的方式，建議在應用程序架構中采用密鑰輪換機制，讓可以定期使用它，或者偶爾(當心懷不滿的雇員離開公司)，以確保受損密鑰不能持續工作。
另一種方式是采用 X.509 證書來研制特定的AWS服務。證書文件在base64-encoded DER證書主體中包含了公鑰，另一個文件包含了base64-encodedPKCS#8 私鑰。在aws.amazon.com 和 AWS Management Console 中，AWS支持多因素驗證。
在 IAM 中管理用戶權限
AWS IAM42 能夠AWS賬號內管理多個用戶的權限。 一個用戶(在AWS賬號內)是訪問AWS云服務的唯一安全身份。IAM 消除了密碼和訪問密鑰的共享，可以方便的開通或禁止用戶訪問。
IAM是實現安全性的一個最佳實踐, 例如通過授權實現最低訪問權限，只有通過授權的用戶才能訪問AWS服務和資源。IAM 是默認安全的，新用戶沒有被準確授權的話無法訪問AWS服務。
IAM 原生集成了大多數的AWS 云服務。IAM的API不會變化，應用和工具在權限變化時可以進行運行。應用只需要在開始時為新用戶生成訪問密鑰。當與其他AWS服務交互的時候，應該最小化地使用 AWS的賬號憑據，這樣才能分享IAM帶來的好處。
應用安全
安全組是網絡流量入口規則的集合，需要指定TCP 和 UDP 端口, ICMP 類型和代碼,以及源地址等,每個Amazon EC2實例都被一個或多個安全組所保護。安全組為運行實例提供基本的類似防火墻保護。例如，隸屬應用的實例有如下的安全組設置:
限制呼入流量的另一種方式是配置實例的軟件防火墻。Windows 實例有內置的防火墻， Linux 實例使用 netfilter45 和 iptables.
隨著時間的推移，如果在軟件中發現錯誤，需要打補丁來修復，應該保障下面的措施是應用的安全最大化：
定期下載補丁從供應商的網站并更新到AMI 中;
從重新部署新AMI實例和測試應用程序，以確保補丁不破壞任何東西，同時確保最新的AMI部署到所有實例;
開發測試腳本定期地進行自動化安全檢查;
確保第三方軟件配置為最安全設置
除非絕對必要，否則永遠不要以root或管理員身份運行的進程
所有在云時代之前的標準安全實踐依然適用，例如采用良好的編碼習慣，隔離敏感數據等。
現在回想起來，云技術簡化了物理安全的復雜性，通過工具控制和相關特性可以確保應用程序安全。
未來的研究方向
應用不用關心物理硬件的時代并不遙遠。作為一個架構師，只需要管理抽象的計算，存儲和網絡資源，而不是物理服務器。即使底層物理硬件發生故障或被拆除或更換，應用程序都將繼續運行。應用程序將適應不斷變化的需求模式且瞬間自動調配資源，從而在所有時間達到最高的利用率水平。擴展性，安全性，高可用性，容錯性，可測性和彈性都是應用架構的配置屬性，而且在平臺構建時自動內置了。
但是，我們還沒有到那樣的程度?，F在，可以通過文中的最佳實踐來建立在云計算中應用來具備這些特質?；谠朴嬎慵軜嫷淖罴褜嵺`還在繼續發展，并作為研究人員，我們應該不僅著眼于增強云計算的知識而且要關注工具構建，技術和流程，這將更容易讓開發人員和架構師把應用程序遷移到云計算環境中。
結論
本文為云計算架構師提供了設計高效云應用程序的規范性指導。
通過專注于概念和最佳實踐，例如設計失敗，應用程序組件解耦合，理解和實現彈性，彈性與并行結合，并在應用程序架構的各個層面整合安全，云計算架構師可以了解到構建高可擴展的云應用程序時必要的設計要素。
AWS云服務提供了高度可靠的按需付費的基礎設施。在AWS具體策略中突出可如何使用這些服務來設計云應用。作為一名研究者，最好充分發揮這些商業服務的作用，站在巨人的肩膀上，進一步增強基于云計算的創造。
京公網安備 11010502049343號