譯者序

AWS用戶廣泛，產(chǎn)品線復(fù)雜，AWS發(fā)布的白皮書《Architecting for the Cloud-AWS Best Practices》介紹了常見場景下云架構(gòu)的最佳實踐，不僅對于使用AWS的用戶，對于廣大使用云的用戶都有參考意義，新鈦云服工程師特意翻譯了本白皮書，供廣大使用云的用戶參考。

本手冊分為兩部分

第一部分 傳統(tǒng)環(huán)境和云環(huán)境的差異

第二部分 云架構(gòu)設(shè)計原則

4. 設(shè)計原則

AWS 包含許多可應(yīng)用于各種用例的設(shè)計模式和體系結(jié)構(gòu)選項。AWS的一些關(guān)鍵設(shè)計原則包括可擴展性，可支配資源，自動化，用松耦合管理服務(wù)，以及靈活的數(shù)據(jù)存儲選項。

4.1 可擴展性

預(yù)計隨著時間的推移而增長的系統(tǒng)需要建立在可擴展的架構(gòu)之上。這樣的體系架構(gòu)可以支持用戶，流量或數(shù)據(jù)大小的增長，而不會降低性能。應(yīng)該以線性方式按比例提供資源，添加額外資源至少導(dǎo)致成比例增加提供額外負(fù)載的能力。增長應(yīng)引入規(guī)模經(jīng)濟，成本應(yīng)遵循從該系統(tǒng)產(chǎn)生商業(yè)價值的相同維度。雖然云計算提供幾乎無限的按需容量，但你的設(shè)計需要能夠無縫地利用這些資源。

通常有兩種擴展IT架構(gòu)的方法：縱向擴展和橫向擴展。

4.1.1 縱向擴展

縱向擴展通過增加單個資源的規(guī)模來實現(xiàn)，例如升級具有更大硬盤驅(qū)動器或更快CPU的服務(wù)器。使用Amazon EC2，你可以停止實例并將其調(diào)整為具有更多RAM，CPU，I/O或網(wǎng)絡(luò)功能的實例類型。這種縮放方式最終將達(dá)到極限，并且它并不總是具有成本效益或高度可用的方法。但是，它很容易實現(xiàn)，并且對于許多用例來說已經(jīng)足夠了，特別是在短期內(nèi)。

4.1.2 橫向擴展

通過增加資源數(shù)量來橫向擴展，例如向存儲陣列添加更多硬盤驅(qū)動器，或添加更多服務(wù)器以支持應(yīng)用程序。這是構(gòu)建利用云彈性的互聯(lián)網(wǎng)規(guī)模應(yīng)用程序的好方法。并非所有體系結(jié)構(gòu)都旨在將其工作負(fù)載分配給多個資源，因此讓我們檢視一些可能的情況。

1) 無狀態(tài)應(yīng)用

當(dāng)用戶或服務(wù)與應(yīng)用程序交互時，通常會執(zhí)行一系列形成會話的交互。會話是用戶在使用應(yīng)用程序時在請求之間保持不變的唯一數(shù)據(jù)。無狀態(tài)應(yīng)用程序是不需要先前交互知識，且不存儲會話信息的應(yīng)用程序。例如，給定相同輸入，向任何最終用戶提供相同響應(yīng)的應(yīng)用程序是無狀態(tài)應(yīng)用程序。無狀態(tài)應(yīng)用程序可以橫向擴展，因為任何可用的計算資源(例如EC2實例和AWS Lambda函數(shù))都可以為任何請求提供服務(wù)。如果沒有存儲會話數(shù)據(jù)，可以根據(jù)需要添加更多計算資源。當(dāng)不再需要該容量時，可以在運行任務(wù)耗盡后安全地終止這些單獨的資源。這些資源不需要知道同伴的存在，所需要的只是將工作負(fù)載分配給它們的方法。

2) 將負(fù)載分配給多個節(jié)點

要將工作負(fù)載分配到環(huán)境中的多個節(jié)點，可以選擇推模型或拉模型。

