近年來，對于打造高度可擴(kuò)展的應(yīng)用程序，軟件架構(gòu)師們挖掘了若干相關(guān)理念，并以最佳實踐的方式加以實施。在今天的“信息時代”，這些理念更加適用于不斷增長的數(shù)據(jù)集，不可預(yù)知的流量模式，以及快速響應(yīng)時間的需求。本文將強(qiáng)調(diào)并重申其中的一些傳統(tǒng)觀念，并討論他們?nèi)绾卧谌诤显朴嬎愕陌l(fā)展，還將討論由于云計算的動態(tài)性而產(chǎn)生的一些前所未有的概念(如彈性)。

本文的目標(biāo)是面向云架構(gòu)師，如何將移動企業(yè)級應(yīng)用從一個固定的物理環(huán)境遷移到虛擬化云環(huán)境。本文的重點是如何構(gòu)建一個新的云應(yīng)用或現(xiàn)有應(yīng)用程序遷移到云環(huán)境所涉及的概念，原則和最佳實踐。

[[130964]]

背景介紹

作為云架構(gòu)師，理解云計算的優(yōu)勢非常重要。在本節(jié)中，我們將探討一些云計算的技術(shù)優(yōu)勢和商業(yè)優(yōu)勢以及各種各樣的AWS服務(wù)。

云計算的商業(yè)優(yōu)勢

在云中構(gòu)建應(yīng)用程序有一些明顯的商業(yè)優(yōu)勢，這里列出機(jī)構(gòu)主要特點：

前期基礎(chǔ)設(shè)施投資幾乎為零：如果你要建立一個大型的系統(tǒng)，它可能需要大量投資用于于機(jī)房，物理安全，硬件(機(jī)架，服務(wù)器，路由器，備用電源)，硬件管理(電源管理，散熱)，和運(yùn)維人員。由于高昂的前期成本，該項目通常甚至開始之前需要多輪的管理審批和論證?，F(xiàn)在，采用公有云環(huán)境，幾乎沒有固定成本或啟動成本。

基礎(chǔ)設(shè)施即時性：在過去，如果你的應(yīng)用程序開始大規(guī)模上量，而你的系統(tǒng)或基礎(chǔ)設(shè)施沒有在規(guī)模上跟上來，將會極大影響應(yīng)用的成功。相反，如果前期投入了大量資金，而應(yīng)用沒有得到普及，你的系統(tǒng)或基礎(chǔ)設(shè)施又將成為失敗的犧牲品。通過在云環(huán)境自適應(yīng)部署應(yīng)用程序，就可以不必?fù)?dān)心是否要預(yù)先采購大型的系統(tǒng)。這增加了靈活性，降低了風(fēng)險和運(yùn)營成本，因為你可以根據(jù)用于成長的規(guī)模而按需支付費用。

更有效地利用資源：系統(tǒng)管理員通常會擔(dān)心新硬件的采購(資源耗盡的情況)和更高的基礎(chǔ)設(shè)施利用率(資源冗余余或閑置的情況)。在云環(huán)境中，我們可以根據(jù)該應(yīng)用程序請求量更高效地管理資源以及有效地按需釋放資源。

根據(jù)使用計算成本：用工具式的定價，可以只對已使用的基礎(chǔ)設(shè)施付費而不必支付那些分配了但未使用的基礎(chǔ)設(shè)施。這增加了一個節(jié)省成本的新維度。當(dāng)部署了優(yōu)化補(bǔ)丁來更新云應(yīng)用時，你可以立竿見影地看到成本節(jié)約(有時會提前出現(xiàn)在下個月的賬單里)。例如，如果一個緩存層可以減少70%的數(shù)據(jù)請求，你馬上就可以在下一個賬單里看到回報。此外，如果您正在云上構(gòu)建一個平臺，同樣可以把這個靈活可變的基于使用的成本結(jié)構(gòu)傳遞給自己的客戶。

縮短產(chǎn)品上市時間：并行化是加快處理速度的重要方式。如果一個計算密集型或數(shù)據(jù)密集型任務(wù)在一臺機(jī)器上并行處理需要運(yùn)行500小時，通過云架構(gòu)，能夠復(fù)制并運(yùn)行500個實例來處理相同的任務(wù)，并在1小時內(nèi)完成。具有彈性的基礎(chǔ)設(shè)施提供了利用并行化的成本效益來縮短產(chǎn)品上市時間的能力。

云計算的技術(shù)優(yōu)勢：

云計算的技術(shù)優(yōu)勢如下：

• 自動化：“腳本化的基礎(chǔ)設(shè)施”：可以通過充分利用可編程(API驅(qū)動的)基礎(chǔ)設(shè)施，可重用構(gòu)建和部署系統(tǒng)。
• 自動擴(kuò)展：無需任何人工干預(yù)，就可以根據(jù)需求對應(yīng)用進(jìn)行雙向擴(kuò)展。自動縮放提高了自動化程度從而更加高效。
• 主動擴(kuò)展：基于需求預(yù)期和流量模式的合理規(guī)劃，可以對應(yīng)用進(jìn)行雙向擴(kuò)展讓從而保持低成本運(yùn)營。
• 更有效的開發(fā)周期：可以很容易地克隆開發(fā)和測試環(huán)境到生產(chǎn)系統(tǒng)。不同階段的環(huán)境可以很容易地推廣到生產(chǎn)系統(tǒng)。
• 改進(jìn)的可測性：不需要進(jìn)行硬件耗盡的測試。注入和自動化測試能夠持續(xù)在開發(fā)過程的每一個階段。我們可以建立一個預(yù)配置環(huán)境——“即時測試實驗室”，僅用于一段時間的測試。
• 災(zāi)難恢復(fù)和業(yè)務(wù)連續(xù)性：云服務(wù)為維護(hù)一系列DR服務(wù)器和數(shù)據(jù)存儲提高了低成本選擇。使用云服務(wù)，你可以在幾分鐘內(nèi)完成將某一地點的環(huán)境復(fù)制到其他地域的云環(huán)境中。
• 流量溢出到云環(huán)境：通過幾次點擊和有效的負(fù)載均衡策略，可以創(chuàng)建路由將超出的訪問流量轉(zhuǎn)移到云環(huán)境中的一個完整的防溢應(yīng)用程序。

#p#

AWS 云服務(wù)

AWS云服務(wù)以最小的支持和管理成本，通過高度可靠和可擴(kuò)展的基礎(chǔ)設(shè)施，提供了Web應(yīng)用部署的解決方案，其靈活性遠(yuǎn)高于自建的基礎(chǔ)設(shè)施，無論這些設(shè)施是企業(yè)內(nèi)部的部署環(huán)境還是在數(shù)據(jù)中心設(shè)施。

如今，AWS提供了各種基礎(chǔ)設(shè)施服務(wù)。下圖將為您介紹了AWS的術(shù)語，并幫助您了解應(yīng)用程序可以用不同的AWS服務(wù)以及不同的服務(wù)間是如何交互。