使用推模型，可以使用Elastic Load Balancing(ELB)來分配工作負(fù)載。ELB跨多個EC2實例路由傳入的應(yīng)用程序請求。在路由流量時，網(wǎng)絡(luò)負(fù)載均衡器在開放系統(tǒng)互連(OSI)模型的第4層運行，以處理每秒數(shù)百萬個請求。通過采用基于容器的服務(wù)，還可以使用應(yīng)用程序負(fù)載均衡器。應(yīng)用程序負(fù)載均衡器提供OSI模型的第7層，并支持基于應(yīng)用程序流量的基于內(nèi)容的請求路由。或者，可以使用Amazon Route 53實施DNS輪詢。在這種情況下，DNS響應(yīng)以循環(huán)方式從有效主機列表中返回IP地址。雖然易于實施，但這種方法并不總能很好地適應(yīng)云計算的彈性。這是因為即使你可以為DNS記錄設(shè)置低生存時間(TTL)值，緩存DNS解析器也不在Amazon Route 53的控制范圍內(nèi)，并且可能并不總是遵循你的設(shè)置。

可以為異步，事件驅(qū)動的工作負(fù)載實現(xiàn)拉模型，而不是負(fù)載平衡解決方案。在拉模型中，需要執(zhí)行的任務(wù)或需要處理的數(shù)據(jù)可以使用Amazon Simple Queue Service(Amazon SQS)作為消息存儲在隊列中，也可以作為流數(shù)據(jù)解決方案存儲

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

3) 無狀態(tài)組件

實際上，大多數(shù)應(yīng)用程序都維護某種狀態(tài)信息。例如，Web應(yīng)用程序需要跟蹤用戶是否已登錄，以便可以基于先前的操作呈現(xiàn)個性化內(nèi)容。自動化的多步驟過程還需要跟蹤先前的活動，以確定其下一步應(yīng)該是什么。仍然可以通過不在本地文件系統(tǒng)中存儲需要多于一個請求的任何內(nèi)容，來使這些體系結(jié)構(gòu)的一部分無狀態(tài)。

例如，Web應(yīng)用程序可以使用HTTP cookie在Web客戶端緩存中存儲會話信息(如購物車項目)。瀏覽器在每個后續(xù)請求時將該信息傳遞回服務(wù)器，以便應(yīng)用程序不需要存儲它。但是，這種方法有兩個缺點。首先，HTTP cookie的內(nèi)容可能會在客戶端被篡改，因此你應(yīng)始終將其視為必須經(jīng)過驗證的不可信數(shù)據(jù)。其次，HTTP cookie隨每個請求一起傳輸，這意味著你應(yīng)該將其大小保持在最小，以避免不必要的延遲。

考慮僅在HTTP cookie中存儲唯一的會話標(biāo)識符，并在服務(wù)器端存儲更詳細(xì)的用戶會話信息。大多數(shù)編程平臺都提供以這種方式工作的本機會話管理機制。但是，默認(rèn)情況下，用戶會話信息通常存儲在本地文件系統(tǒng)中，從而形成有狀態(tài)架構(gòu)。此問題的常見解決方案是將此信息存儲在數(shù)據(jù)庫中。Amazon DynamoDB是一個很好的選擇，因為它具有可擴展性，高可用性和耐用性特征。對于許多平臺，有一些開源替代庫，允許你在Amazon DynamoDB中存儲本機會話。

其他方案需要存儲較大的文件(例如用戶上載和批處理的中間結(jié)果)。通過將這些文件放在共享存儲層(如Amazon Simple Storage Service，Amazon S3；或Amazon Elastic File System，Amazon EFS))中，可以避免引入有狀態(tài)組件。

最后，復(fù)雜的多步驟工作流是另一個必須跟蹤每個執(zhí)行的當(dāng)前狀態(tài)的示例。可以使用AWS步驟功能集中存儲執(zhí)行歷史記錄，并使這些工作負(fù)載無狀態(tài)。

4) 有狀態(tài)組件

不可避免地，你的架構(gòu)層將不會變成無狀態(tài)組件。根據(jù)定義，數(shù)據(jù)庫是有狀態(tài)的。有關(guān)更多信息，請參閱后面的“數(shù)據(jù)庫章節(jié)"。此外，許多遺留應(yīng)用程序設(shè)計為依靠本地計算資源在單個服務(wù)器上運行。其它用例包括可能需要客戶端設(shè)備長時間保持與特定服務(wù)器的連接。例如，實時多人游戲必須以非常低的延遲為多個玩家提供一致的游戲世界視圖。在非分布式實現(xiàn)中實現(xiàn)這一點要簡單得多，其中參與者連接到同一服務(wù)器。

仍然可以通過將負(fù)載分配到具有會話親緣關(guān)系的多個節(jié)點來水平擴展這些組件。在此模型中，將會話的所有事務(wù)綁定到特定的計算資源。但是，這個模型確實有一些局限性。現(xiàn)有會話不會直接受益于新啟動的計算節(jié)點的引入。更重要的是，無法保證會話親和力。例如，當(dāng)節(jié)點終止或變得不可用時，綁定到該節(jié)點的用戶將斷開連接并遇到特定于會話的數(shù)據(jù)丟失，這些數(shù)據(jù)不會存儲在共享資源，如Amazon S3，Amazon EFS或a數(shù)據(jù)庫。

5) 實現(xiàn)會話親和性

對于HTTP和HTTPS流量，你可以使用應(yīng)用程序負(fù)載均衡器的粘性會話功能，將用戶的會話綁定到特定實例。使用此功能，應(yīng)用程序負(fù)載均衡器將嘗試在該持續(xù)時間內(nèi)為該用戶使用相同的服務(wù)器會議。另一個選項，如果你控制在客戶端上運行的代碼，是使用客戶端負(fù)載平衡。這會增加額外的復(fù)雜性，但在負(fù)載均衡器不符合你的要求的情況下非常有用。例如，你可能正在使用ELB不支持的協(xié)議，或者你可能需要完全控制如何將用戶分配給服務(wù)器(例如，在游戲場景中，可能需要確保游戲參與者匹配并連接到相同的服務(wù)器)。在此模型中，客戶端需要一種方法來發(fā)現(xiàn)有效的服務(wù)器端點以直接連接。可以使用DNS，或者你可以構(gòu)建一個簡單的發(fā)現(xiàn)API，以便將該信息提供給客戶端上運行的軟件。在沒有負(fù)載均衡器的情況下，還需要在客戶端實現(xiàn)健康檢查機制。應(yīng)該設(shè)計客戶端邏輯，以便在檢測到服務(wù)器不可用時，設(shè)備重新連接到另一臺服務(wù)器，而對應(yīng)用程序幾乎沒有中斷。

6) 分布式處理

涉及處理大量數(shù)據(jù)的用例，無法及時處理單個計算資源的任何事物，需要采用分布式處理方法。通過將任務(wù)及其數(shù)據(jù)劃分為許多小的工作片段，可以跨一組計算資源并行執(zhí)行它們。

7)實施分布式處理

通過使用AWS Batch，AWS Glue和Apache Hadoop等分布式數(shù)據(jù)處理引擎，可以水平擴展脫機批處理作業(yè)。在AWS上，可以使用Amazon EMR在一組EC2實例之上運行Hadoop工作負(fù)載，而無需運維復(fù)雜性。對于流數(shù)據(jù)的實時處理，Amazon Kinesis將數(shù)據(jù)分成多個分片，然后由多個Amazon EC2或AWS Lambda資源使用，以實現(xiàn)可擴展性。

有關(guān)這些類型工作負(fù)載的更多信息，請參閱《Big Data Analytics Options on AWS 》和《Core Tenets of IoT》白皮書。

4.2 一次性資源而不是固有服務(wù)器

在傳統(tǒng)的基礎(chǔ)架構(gòu)環(huán)境中，由于引入新硬件的前期成本和前置時間，必須使用固定資源。這推動了諸如手動登錄服務(wù)器以配置軟件或修復(fù)問題，硬編碼IP地址以及按順序運行測試或處理作業(yè)等實踐。

在為AWS設(shè)計時，可以利用云計算的動態(tài)配置特性。可以將服務(wù)器和其他組件視為臨時資源。可以根據(jù)需要啟動任意數(shù)量實例，并且只在需要時使用它們。

長期運行的服務(wù)器的另一個問題是配置偏差。隨時間推移應(yīng)用的更改和軟件修補程序可能會導(dǎo)致跨不同環(huán)境的未經(jīng)測試和異構(gòu)配置。可以使用不可變的基礎(chǔ)架構(gòu)結(jié)構(gòu)模型模式解決此問題。使用這種方法方式，服務(wù)器一旦啟動永遠(yuǎn)不會更新。相反，當(dāng)出現(xiàn)問題或需要更新時，問題服務(wù)器將替換為具有最新配置的新服務(wù)器。這使資源始終處于一致(和測試)狀態(tài)，并使回滾更容易執(zhí)行。使用無狀態(tài)體系結(jié)構(gòu)更容易支持這一點。

4.2.1 實例化計算資源

無論是部署新環(huán)境進(jìn)行測試，還是增加現(xiàn)有系統(tǒng)的容量來應(yīng)對額外負(fù)載，你都不希望使用其配置和代碼手動設(shè)置新資源。重要的是，你要使其成為一個自動化且可重復(fù)的過程，以避免較長的交付周期，并且不會出現(xiàn)人為錯誤。有幾種方法可以實現(xiàn)這一目標(biāo)。