AmazonEC2 是一個Web服務(wù)，提供容量可調(diào)整的云計算能力。你可以將操作系統(tǒng)，應(yīng)用軟件和相關(guān)配置捆綁在一起，然后設(shè)置成亞馬遜機(jī)器映像(AMI)。然后，您可以使用這些AMI生成多個虛擬化實例，以及使用簡單的Web服務(wù)調(diào)用，快速雙向擴(kuò)展容量，也可以根據(jù)容量需求的變化而去除他們。您可以購買點播實例以小時付費或按次付款并保留實例，在使用率較低時，可以申辦未使用的容量，并進(jìn)一步降低成本。實例可以在一個或多個地域運(yùn)行。每個地域都有多個可用區(qū)?？捎脜^(qū)是被設(shè)計成與其他可用區(qū)的故障隔離，并提供了與同一地域其他可用區(qū)不同廉價低延遲的連接網(wǎng)絡(luò)。

彈性IP地址允許您通過編程的方式將一個靜態(tài)的IP地址分配給一個實例。您可以使用Amazon CloudWatch監(jiān)控一個Amazon EC2實例的可見性資源利用率，運(yùn)行性能和全部要求模(包括指標(biāo)，如CPU利用率，磁盤讀取和寫入，以及網(wǎng)絡(luò)流量)。根據(jù)CloudWatch收集一定的條件指標(biāo)，您可以創(chuàng)建Auto-scaling Group來使用自擴(kuò)展特性來實現(xiàn)自動縮放。您也可以通過使用彈性負(fù)載均衡ELB服務(wù)創(chuàng)建一個彈性負(fù)載平衡器分發(fā)請求流量。彈性塊存儲(EBS)將持久性存儲通過網(wǎng)絡(luò)方式關(guān)聯(lián)到Amazon EC2實例中。對于EBS的一致性的卷快照，可以創(chuàng)建并存儲在亞馬遜簡單存儲服務(wù)Amazon S3中。

Amazon S3是高度耐用和分布式數(shù)據(jù)存儲。用一個簡單的Web服務(wù)接口，在任何時間，在網(wǎng)絡(luò)上的任何地方都可以使用標(biāo)準(zhǔn)的HTTP命令存儲和檢索大量在數(shù)據(jù)箱中的對象。作為Web服務(wù)的傳輸內(nèi)容，對象的副本(靜態(tài)或流媒體內(nèi)容)都可以通過創(chuàng)建并使用Amazon CloudFront的緩存服務(wù)來分布在世界各地的14個地域-。亞馬遜SimpleDB也是一個Web服務(wù)，它提供了一個數(shù)據(jù)庫的核心功能，無需復(fù)雜操作，就可以完成實時查詢和結(jié)構(gòu)化數(shù)據(jù)的簡單查詢。域是由鍵值對所描述的條目集合，我們可以組織數(shù)據(jù)集到域，并對該特定域中的數(shù)據(jù)進(jìn)行查詢(NoSql服務(wù))。

Amazon RDS 提供了在云環(huán)境中建立，操作和擴(kuò)展關(guān)系型數(shù)據(jù)庫的簡單方法。你可以發(fā)布一個DB Instance 就可以訪問 MySQL數(shù)據(jù)庫的全部特性，而不必?fù)?dān)心通用的數(shù)據(jù)庫管理任務(wù)例如 備份，補(bǔ)丁管理等。

Amazon SQS 是一個高可靠，高擴(kuò)展的分布式消息隊列，通過消息隊列可以完成不同主機(jī)以及應(yīng)用組件間的消息傳遞。

Amazon SNS 使用發(fā)布-訂閱協(xié)議并創(chuàng)建相關(guān)主題，提供了從云端通知應(yīng)用或用戶的簡單方法。

Amazon EMR 提供了以EC2 和S3為基礎(chǔ)設(shè)施的 Hadoop 框架，可以創(chuàng)建自定義的作業(yè)流. 作業(yè)流就是 MapReduce 過程序列.

Amazon VPC allows能夠在AWS內(nèi)部將企業(yè)網(wǎng)擴(kuò)展為私有云。Amazon VPC 使用IPSec 管道模式在你的數(shù)據(jù)中心網(wǎng)關(guān)和AWS網(wǎng)關(guān)之間建立一個安全連接。

Amazon Route53 是一個高可擴(kuò)展的 DNS 服務(wù)，你可以在每一個域創(chuàng)建一個HostedZone來管理所有的DNS記錄。

AWS IAM 在AWS賬戶內(nèi)部通過唯一的安全準(zhǔn)則可以創(chuàng)建多個用戶，并具有不同地權(quán)限。 IAM與AWS 云服務(wù)以原生方式集成在一起. 在使用IAM時，不需要退出應(yīng)用和先關(guān)工具，就可以保持AWS的服務(wù)持續(xù)運(yùn)行。

AWS 通過支付的基礎(chǔ)設(shè)施提供了各種各樣的支付方式和計費服務(wù)。

所有AWS 云服務(wù)都提供了按使用計費的方式，而不需要長期承諾或合同。 例如, 按小時支付 Amazon EC2 實例的使用，按照存儲量和傳輸量對Amazon S3付費. 更多信息可以關(guān)注AWS的網(wǎng)站。

注意，使用AWS云計算并不需要犧牲靈活性和也不改變你的使用習(xí)慣：

• 你可以隨意使用你選擇的編程模型，語言，或者操作系統(tǒng)(Windows, OpenSolaris or any flavor of Linux)
• 你可以隨意使用任何一個AWS服務(wù)或者任何服務(wù)的組合，只要最大限度地滿足你的需求就可以了。
• 由于 AWS提供了可以調(diào)整的資源 (存儲, 帶寬和技術(shù)能力),你可以自由地增減資源并安裝真正的使用付費。
• 可以繼續(xù)使用原來的系統(tǒng)管理工具，將你的數(shù)據(jù)中心擴(kuò)展到云端。

#p#

云計算中的基本理念

云計算強(qiáng)化了構(gòu)建高度可擴(kuò)展互聯(lián)網(wǎng)架構(gòu)的一些基本理念，同時引入了一些新的概念完全該變量應(yīng)用的構(gòu)建和部署方式。因此，當(dāng)你在從概念設(shè)計到實施的過程中，你可能會感到“什么都變了，卻又沒什么不同”。云計算改變了處理方式，模式，實踐方式，甚至哲學(xué)理念，同時強(qiáng)化了傳統(tǒng)的SOA原則，這些原則比以前更加重要。在本節(jié)，你將看到云計算中的新概念以及對SOA原理的重申。

構(gòu)建傳統(tǒng)應(yīng)用時，權(quán)衡體系結(jié)構(gòu)和經(jīng)濟(jì)性之間的關(guān)系需要大量的開發(fā)經(jīng)驗. 云計算帶來了新的理念，現(xiàn)探討如下:

構(gòu)建可擴(kuò)展架構(gòu)：

為了獲得一個可擴(kuò)展基礎(chǔ)設(shè)施的好處，構(gòu)建一個可擴(kuò)展的架構(gòu)非常關(guān)鍵。

云計算在設(shè)計上提供了概念上的無限可擴(kuò)展。但是，如果你的架構(gòu)部署可擴(kuò)展的，也無法使用到云計算的可擴(kuò)展性帶來的優(yōu)勢。

你必須確定架構(gòu)中的瓶頸和單點組件，確定架構(gòu)中哪些是不能按需部署的部分，然后重構(gòu)應(yīng)用來調(diào)整為可擴(kuò)展的架構(gòu)，從獲得云計算的益處。

一個真正可擴(kuò)展應(yīng)用的特點:

• 增加資源就可以按比例增加性能
• 一個可擴(kuò)展的服務(wù)可以處理異構(gòu)的兼容性
• 一個可擴(kuò)展的服務(wù)可以有效的運(yùn)營
• 一個可擴(kuò)展的服務(wù)是彈性的
• 一個可擴(kuò)展的服務(wù)能夠在業(yè)務(wù)增長時成本更低(單位成本隨著單元的增加而遞減)

這些特性應(yīng)該是應(yīng)用中的固有部分，在架構(gòu)設(shè)計時要銘記于心，基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)要協(xié)同工作完成可擴(kuò)展性。

對彈性的理解

下圖解釋了一個云應(yīng)用架構(gòu)中按需擴(kuò)展的不同方法。

放大擴(kuò)展的途徑: 使用可擴(kuò)展的應(yīng)用架構(gòu)不用擔(dān)心為了滿足需求而大規(guī)模投資以及購買更強(qiáng)大的服務(wù)器(垂直擴(kuò)展)這種方法通常工作到一個點，但是在新設(shè)備部署前就可以降低成本 (見圖中的“Huge capital expenditure” )或者滿足業(yè)務(wù)增長的需要 (見圖中“You just lostyour customers”).

傳統(tǒng)向外擴(kuò)展的途徑： 創(chuàng)建水平擴(kuò)展的架構(gòu)和投資小塊的基礎(chǔ)設(shè)施。大多數(shù)業(yè)務(wù)或大規(guī)模web應(yīng)用都采用如下的模式，分布式應(yīng)用組件，聯(lián)合數(shù)據(jù)集和SOA的設(shè)計。 這種方法通常比放大擴(kuò)展更有效。然而，這需要準(zhǔn)確的業(yè)務(wù)預(yù)期才能實現(xiàn)滿足需求的部署。經(jīng)常會導(dǎo)致容量過剩(“燒錢”) 和持續(xù)人工監(jiān)測 (“浪費人力成本”).此外，如果遇到業(yè)務(wù)的爆發(fā)式增長，系統(tǒng)將無法正常工作。

注意：這兩種方法具有初始啟動成本，而且在本質(zhì)上是被動的。

傳統(tǒng)結(jié)構(gòu)一般要預(yù)測幾年內(nèi)系統(tǒng)所需資源的數(shù)量，如果預(yù)計不足，應(yīng)用將沒有馬力處理預(yù)期外的流量，從而導(dǎo)致客戶的不滿。如果預(yù)計過高，又造成資源浪費。

按需部署和彈性是云計算的天然方式(自動彈性)，使基礎(chǔ)設(shè)施與真實需求盡量匹配，因而可以提供資源利用率及壓縮成本。

彈性是云計算的一個基礎(chǔ)屬性。彈性通過微量的調(diào)整即可實現(xiàn)計算資源的可擴(kuò)展性增減。彈性給云計算帶來絕對的優(yōu)勢，這非常重要。 作為云計算架構(gòu)，要牢記這一概念，并應(yīng)用到系統(tǒng)架構(gòu)中，才能獲得云計算的最大利益。

傳統(tǒng)上，以一個固定的預(yù)部署的剛性基礎(chǔ)設(shè)施來構(gòu)建應(yīng)用，公司不需要每天都要進(jìn)行安裝部署。結(jié)果使大多數(shù)軟件架構(gòu)不適用快速部署和硬件縮減。既然獲取新資源需要較高的實施時間和追加投資，軟件架構(gòu)也不會在硬件利用率的優(yōu)化是投入時間和資源，應(yīng)用在低使用率的硬件上運(yùn)行時可以接受的。在分鐘級獲得新資源是不可能的，所以一個架構(gòu)的彈性也是被忽略的。

在云計算中，這是觀念的改變。云計算以流水線處理的方式獲取所需資源，不再需要預(yù)先采購設(shè)備和保留閑置的硬件。云架構(gòu)可以在幾分鐘內(nèi)完成資源采購或者自動化采購，從而擁有了大量擴(kuò)展和響應(yīng)時間的優(yōu)勢，同樣，也可以釋放掉那些閑置的或低利用率的資源。如果在你的系統(tǒng)架構(gòu)中不能擁抱這樣的變化，就不能分享云計算的全部好處。

作為一個云應(yīng)用架構(gòu)師，你需要創(chuàng)造性地思考在應(yīng)用系統(tǒng)中實現(xiàn)彈性。 例如,基礎(chǔ)設(shè)施被用來白天運(yùn)行，晚上構(gòu)建，在凌晨2點執(zhí)行回歸和單元測試兩個小時 ，其他時間都是空閑的。現(xiàn)在，基礎(chǔ)設(shè)施有了彈性, 可以只支付晚上兩個小時的計算時間。類似的，內(nèi)部故障經(jīng)常出現(xiàn)在容量的峰值(例如5 服務(wù)器 24x7x365)，現(xiàn)在可以按照流量模式來按需配置(如5 服務(wù)器從9AM 到 5 PM 運(yùn)行，而只用2個服務(wù)器在5 PM 到 9 AM運(yùn)行)。

云架構(gòu)的智能彈性設(shè)計使基礎(chǔ)設(shè)施能夠按需運(yùn)行，這本身就是一門藝術(shù)。彈性應(yīng)該是一種架構(gòu)設(shè)計的需求或者系統(tǒng)屬性。你可能會問：系統(tǒng)架構(gòu)中的哪些組件或者層次可以成為彈性的?用什么技術(shù)可以使這些組件變得有彈性? 實現(xiàn)彈性對系統(tǒng)架構(gòu)的整體有何影響?

在下一章，將會展示在應(yīng)用中實現(xiàn)彈性的相關(guān)技術(shù)。有效地利用云計算的彈性優(yōu)勢，是架構(gòu)中非常重要的觀念。

無懼約束

當(dāng)你決定架構(gòu)應(yīng)用向云計算遷移的時候，或者將自己的系統(tǒng)規(guī)范映射成云服務(wù)時，要注意到云計算中沒有原來所需的準(zhǔn)確資源定義。例如，云計算中一個服務(wù)器沒有RAM的數(shù)量，或者一個數(shù)據(jù)庫實例需要更多的IOPS。