1)引導(dǎo)

啟動AWS資源(如EC2實例或AmazonRelational Database Service(Amazon RDS)數(shù)據(jù)庫實例)時，將啟動默認(rèn)配置。然后，可以執(zhí)行自動引導(dǎo)操作，這些操作是安裝軟件或復(fù)制數(shù)據(jù)以將該資源帶入特定狀態(tài)的腳本。可以參數(shù)化在不同環(huán)境(例如生產(chǎn)或測試)之間變化的配置詳細(xì)信息，以便可以重復(fù)使用相同的腳本而無需進(jìn)行任何修改。

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

2)黃金鏡像

某些AWS資源類型(例如EC2實例，AmazonRDS數(shù)據(jù)庫實例和Amazon Elastic Block Store，Amazon EBS)可以從黃金鏡像啟動，黃金鏡像是該資源的特定狀態(tài)的快照。與引導(dǎo)方法相比，黃金鏡像可以縮短啟動時間并消除對配置服務(wù)或第三方存儲庫的依賴性。這在自動擴展環(huán)境中非常重要，在這種環(huán)境中，你希望能夠快速可靠地啟動其他資源，以響應(yīng)需求變化。

可以自定義EC2實例，然后通過創(chuàng)建Amazon Machine Image(AMI)來保存其配置。可以根據(jù)需要從AMI啟動任意數(shù)量的實例，并且它們都將包括這些自定義項。每次要更改配置時，都必須創(chuàng)建一個新的黃金鏡像，因此必須具有版本控制約定來管理你的黃金鏡像。建議你使用腳本為你用于創(chuàng)建的EC2實例創(chuàng)建引導(dǎo)程序的AMI。這為你提供了一種靈活的方法來測試和修改這些鏡像。

或者，如果你具有現(xiàn)有的本地虛擬化環(huán)境，則可以使用AWS的VM導(dǎo)入/導(dǎo)出將各種虛擬化格式轉(zhuǎn)換為AMI。你還可以查找和使用AWS或AWS中的第三方提供的預(yù)封裝共享AMI。

雖然啟動新EC2實例時最常使用黃金鏡像，但它們也可以應(yīng)用于Amazon RDS數(shù)據(jù)庫實例或Amazon EBS卷等資源。例如，當(dāng)啟動新的測試環(huán)境時，你可能希望通過從特定的Amazon RDS快照實例化數(shù)據(jù)庫來預(yù)填充其數(shù)據(jù)庫，而不是從冗長的SQL腳本中導(dǎo)入數(shù)據(jù)。

3)容器

開發(fā)人員喜歡的另一個選擇是Docker，一種開源技術(shù)，允許你在軟件容器內(nèi)構(gòu)建和部署分布式應(yīng)用程序。Docker允許你將一個軟件封裝在Docker鏡像中，這是一個軟件開發(fā)的標(biāo)準(zhǔn)化單元，包含軟件運行所需的所有內(nèi)容：代碼，運行時，系統(tǒng)工具，系統(tǒng)庫等。AWS Elastic Beanstalk，Amazon ElasticContainer 服務(wù)(Amazon ECS)和AWSFargate允許你跨EC2實例集群部署和管理多個容器。你可以構(gòu)建黃金Docker鏡像并使用ECS容器注冊表來管理它們。

另一種容器環(huán)境是Kubernetes和Kubernetes的亞馬遜彈性容器服務(wù)(Amazon EKS)。借助Kubernetes和Amazon EKS，你可以輕松部署，管理和擴展容器化應(yīng)用程序。

4)混合

你還可以使用這兩種方法的組合：配置的某些部分在黃金鏡像中捕獲，而其他部分則通過引導(dǎo)操作動態(tài)配置。

不經(jīng)常更改或引入外部依賴項的項目通常是你的黃金鏡像的一部分。一個好的候選者的例子是你的Web服務(wù)器軟件，否則每次啟動實例時都必須由第三方存儲庫下載。

可以通過引導(dǎo)操作動態(tài)設(shè)置在不同環(huán)境之間經(jīng)常更改或不同的項目。例如，如果要經(jīng)常部署應(yīng)用程序的新版本，則為每個應(yīng)用程序版本創(chuàng)建新的AMI可能不切實際。你也不希望將數(shù)據(jù)庫主機名配置硬編碼到AMI，因為測試和生產(chǎn)環(huán)境之間會有所不同。用戶數(shù)據(jù)或標(biāo)簽允許你使用可在啟動時修改的更通用的AMI。例如，如果你為各種小型企業(yè)運行Web服務(wù)器，則它們都可以使用相同的AMI，并從啟動時在用戶數(shù)據(jù)中指定的S3存儲桶位置檢索其內(nèi)容。

AWS Elastic Beanstalk遵循混合模型。它提供預(yù)配置的運行時環(huán)境，每個環(huán)境都是從其自己的AMI11啟動的，但允許你通過ebextensions配置文件運行引導(dǎo)操作，并配置環(huán)境變量以參數(shù)化環(huán)境差異。

4.2.2 基礎(chǔ)架構(gòu)即代碼

我們討論的原則的應(yīng)用不必限于單個的資源水平。由于AWS資源是可編程的，因此你可以應(yīng)用軟件開發(fā)中的技術(shù)，實踐和工具，使你的整個基礎(chǔ)架構(gòu)可重用，可維護，可擴展和可測試。

AWS CloudFormation模板為你提供了一種簡單的方法來創(chuàng)建和管理相關(guān)AWS資源的集合，并以有序和可預(yù)測的方式提供和更新它們。你可以描述運行應(yīng)用程序所需的AWS資源，以及任何關(guān)聯(lián)的依賴項或運行時參數(shù)。你的CloudFormation模板可以與你的版本控制存儲庫中的應(yīng)用程序一起使用，這樣你就可以重用架構(gòu)并可靠地克隆生產(chǎn)環(huán)境以進(jìn)行測試。

4.3 自動化

在傳統(tǒng)的IT基礎(chǔ)架構(gòu)中，你通常必須手動對各種事件做出反應(yīng)。在AWS上部署時，你可以進(jìn)行自動化。

為了提高系統(tǒng)的穩(wěn)定性和組織的效率，考慮將一種或多種這類自動化引入你的應(yīng)用程序體系結(jié)構(gòu)，以確保更高的彈性，可伸縮性和性能。

4.3.1 無服務(wù)器管理和部署

采用無服務(wù)器模式時，操作重點是部署自動化流水線。AWS管理基礎(chǔ)服務(wù)，規(guī)模和可用性。AWS CodePipeline，AWS CodeBuild和AWS CodeDeploy支持這些流程部署的自動化。

4.3.2 基礎(chǔ)架構(gòu)管理和部署

AWS Elastic Beanstalk：你可以使用此服務(wù)在熟悉的服務(wù)器(如Apache，Nginx，Passenger和服務(wù)器)上部署和擴展使用Java，.NET，PHP，Node.js，Python，Ruby，Go和Docker開發(fā)的Web應(yīng)用程序和服務(wù)。IIS開發(fā)人員可以簡單地上傳他們的應(yīng)用程序代碼，該服務(wù)自動處理所有細(xì)節(jié)，例如資源配置，負(fù)載平衡，自動擴展和監(jiān)視。

Amazon EC2自動恢復(fù)：你可以創(chuàng)建監(jiān)控EC2實例的Amazon CloudWatch警報，并在其受損時自動恢復(fù)。恢復(fù)的實例與原始實例相同，包括實例ID，私有IP地址，彈性IP地址，和所有實例元數(shù)據(jù)。但是，此功能僅適用于適用的實例配置。有關(guān)這些前提條件的最新說明，請參閱Amazon EC2文檔。此外，在實例恢復(fù)期間，實例將通過實例重新引導(dǎo)進(jìn)行遷移，并且內(nèi)存中的所有數(shù)據(jù)都將丟失。

AWS Systems Manager：你可以自動收集軟件清單，應(yīng)用操作系統(tǒng)補丁，創(chuàng)建系統(tǒng)鏡像以配置Windows和Linux操作系統(tǒng)，以及執(zhí)行任意命令。提供這些服務(wù)簡化了操作模型并確保了最佳的環(huán)境配置。

Auto Scaling：你可以根據(jù)你定義的條件自動維護應(yīng)用程序可用性，并自動擴展Amazon EC2，Amazon DynamoDB，Amazon ECS，適用于Kubernetes的Amazon Elastic Container Service，(Amazon EKS)容量。你可以使用Auto Scaling幫助確保跨多個可用區(qū)運行所需數(shù)量的健康EC2實例。Auto Scaling還可以在需求峰值期間自動增加EC2實例的數(shù)量，在不太繁忙的時期保持性能并降低容量以優(yōu)化成本。

4.3.3 警報和事件