要理解云計算提供的是抽象資源，這才使按需實施模式變得強(qiáng)大。當(dāng)使用云資源時不用擔(dān)心不夠用，你的硬件沒有真正確切地復(fù)制在云環(huán)境中，這非常重要，你能夠獲得任何你所需要的資源。

例如，云計算沒有告訴你一個服務(wù)器中確切的內(nèi)存數(shù)量，使用了向memcached的分布式緩存，或者將數(shù)據(jù)在多個服務(wù)器上做了分區(qū)。如果你的數(shù)據(jù)庫需要更多的IOPS，且不能映射到云中的服務(wù)，可以根據(jù)使用用例和數(shù)據(jù)類型選擇其他的云計算方案。如果是一個重度讀應(yīng)用，你可以將這些讀請求分布到一組同步的從服務(wù)中。另一種方法是，采用分片算法來路由數(shù)據(jù)，或者采用各種數(shù)據(jù)庫集群解決方案。

回顧一下, 當(dāng)你將靈活性和按需實施能力結(jié)合在一起的時候，就已經(jīng)意識到資源約束的解除顯然提高了可擴(kuò)展性，改善了系統(tǒng)的整體性能。

虛擬化管理

云計算的到來將系統(tǒng)管理員的角色變成了“虛擬系統(tǒng)管理員”。這意味著這些管理員們更關(guān)注應(yīng)用本身那些有趣的事情，以及從整體上決定哪些對業(yè)務(wù)是最佳的。系統(tǒng)管理員不再需要部署服務(wù)器，安裝軟件以及連接網(wǎng)絡(luò)設(shè)備，所有這繁復(fù)的工作都可以通過幾下點擊和幾個命令行調(diào)用就完成了。基礎(chǔ)設(shè)施的可編程化使云計算自動化程度更高。系統(tǒng)管理員需要升級自己的技術(shù)結(jié)構(gòu)來學(xué)習(xí)如何使用腳本管理抽象的云資源。

類似地，DBA的角色也變成了“虛擬DBA”，通過基于web的終端管理資源，執(zhí)行腳本在容量用光時增加新的數(shù)據(jù)庫容量，以及每天的自動化處理。

虛擬DBA必須學(xué)習(xí)新的部署方法(通過虛擬機(jī)鏡像)，擁抱新的模型 (并行查詢，遠(yuǎn)程災(zāi)備和異步復(fù)制),反思數(shù)據(jù)的架構(gòu)方法 (分片,水平分區(qū),聯(lián)盟) 以及針對不同數(shù)據(jù)集采用不同的云存儲服務(wù)。

在傳統(tǒng)企業(yè)中，應(yīng)用開發(fā)者沒有和網(wǎng)絡(luò)管理員在一起緊密的工作，網(wǎng)絡(luò)管理員也沒有關(guān)于應(yīng)用的膠水。結(jié)果是，網(wǎng)絡(luò)層和應(yīng)用架構(gòu)層優(yōu)化經(jīng)常被忽略。 通過云計算，二者被凝聚在一起，在將來做應(yīng)用架構(gòu)的時候，公司將形成更多的跨團(tuán)隊融合。

#p#

云架構(gòu)最佳實踐

在本節(jié),我們將學(xué)習(xí)到在云端構(gòu)建應(yīng)用的最佳實踐。

容錯性設(shè)計和零故障

大拇指原則：在云端進(jìn)行架構(gòu)設(shè)計時要保持悲觀，假設(shè)所有事物都會發(fā)生故障。換句話來說，要面向故障的自動化恢復(fù)來設(shè)計，實施和部署。

特別地，假設(shè)硬件會發(fā)生故障，斷電了，這些災(zāi)難使應(yīng)用不能工作了，某些天的每秒請求超出的限制，不得不停止服務(wù)， 軟件也發(fā)生了故障等。作為一個悲觀主義者，在設(shè)計時就要思考恢復(fù)策略，將使整個系統(tǒng)變得更好。

如果意識到了故障切換并且作為架構(gòu)的一部分，通過可擴(kuò)展的基礎(chǔ)設(shè)施來構(gòu)建故障處理的機(jī)制，你將不再建一個容錯的架構(gòu)，而是由云環(huán)境完成了。

你會問：系統(tǒng)中一個節(jié)點故障時發(fā)生了什么?如何識別故障?如何更換這個節(jié)點?我要規(guī)劃怎樣的場景?什么是我的單點故障?如果在一組服務(wù)器之前使用了負(fù)載均衡，那么均衡器掛了怎么辦? 如果架構(gòu)中采用了主從結(jié)構(gòu)，主節(jié)點掛了怎么辦?如何故障切換?一個與主服務(wù)器同步的新從設(shè)備如何被實例化?

和硬件故障設(shè)計一樣，必須進(jìn)行軟件的故障設(shè)計。

你會問:如果一個依賴服務(wù)的接口變了，我的應(yīng)用怎么辦?如果下行服務(wù)超時或者返回異常怎么辦?如果緩存的鍵值數(shù)量超出了一個實例的內(nèi)存限制怎么辦?

建立處理故障的機(jī)制. 例如, 下面的策略可以為故障處理提供幫助:

1. 數(shù)據(jù)的連貫備份和恢復(fù)以及自動執(zhí)行

2. 構(gòu)建重啟的進(jìn)程

3. 從隊列中重載消息來完成系統(tǒng)狀態(tài)的重新同步

4. 保留已經(jīng)配置和優(yōu)化好的虛擬鏡像來支持步驟2和3

5. 避免內(nèi)存中的會話或者狀態(tài)化的上下文，把它們移到數(shù)據(jù)存儲中。

好的云架構(gòu)可以減少重新加載或者重新啟動。例如使用 Amazon SQS 和Amazon SimpleDB的組合, 這個控制器的架構(gòu)對這些故障非常有彈性。對實例而言，如果控制器上的實例線程假死，它可以恢復(fù)到以前的狀態(tài)就像什么都沒發(fā)生過似的。這是通過創(chuàng)建一個預(yù)先配置好的AMI完成的，它重啟動的時候從Amazon SQS隊列中讀取所有消息，并從SimpleDB讀取它們的所有狀態(tài)。

針對底層硬件故障的可能情況進(jìn)行設(shè)計，可以做到有備無患。

這一設(shè)計原則能夠?qū)崿F(xiàn)運(yùn)營友好的應(yīng)用[11]。如果你通過主動測量和動態(tài)負(fù)載均衡來擴(kuò)展這一原理，由于云環(huán)境的多租戶特性，你可以實現(xiàn)各種各樣的網(wǎng)絡(luò)和硬盤性能。

AWS提供了特殊的策略來實施這一最佳實踐:

1.使用彈性IP來優(yōu)雅地實現(xiàn)故障切換: 彈性IP是將一個靜態(tài)的IP動態(tài)地重新映射。你可以通過重新映射將故障切換到另外的一組服務(wù)器上，流量也將路由到新的服務(wù)器。這對應(yīng)硬件故障或者應(yīng)用升級都非常有效。

2.使用多可用區(qū): 可用區(qū)是概念上的邏輯數(shù)據(jù)中心。在多可用區(qū)上部署你的系統(tǒng)架構(gòu)，可以保證高可用性。使用 Amazon RDS Multi-AZ [21] 的部署功能可以在多可用區(qū)上自動復(fù)制數(shù)據(jù)庫。

3.維護(hù)一個AMI能夠在不同的可用區(qū)上輕松地克隆和恢復(fù)環(huán)境;在可用區(qū)間維護(hù)多個從數(shù)據(jù)庫從而實現(xiàn)熱備份。

4. 使用 Amazon CloudWatch(或各種實時的開源監(jiān)測工具) 以可視化的方式對硬件故障或者性能下降采用合適的措施。建立一個自動可擴(kuò)展組以便用新的實例替換那些不健康的 Amazon EC2實例。

5. 使用Amazon EBS，建立 cron jobs來實現(xiàn)將增量快照自動地上傳到AmazonS3，使數(shù)據(jù)與實例獨立開來。

6. 使用Amazon RDS ，設(shè)置為備份的保留期限，以便它可以執(zhí)行自動備份。

組件解耦合

云計算強(qiáng)化了SOA的設(shè)計原理，系統(tǒng)組件的耦合越松，擴(kuò)展起來越方便越好。

構(gòu)建組件的關(guān)鍵是減少之間的依賴，如果一個組件死掉了，沒有響應(yīng)，或者響應(yīng)時間過長，系統(tǒng)中的其他組件應(yīng)該可以繼續(xù)正常工作。 顯然，松耦合使組件間以及層次間相互獨立，這樣每個組件可以將其他組件作為黑盒子完成異步交互。例如

一個web應(yīng)用架構(gòu)的情況,將應(yīng)用服務(wù)器，web服務(wù)器和數(shù)據(jù)分離開來，該應(yīng)用程序服務(wù)器不知道你的Web服務(wù)器，反之亦然，這些層之間的解耦合，不存在代碼依賴或功能交叉。在批處理的系統(tǒng)架構(gòu)中，可以創(chuàng)建相互獨立的異步組件。

你可能會問:哪些業(yè)務(wù)組件或特性可以從當(dāng)前的單點應(yīng)用中隔離出來，可以獨立運(yùn)行么?那么，在不破壞當(dāng)前系統(tǒng)的前提下能夠為這個組件增加更多的實例么，以及同時服務(wù)更多的用戶? 付出多大的努力才能封裝這些組件并使其異步通信呢?

組件解耦合，異步系統(tǒng)和水平擴(kuò)展在云計算中是非常重要的。你不僅可以為同一組件增加多個實例實現(xiàn)擴(kuò)展，而且允許你設(shè)計創(chuàng)新的混合模式，其中一些成分繼續(xù)私有部署運(yùn)行，而其他組件可以利用云計算可擴(kuò)展的優(yōu)勢，使用云計算的計算能力和帶寬。這樣，以最小的代價，你可以通過實施智能負(fù)載均衡策略將在“溢出”多余的流量移動到云上。

建立松耦合系統(tǒng)的另一方式是使用消息隊列。如果兩個組件間通過隊列或者緩沖區(qū)連接的話，可以支持高并發(fā)，高可用和負(fù)載削峰。其結(jié)果是，即使元件部分功能暫時不可用，整個系統(tǒng)仍然繼續(xù)執(zhí)行。如果一個組件死亡或暫時不可用時，系統(tǒng)將消息緩存起來，在組件恢復(fù)時再處理他們。

在GrepTheWeb的架構(gòu)這篇文章中可以看到消息隊列的充分使用[6]。在 GrepTheWeb中,

如果忽然間有大量的請求到達(dá)服務(wù)器(互聯(lián)網(wǎng)引發(fā)的過載情況)或者正則表達(dá)式的處理花費了大量的時間(一個組件響應(yīng)遲鈍)， Amazon SQS 將在一段時間內(nèi)緩存這些請求，使這些延遲不會影響其他組件。

AWS提供了特殊的策略來實施這一最佳實踐:

1. 使用Amazon SQS來隔離組件

2. 使用Amazon SQS作為組件間的緩沖區(qū)

3. 設(shè)計的每個組件暴露其服務(wù)接口，負(fù)責(zé)其自己的可擴(kuò)展性，并與其他組件異步交互

4. 綁定組件的邏輯結(jié)構(gòu)并制成AMI，以便可以時常部署

5. 使應(yīng)用盡可能無狀態(tài)化，將會話的狀態(tài)存儲在組件的外部(例如SimpleDB)

實現(xiàn)彈性

云計算為你的應(yīng)用帶來了彈性的概念。有三種方法實現(xiàn)彈性：:

1. 周期性主動擴(kuò)展: 固定時間將的周期性擴(kuò)展(按天, 周, 月, 季度)

2. 基于事件的主動擴(kuò)展:根據(jù)安排好的商務(wù)活動(新品發(fā)布，市場宣傳活動)所期望的請求流量爆發(fā)而做的擴(kuò)展

3. 按需自動擴(kuò)展 ：通過監(jiān)控服務(wù)的使用，系統(tǒng)可以根據(jù)相關(guān)指標(biāo)觸發(fā)適當(dāng)?shù)膭幼鱽頂U(kuò)容或減負(fù) (例如一個實例的服務(wù)器或者網(wǎng)絡(luò)IO的使用情況)

為了實現(xiàn)彈性,首先要做到自動化部署，流水線配置和構(gòu)建流程，這樣可以保證在沒有人工參與的情況下自動地實現(xiàn)系統(tǒng)的可擴(kuò)展。這能導(dǎo)致即時節(jié)約成本，保證資源與需求高度匹配，而不需為了潛在需求運(yùn)行的服務(wù)器在低利用率運(yùn)行。

#p#

基礎(chǔ)設(shè)施自動化

使用云環(huán)境最重要的優(yōu)勢之一是能夠使用API完成自動化部署。在遷移的早期花時間考慮自動化部署是非常值得的。創(chuàng)建一個自動化和可重復(fù)的部署流程能夠減少錯誤，有效地擴(kuò)展和升級。

自動化部署:

• 建一個庫：頻繁使用的小腳本(用于安裝和配置)
• 使用AMI內(nèi)綁定的代理來管理配置和部署流程
• 實例自舉

實例自舉

讓你的實例在啟動的時候問你個問題 “我是誰，我的角色是什么?” 每個實例都應(yīng)該在環(huán)境中扮演一個角色(“DB server”, “app server”, “slave server” 等) 。 這個角色可能是傳遞給啟動過程的參數(shù)，用來指示AMI實例化社的步驟。再啟動時,基于角色和所關(guān)聯(lián)集群的功能，實例可以獲取所需的資源 (代碼, 腳本, 配置)。