Amazon CloudWatch警報：你可以創(chuàng)建CloudWatch警報，當(dāng)特定指標(biāo)超過指定閾值達(dá)指定數(shù)量的時段時，該警報會發(fā)送AmazonSimple Notification Service(Amazon SNS)消息。這些Amazon SNS消息可以自動啟動執(zhí)行訂閱的Lambda函數(shù)，將通知消息排入Amazon SQS隊列，或者對HTTP或HTTPS端點執(zhí)行POST請求。

Amazon CloudWatchEvents：提供近乎實時的系統(tǒng)事件流，描述AWS資源中的變更.使用簡單規(guī)則，你可以將每種類型的事件路由到一個或多個目標(biāo)，例如Lambda函數(shù)，Kinesis流和SNS主題。

AWS Lambda預(yù)定事件：你可以創(chuàng)建Lambda函數(shù)并配置AWS Lambda以定期執(zhí)行它。

AWS WAF安全自動化：AWS WAF是一種Web應(yīng)用程序防火墻，使你能夠創(chuàng)建自定義的特定于應(yīng)用程序的規(guī)則，以阻止可能影響應(yīng)用程序可用性，危及安全性或消耗過多資源的常見攻擊模式。你可以通過API完全管理AWS WAF，從而簡化安全自動化，實現(xiàn)快速規(guī)則傳播和快速事件響應(yīng)。

4.4 松耦合

隨著應(yīng)用程序復(fù)雜性的增加，IT系統(tǒng)的理想屬性是可以將其分解為更小，松耦合的組件。這意味著IT系統(tǒng)的設(shè)計應(yīng)該能夠減少相互依賴性，一個組件中的更改或故障不應(yīng)該級聯(lián)到其他組件。

4.4.1 定義明確的接口

減少系統(tǒng)中相互依賴性的一種方法是允許各種組件僅通過特定的，與技術(shù)無關(guān)的接口(例如RESTful API)相互交互。通過這種方式，隱藏了技術(shù)實現(xiàn)細(xì)節(jié)，以便團隊可以修改底層實現(xiàn)而不影響其他組件。只要這些接口保持向后兼容性，差異組件的部署就會分離。這種粒度設(shè)計模式通常被稱為微服務(wù)架構(gòu)。

Amazon API Gateway是一種完全托管的服務(wù)，使開發(fā)人員可以輕松地以任何規(guī)模創(chuàng)建，發(fā)布，維護，監(jiān)控和保護API。它處理接受和處理多達(dá)數(shù)十萬個并發(fā)API調(diào)用所涉及的所有任務(wù)，包括流量管理，授權(quán)和訪問控制，監(jiān)控和API版本管理。

4.4.2 服務(wù)發(fā)現(xiàn)

部署為一組較小服務(wù)的應(yīng)用程序取決于這些服務(wù)相互交互的能力。因為每個服務(wù)都可以跨多個計算資源運行，所以需要有一種方法來解決每個服務(wù)。例如，在傳統(tǒng)基礎(chǔ)結(jié)構(gòu)中，如果你的前端Web服務(wù)需要與后端Web服務(wù)連接，則可以對運行此服務(wù)的計算資源的IP地址進(jìn)行硬編碼。雖然這種方法仍然適用于云計算，但如果這些服務(wù)是松耦合的，那么它們應(yīng)該能夠在不事先了解其網(wǎng)絡(luò)拓?fù)浼?xì)節(jié)的情況下使用。除了隱藏復(fù)雜性之外，這還允許基礎(chǔ)架構(gòu)細(xì)節(jié)隨時更改。如果你想利用云計算的彈性，可以在任何時間點啟動或終止新資源，那么松耦合是一個至關(guān)重要的因素。為了實現(xiàn)這一目標(biāo)，你需要一些實現(xiàn)服務(wù)發(fā)現(xiàn)的方法。

實施服務(wù)發(fā)現(xiàn)

對于Amazon EC2托管的服務(wù)，實現(xiàn)服務(wù)發(fā)現(xiàn)的一種簡單方法是通過Elastic LoadBalancing(ELB)。由于每個負(fù)載均衡器都有自己的主機名，因此你可以通過穩(wěn)定的endpoint使用服務(wù)。這可以與DNS和私有Amazon Route 53區(qū)域結(jié)合使用，以便可以隨時抽象和修改特定負(fù)載均衡器的endpoint。