實例自舉的好處:

1. 少量操作即可完成環(huán)境重建(開發(fā), 測試, 生成)

2. 實現(xiàn)對抽象云資源的更多控制

3. 減少人為部署的錯誤

4. 創(chuàng)建了一個自愈環(huán)境對硬件故障而言更有彈性

AWS 提供了基礎(chǔ)設(shè)施自動化的相關(guān)策略：

1. 使用Amazon EC2中的Auto-scalingfeature 為不同的集群定義Auto-scaling groups

2. 使用Amazon CloudWatch 來監(jiān)控系統(tǒng)指標(biāo)(CPU, Memory, Disk I/O, Network I/O) ，然后采取合適的操作(使用Auto-scalingservice動態(tài)啟用新的AMI)或者發(fā)通知 。

3. 動態(tài)存儲和恢復(fù)配置信息: 利用Amazon SimpleDB 在實例啟動時獲得配置數(shù)據(jù)。SimpleDB也可以用來存儲實例的信息如 IP 地址,機(jī)器名和角色.

4. 設(shè)計一個構(gòu)建流程將最新版本存入AmazonS3; 從而在系統(tǒng)啟動的時候加載最新的版本

5. 構(gòu)建資源管理工具(自動化腳本,配置好的鏡像 )或者使用開源的配置管理工具如 Chef18, Puppet19, CFEngine 20或Genome21.

6. 將裁減的操作系統(tǒng)和軟件依賴綁定并放入AMI中，這樣便于管理和維護(hù)。在啟動時傳遞配置文件和參數(shù)，啟動后獲得用戶和實例的相關(guān)數(shù)據(jù).

7. 將一個實例管理一個或多個EBS卷可以減少綁定和啟動的時間。創(chuàng)建通用卷快照，可以在合適的時候共享這些快照。

8. 假定應(yīng)用組件處于不良狀態(tài)。例如，動態(tài)綁定一個新節(jié)點的IP到集群中，自動故障切換以及故障發(fā)生時啟動一個新的克隆。

并行化思考

云計算能輕松實現(xiàn)并行化。無論是從云中請求數(shù)據(jù)，將數(shù)據(jù)存儲到云中，在云中處理數(shù)據(jù)(或執(zhí)行的作業(yè))，作為一個云服務(wù)架構(gòu)師，在架構(gòu)設(shè)計時一定要將并行化秉記于心。

由于云計算可以非常容易地創(chuàng)建可重復(fù)流程，所以不但要盡可能地實現(xiàn)并行化，而且使之自動化執(zhí)行。

當(dāng)數(shù)據(jù)訪問的時候,云環(huán)境可以處理大量的并行操作。為了得到最大的性能和吞吐量， 需要充分利用并行化請求。多線程并發(fā)處理要比順序化請求處理快得多。因此，盡可能地使用非共享原則來充分利用多線程來設(shè)計線程安全的云應(yīng)用。

在云端處理請求的時候，并行處理就越發(fā)重要了。在web應(yīng)用中，一個通常的最佳實踐是使用負(fù)載均衡將請求分布到多個異步的web服務(wù)器中。在批處理應(yīng)用中，可以使用多個從服務(wù)節(jié)點來處理并行化任務(wù)。

當(dāng)并行化和彈性相結(jié)合體現(xiàn)了云計算之美。云應(yīng)用使用少量的API在幾分鐘內(nèi)就可完成計算集群的部署，并行地處理任務(wù)、保存結(jié)果和終止實例。

AWS 面向并行化的相關(guān)策略:

1.對 Amazon S3 多線程化

2. 對 SimpleDB 的GET 和 BATCHPUT 請求多線程化 [3][4] [5]

3. 對每日的批處理任務(wù)(索引，日志分析等)，使用AmazonEMR 創(chuàng)建作業(yè)任務(wù)，能夠并行處理并節(jié)約時間。.

4. 使用彈性負(fù)載。

動靜分離：動態(tài)數(shù)據(jù)靠近計算，靜態(tài)數(shù)據(jù)貼近用戶

一般來說，讓數(shù)據(jù)盡可能靠近你的計算或處理單元，以減少延遲是一個很好的做法。在云計算中，由于必須經(jīng)常處理互聯(lián)網(wǎng)延遲，這一實踐更加重要。此外，在云環(huán)境中，我們必須要為數(shù)據(jù)傳輸?shù)那д鬃止?jié)帶寬付費，成本開銷很大。

如果大量數(shù)據(jù)需要在云計算之外處理，先傳輸再計算可能比較便宜。例如，對于一個數(shù)據(jù)倉庫的應(yīng)用而言，最好是數(shù)據(jù)集先移到云，然后執(zhí)行并行數(shù)據(jù)查詢。對于一個從關(guān)系型數(shù)據(jù)庫存取數(shù)據(jù)的web應(yīng)用，最好也是將數(shù)據(jù)庫和應(yīng)用服務(wù)器一并移到云環(huán)境中。如果數(shù)據(jù)是在云端產(chǎn)生的，則消耗該數(shù)據(jù)的應(yīng)用程序也應(yīng)該部署在云中，以便它們可以享受在云環(huán)境內(nèi)部的免費數(shù)據(jù)傳輸和低時延。例如，在一個電商的應(yīng)用記錄點擊數(shù)據(jù)并生成日志的情況，最好在云中運(yùn)行日志分析和報表引擎。

相反地，如果數(shù)據(jù)是靜態(tài)的，不經(jīng)常改變(例如，圖像，視頻，音頻，PDF文件，JS，CSS文件)，最好是利用CDN服務(wù)的優(yōu)點，內(nèi)容分發(fā)服務(wù)提供更快的對象訪問，使得靜態(tài)數(shù)據(jù)被高速緩存在靠近最終用戶(請求者)的網(wǎng)絡(luò)位置，從而降低了訪問時延。

AWS針對這一最佳實踐的相關(guān)策略：

1. 使用 Import/Export 服務(wù)27.將數(shù)據(jù)盤遷移到云環(huán)境中，用 sneakernet28 tha比互聯(lián)網(wǎng)上傳更快捷而且便宜。.

2. 使用相同的可用區(qū)來發(fā)布集群

3. 創(chuàng)建一個Amazon S3數(shù)據(jù)發(fā)布版本， 充分利用 AmazonCloudFront 在全球14個地區(qū)的CDN服務(wù)

#p#

關(guān)于安全的最佳實踐

在多租戶環(huán)境中，云計算架構(gòu)師經(jīng)?？紤]的就是安全性。安全應(yīng)在云應(yīng)用體系結(jié)構(gòu)的每