另一種選擇是使用服務(wù)注冊和發(fā)現(xiàn)方法來允許檢索任何服務(wù)的endpoint IP地址和端口號。由于服務(wù)發(fā)現(xiàn)成為組件之間的粘合劑，因此高度可用且可靠性非常重要。如果未使用負(fù)載平衡器，則還應(yīng)該進(jìn)行服務(wù)發(fā)現(xiàn)允許健康檢查等選項。Amazon Route 53支持自動命名，以便更輕松地為微服務(wù)配置實例。自動命名允許你根據(jù)定義的配置自動創(chuàng)建DNS記錄。其他示例實現(xiàn)包括使用標(biāo)簽組合的自定義解決方案，高可用性數(shù)據(jù)庫，調(diào)用AWSAPI的自定義腳本，或Netflix Eureka，AirbnbSynapse或HashiCorp Consul等開源工具。

4.4.3 異步集成

異步集成是服務(wù)之間松耦合的另一種形式。此模型適用于任何不需要立即響應(yīng)的交互，以及已經(jīng)注冊請求的確認(rèn)就足夠了。它涉及一個生成事件的組件和另一個消耗它們的組件。這兩個組件不通過直接的點對點交互進(jìn)行集成，而是通過中間持久存儲層進(jìn)行集成，例如SQS隊列或流式數(shù)據(jù)平臺(如Amazon Kinesis)，級聯(lián)Lambda事件，AWS步驟功能或AmazonSimple Workflow服務(wù)。

圖1：緊耦合和松耦合

這種方法將兩個組件分離，并引入了額外的彈性。因此，例如，如果正在從隊列中讀取消息的進(jìn)程失敗，則仍可以將消息添加到隊列中并在系統(tǒng)恢復(fù)時進(jìn)行處理。它還允許你保護不太可擴展的后端服務(wù)免受前端尖峰的攻擊，并找到正確的成本和處理滯后之間的權(quán)衡。例如，你可以決定不需要擴展數(shù)據(jù)庫以適應(yīng)偶爾的寫入查詢峰值，只要你最終以一些延遲異步處理這些查詢。最后，通過從交互式請求路徑中刪除慢速操作，你還可以改善最終用戶體驗。

異步集成的示例包括：

• 前端應(yīng)用程序?qū)⒆鳂I(yè)插入隊列系統(tǒng)(如Amazon SQS)。后端系統(tǒng)檢索這些作業(yè)并按照自己的進(jìn)度處理它們。
• API生成事件并將其推送到Kinesis流中。后端應(yīng)用程序批量處理這些事件以創(chuàng)建存儲在數(shù)據(jù)庫中的聚合時間序列數(shù)據(jù)。
• 多個異構(gòu)系統(tǒng)使用AWS步驟函數(shù)來傳達(dá)它們之間的工作流，而無需直接相互交互。
• Lambda函數(shù)可以使用來自各種AWS源的事件，例如Amazon DynamoDB更新流和Amazon S3事件通知。你不必?fù)?dān)心實現(xiàn)排隊或其他異步集成方法，因為Lambda會為你處理此問題。

4.4.4 分布式系統(tǒng)最佳實踐

增加松耦合的另一種方法是構(gòu)建以優(yōu)雅方式處理組件故障的應(yīng)用程序。你可以確定減少對最終用戶的影響的方法，并提高你在脫機過程中取得進(jìn)展的能力，即使在某些組件發(fā)生故障時也是如此。

實踐中優(yōu)雅的應(yīng)對失敗

失敗的請求可以使用指數(shù)退避和抖動策略重試，也可以存儲在隊列中以供以后處理。對于前端接口，可以提供替代或緩存的內(nèi)容，而不是完全失敗，例如，你的數(shù)據(jù)庫服務(wù)器變得不可用。Amazon Route 53 DNS故障轉(zhuǎn)移功能還使你能夠監(jiān)控你的網(wǎng)站，并在主站點不可用時自動將訪問者路由到備份站點。你可以將備份站點作為Amazon S3上的靜態(tài)網(wǎng)站托管，也可以作為單獨的動態(tài)環(huán)境托管。

4.4.5 服務(wù)，而不是服務(wù)器

開發(fā)，管理和運維應(yīng)用程序，尤其是大規(guī)模應(yīng)用程序，需要各種各樣的底層技術(shù)組件。對于傳統(tǒng)的IT基礎(chǔ)架構(gòu)，公司必須構(gòu)建和運行所有這些組件。

AWS提供廣泛的計算，存儲，數(shù)據(jù)庫，分析，應(yīng)用程序和部署服務(wù)，可幫助組織更快地移動并降低IT成本。

不利用這種廣度的架構(gòu)(例如，如果它們僅使用AmazonEC2)可能無法充分利用云計算，并且可能錯失了提高開發(fā)人員生產(chǎn)力和運營效率的機會。

4.4.5.1 管理服務(wù)

AWS托管服務(wù)提供開發(fā)人員可以使用的構(gòu)建塊來為其應(yīng)用程序供電。這些托管服務(wù)包括數(shù)據(jù)庫，機器學(xué)習(xí)，分析，排隊，搜索，電子郵件，通知等。例如，使用Amazon SQS，你可以減輕運維和擴展高可用性消息傳遞群集的管理負(fù)擔(dān)，同時僅為你使用的內(nèi)容支付低價。Amazon SQS本身也具有可擴展性和可靠性。這同樣適用于Amazon S3，它使你可以根據(jù)需要存儲盡可能多的數(shù)據(jù)，并在需要時訪問它，而無需考慮容量，硬盤配置，復(fù)制和其他相關(guān)問題。

為你的應(yīng)用程序提供支持的托管服務(wù)的其他示例包括：

• 用于內(nèi)容交付的AmazonCloudFront
• 用于負(fù)載平衡的ELB
• 用于NoSQL數(shù)據(jù)庫的Amazon DynamoDB
• 用于搜索工作負(fù)載的AmazonCloudSearch
• 用于視頻編碼的Amazon ElasticTranscoder
• 用于發(fā)送和接收電子郵件的AmazonSimple Email Service(Amazon SES)

4.4.5.2 無服務(wù)器計算架構(gòu)

無服務(wù)器計算架構(gòu)可以降低運行應(yīng)用程序的操作復(fù)雜性。無需管理任何服務(wù)器基礎(chǔ)架構(gòu)，就可以為移動，Web，分析，CDN業(yè)務(wù)邏輯和物聯(lián)網(wǎng)構(gòu)建事件驅(qū)動和同步服務(wù)。這些體系結(jié)構(gòu)可以降低成本，因為你無需管理或支付未充分利用的服務(wù)器，也無需配置冗余基礎(chǔ)架構(gòu)來實現(xiàn)高可用性。

例如，你可以將代碼上載到AWS Lambda計算服務(wù)，并且該服務(wù)可以使用AWS基礎(chǔ)結(jié)構(gòu)代表你運行代碼。使用AWS Lambda，你需要為代碼執(zhí)行的每100毫秒以及觸發(fā)代碼的次數(shù)付費。通過使用Amazon API Gateway，你可以開發(fā)由AWS Lambda支持的幾乎無限可擴展的同步API。與Amazon S3結(jié)合使用以提供靜態(tài)內(nèi)容資產(chǎn)時，此模式可以提供完整的Web應(yīng)用程序。

在移動和Web應(yīng)用程序方面，你可以使用Amazon Cognito，這樣你就無需管理后端解決方案來處理用戶身份驗證，網(wǎng)絡(luò)狀態(tài)，存儲和同步。Amazon Cognito為你的用戶生成唯一標(biāo)識符。

可以在訪問策略中引用這些標(biāo)識符，以基于每個用戶啟用或限制對其他AWS資源的訪問。Amazon Cognito為你的用戶提供臨時AWS憑證，允許設(shè)備上運行的移動應(yīng)用程序直接與受AWS身份和訪問管理(IAM)保護的AWS服務(wù)進(jìn)行交互。例如，使用IAM，你可以將對S3存儲桶中的文件夾的訪問權(quán)限限制為特定的最終用戶。

對于物聯(lián)網(wǎng)應(yīng)用，組織傳統(tǒng)上必須配置，操作，擴展和維護自己的服務(wù)器作為設(shè)備網(wǎng)關(guān)，以處理連接設(shè)備與其服務(wù)之間的通信。AWS IoT提供完全受管理的設(shè)備網(wǎng)關(guān)，可根據(jù)你的使用情況自動擴展，無需任何操作開銷。

無服務(wù)器計算架構(gòu)還使得在邊緣計算運行響應(yīng)式服務(wù)成為可能。

說明：

本文由新鈦云服運維工程師傅雨斌翻譯，新鈦云服擁有八名認(rèn)證的AWS工程師，在AWS使用和維護方面擁有豐富的經(jīng)驗，已經(jīng)為多家用戶提供AWS上云支持。

原文鏈接：

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

總結(jié)

以上是生活随笔為你收集整理的详细设计 存储分配_万字长文：云架构设计原则（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。