一層中都有體現(xiàn)實現(xiàn)。物理安全性通常是由服務(wù)提供商來處理(安全白皮書[7])，這是使用云的一個額外好處。網(wǎng)絡(luò)和應(yīng)用級的安全是你的責(zé)任，應(yīng)該適用業(yè)務(wù)實施最佳實踐。在本節(jié)中，您將了解如何保護(hù)云應(yīng)用程序在AWS環(huán)境中的那些特定的工具，功能和準(zhǔn)則。建議利用這些工具，實現(xiàn)基本安全功能，然后使用適當(dāng)?shù)臉?biāo)準(zhǔn)方法，或其他認(rèn)為合適的安全性最佳實踐。

保護(hù)在途數(shù)據(jù)

如果需要在服務(wù)器和瀏覽器中交互敏感或機(jī)密信息，最好在服務(wù)器實例中配置SSL，需要使用像VeriSign29 或Entrust30這樣的授權(quán)證書。 證書中的公鑰來驗證服務(wù)器和瀏覽器請求，并作為雙向會話數(shù)據(jù)加密的基礎(chǔ)。

通過少量的命令行調(diào)用就可以創(chuàng)建虛擬私有云 (using Amazon VPC)。 這樣可以在云環(huán)境內(nèi)實現(xiàn)資源的邏輯隔離，然后使用業(yè)界標(biāo)準(zhǔn)的IPSec VPN 連接來直接訪問資源，也可以在Amazon EC2上建立一個OpenVPN服務(wù)器，然后在所有用戶PC上安裝OpenVPN的客戶端。

保護(hù)數(shù)據(jù)的存儲

如果關(guān)心云環(huán)境中存儲的敏感和機(jī)密數(shù)據(jù)，需要在在上傳文件是進(jìn)行加密。例如，使用任何開源工具加密數(shù)據(jù)或者使用商用的PGP 工具在存儲到Amazon S3前進(jìn)行加密，在下載后進(jìn)行解密。在構(gòu)建HIPAA兼容的應(yīng)用程序時需要保存PHI,這通常是一個好的實現(xiàn)。

在 AmazonEC2上,文件加密依賴于操作系統(tǒng) 。運(yùn)行在Windows 上的Amazon EC2 實例可以使用內(nèi)置 EFS 特性 [16]. 該特性可以對文件或目錄自動加解密，對用戶而言是透明的[19]。此外，和名稱不符的是， EFS 不能加密整個文件系統(tǒng)而只加密單個文件。如果對這個文件系統(tǒng)加密，需要考慮開源的TrueCrypt33 產(chǎn)品; 它與NTFS格式 EBS卷集成的很好。運(yùn)行在Linux上的Amazon EC2實例可以使用各種方式加密文件系統(tǒng)來掛載EBS卷 (EncFS34,Loop-AES35, dm-crypt36,TrueCrypt37). 類似的, 運(yùn)行在OpenSolaris 上的Amazon EC2 實例可以試試 ZFS38 加密支持 [20].無論選擇的是什么，在Amazon EC2 上加密的文件和卷都可以保護(hù)文件和日志數(shù)據(jù)，從而只有用戶和服務(wù)器上進(jìn)程可以看到明文，其他都只能看到密文。

不論你選擇了什么樣的技術(shù)或操作系統(tǒng)，加密數(shù)據(jù)都意味著一種挑戰(zhàn): 管理用來加密的密鑰。. 如果密鑰丟失，將永遠(yuǎn)失去你的數(shù)據(jù)，如果密鑰泄露，數(shù)據(jù)同樣存在風(fēng)險. 因此，要認(rèn)真研究所選產(chǎn)品的密鑰管理能力，最小化地減少密鑰丟失的風(fēng)險。

除了保護(hù)數(shù)據(jù)不被竊聽，也要考慮如何保護(hù)其免受災(zāi)難。對EBS卷定期快照，以確保它是高度耐用和可用性。快照是漸進(jìn)性的，存儲在Amazon S3(獨立的地理位置)上，并可以幾次點擊或命令行調(diào)用完成恢復(fù)。

保護(hù)AWS 憑據(jù)

AWS 提供了兩種類型的安全憑據(jù)： AWS 訪問密鑰和 X.509 證書。AWS訪問密鑰有兩部分: 密鑰 ID和安全密鑰 。當(dāng)使用 REST 或 Query API時,必須使用安全密鑰在請求驗證中計算簽名。為了防止在傳輸中被篡改，所有的請求應(yīng)通過HTTPS發(fā)送。

如果AMI需要與其他的AWS 云服務(wù)通信 (例如輪詢 Amazon SQS 或者從 Amazon S3中讀取數(shù)據(jù)), 一個典型錯誤是將AWS 憑據(jù)嵌入到AMI中，正確方法應(yīng)該是在發(fā)送前傳遞參數(shù)[17].

如果安全密鑰被破壞,應(yīng)該通過新的密鑰ID獲得新的安全密鑰。作為一個好的方式，建議在應(yīng)用程序架構(gòu)中采用密鑰輪換機(jī)制，讓可以定期使用它，或者偶爾(當(dāng)心懷不滿的雇員離開公司)，以確保受損密鑰不能持續(xù)工作。

另一種方式是采用 X.509 證書來研制特定的AWS服務(wù)。證書文件在base64-encoded DER證書主體中包含了公鑰，另一個文件包含了base64-encodedPKCS#8 私鑰。在aws.amazon.com 和 AWS Management Console 中，AWS支持多因素驗證。

在 IAM 中管理用戶權(quán)限

AWS IAM42 能夠AWS賬號內(nèi)管理多個用戶的權(quán)限。 一個用戶(在AWS賬號內(nèi))是訪問AWS云服務(wù)的唯一安全身份。IAM 消除了密碼和訪問密鑰的共享，可以方便的開通或禁止用戶訪問。

IAM是實現(xiàn)安全性的一個最佳實踐, 例如通過授權(quán)實現(xiàn)最低訪問權(quán)限，只有通過授權(quán)的用戶才能訪問AWS服務(wù)和資源。IAM 是默認(rèn)安全的，新用戶沒有被準(zhǔn)確授權(quán)的話無法訪問AWS服務(wù)。

IAM 原生集成了大多數(shù)的AWS 云服務(wù)。IAM的API不會變化，應(yīng)用和工具在權(quán)限變化時可以進(jìn)行運(yùn)行。應(yīng)用只需要在開始時為新用戶生成訪問密鑰。當(dāng)與其他AWS服務(wù)交互的時候，應(yīng)該最小化地使用 AWS的賬號憑據(jù)，這樣才能分享IAM帶來的好處。

應(yīng)用安全

安全組是網(wǎng)絡(luò)流量入口規(guī)則的集合，需要指定TCP 和 UDP 端口, ICMP 類型和代碼,以及源地址等,每個Amazon EC2實例都被一個或多個安全組所保護(hù)。安全組為運(yùn)行實例提供基本的類似防火墻保護(hù)。例如，隸屬應(yīng)用的實例有如下的安全組設(shè)置:

限制呼入流量的另一種方式是配置實例的軟件防火墻。Windows 實例有內(nèi)置的防火墻， Linux 實例使用 netfilter45 和 iptables.

隨著時間的推移，如果在軟件中發(fā)現(xiàn)錯誤，需要打補(bǔ)丁來修復(fù)，應(yīng)該保障下面的措施是應(yīng)用的安全最大化：

• 定期下載補(bǔ)丁從供應(yīng)商的網(wǎng)站并更新到AMI 中;
• 從重新部署新AMI實例和測試應(yīng)用程序，以確保補(bǔ)丁不破壞任何東西，同時確保最新的AMI部署到所有實例;
• 開發(fā)測試腳本定期地進(jìn)行自動化安全檢查;
• 確保第三方軟件配置為最安全設(shè)置
• 除非絕對必要，否則永遠(yuǎn)不要以root或管理員身份運(yùn)行的進(jìn)程

所有在云時代之前的標(biāo)準(zhǔn)安全實踐依然適用，例如采用良好的編碼習(xí)慣，隔離敏感數(shù)據(jù)等。

現(xiàn)在回想起來，云技術(shù)簡化了物理安全的復(fù)雜性，通過工具控制和相關(guān)特性可以確保應(yīng)用程序安全。

#p#

未來的研究方向

應(yīng)用不用關(guān)心物理硬件的時代并不遙遠(yuǎn)。作為一個架構(gòu)師，只需要管理抽象的計算，存儲和網(wǎng)絡(luò)資源，而不是物理服務(wù)器。即使底層物理硬件發(fā)生故障或被拆除或更換，應(yīng)用程序都將繼續(xù)運(yùn)行。應(yīng)用程序?qū)⑦m應(yīng)不斷變化的需求模式且瞬間自動調(diào)配資源，從而在所有時間達(dá)到最高的利用率水平。擴(kuò)展性，安全性，高可用性，容錯性，可測性和彈性都是應(yīng)用架構(gòu)的配置屬性，而且在平臺構(gòu)建時自動內(nèi)置了。

但是，我們還沒有到那樣的程度?，F(xiàn)在，可以通過文中的最佳實踐來建立在云計算中應(yīng)用來具備這些特質(zhì)?；谠朴嬎慵軜?gòu)的最佳實踐還在繼續(xù)發(fā)展，并作為研究人員，我們應(yīng)該不僅著眼于增強(qiáng)云計算的知識而且要關(guān)注工具構(gòu)建，技術(shù)和流程，這將更容易讓開發(fā)人員和架構(gòu)師把應(yīng)用程序遷移到云計算環(huán)境中。

結(jié)論

本文為云計算架構(gòu)師提供了設(shè)計高效云應(yīng)用程序的規(guī)范性指導(dǎo)。

通過專注于概念和最佳實踐，例如設(shè)計失敗，應(yīng)用程序組件解耦合，理解和實現(xiàn)彈性，彈性與并行結(jié)合，并在應(yīng)用程序架構(gòu)的各個層面整合安全，云計算架構(gòu)師可以了解到構(gòu)建高可擴(kuò)展的云應(yīng)用程序時必要的設(shè)計要素。

AWS云服務(wù)提供了高度可靠的按需付費的基礎(chǔ)設(shè)施。在AWS具體策略中突出可如何使用這些服務(wù)來設(shè)計云應(yīng)用。作為一名研究者，最好充分發(fā)揮這些商業(yè)服務(wù)的作用，站在巨人的肩膀上，進(jìn)一步增強(qiáng)基于云計算的創(chuàng)造。

參考資料

1. Amazon S3 Team, Best Practices for using Amazon S3, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1904, 2008-11-26

2. Amazon S3 Team, Amazon S3 Error Best Practices, http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ErrorBestPractices.html, 2006-03-01

3. Amazon SimpleDB Team, Query 201: Tips and Tricks for Amazon SimpleDB Query, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1232&categoryID=176, 2008-02-07

4. Amazon SimpleDB Team, Building for Performance and Reliability with Amazon SimpleDB, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1394&categoryID=176, 2008-04-11

5. Amazon SimpleDB Team, Query 101: Building Amazon SimpleDB Queries, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1231&categoryID=176, 2008-02-07

6. J. Varia, Cloud Architectures, http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf, 2007-07-01

7. Amazon Security Team, Overview of Security Processes, http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf, 2009-06-01

8. Amazon Web Services Team, Creating HIPAA-Compliant Medical Data Applications With AWS, http://awsmedia.s3.amazonaws.com/AWS_HIPAA_Whitepaper_Final.pdf, 2009-04-01

9. D. Obasanjo, Building Scalable Databases: Pros and Cons of Various Database Sharding Schemes, http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSchemes.aspx, 2009-01-16

10. D. Pritchett, Shard Lessons, http://www.addsimplicity.com/adding_simplicity_an_engi/2008/08/shard-lessons.html, 2008-08-24

11. J. Hamilton, On Designing and Deploying Internet-Scale Services, 2007, 21st Large Installation System Administration conference (LISA ‘O7), http://mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf

12. J. Dean and S. Ghemawat, MapReduce: Simplified data processing on large clusters2004-12-01, In Proc. of the 6th OSDI, http://labs.google.com/papers/mapreduce-osdi04.pdf

13. T. Schlossnagle, Scalable Internet Architectures, Sams Publishing , 2006-07-31,

14. M. Lurie, The Federation: Database Interoperability, http://www.ibm.com/developerworks/data/library/techarticle/0304lurie/0304lurie.html, 2003-04-23

15. E. Hammond, Escaping Restrictive/Untrusted Networks with OpenVPN on EC2, http://alestic.com/2009/05/openvpn-ec2, 2009-05-02

16. R. Bragg, The Encrypting File System, http://technet.microsoft.com/en-us/library/cc700811.aspx, 2009

17. S. Swidler, How to keep your AWS credentials on an EC2 instance securely, http://clouddevelopertips.blogspot.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html, 2009-08-31

18. Amazon SQS Team, Building Scalable, Reliable Amazon EC2 Applications with Amazon SQS, http://sqs-public-images.s3.amazonaws.com/Building_Scalabale_EC2_applications_with_SQS2.pdf, 2008

19. Microsoft Support Team, Best Practices For Encrypting File System (Windows), http://support.microsoft.com/kb/223316, 2009

20. Solaris Security Team, ZFS Encryption Project (OpenSolaris), http://www.opensolaris.org/os/project/zfs-crypto/, 2009-05-01

21. Amazon RDS Team, Amazon RDS Multi-AZ Deployments, http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/Concepts.DBInstance.html#Concepts.MultiAZ. 2010-05-15

22. Amazon SimpleDB Team, Amazon SimpleDB Consistency Enhancements http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3572 2010-02-24

博文出處：http://blog.csdn.net/wireless_com/article/details/43305701