# 使用 Amazon 服務以 100 美元的價格構建無限可擴展的基礎架構 > 原文： [http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html](http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html) 您是否真的可以使用亞馬遜的存儲，網格和排隊服務平臺以不到 100 美元的價格創建無限擴展的基礎架構？ 看起來如此，至少對于正確的應用而言。 亞馬遜將重點介紹了使用核心外部服務來構建下一代網站的“自帶滾動式”與“按點連接”方法的未來之戰。 他們的論點很強烈。 使用 Amazon 的平臺，您可以快速構建基礎架構，否則這些基礎架構將需要花費很長的時間才能實現，要創造大量的資金，并且需要大量的人來實施和維護。 但是，亞馬遜不提供 SLA，因此您可以將皇冠上的寶石與您真正信任嗎？ Facebook 最近以一套更全面的服務超越了亞馬遜的愿景。 未來的戰斗正在進行中。 網站：http：//aws.amazon.com/ ## 信息來源 * [幻燈片：構建高度可擴展的 Web 應用程序](http://www.slideshare.net/iwmw/building-highly-scalable-web-applications)* [播客：技術：亞馬遜網絡服務](http://www.itconversations.com/shows/detail1728.html)* [亞馬遜服務主頁](http://aws.amazon.com/)。 ## 平臺 * Amazon ECS（電子商務服務）* Amazon S3（簡單存儲服務）* Amazon SQS（簡單排隊服務）* Amazon EC2（網格服務）* 亞馬遜網絡搜索服務* 亞馬遜彈性付款服務（Amazon FPS）* REST and SOAP Service Interfaces ## 里面有什么？ ### 為什么要使用外部服務？ * Amazon 的服務取代了應用程序堆棧中的盒子，電線和磁盤驅動器。* 亞馬遜花了十年時間和超過 10 億美元開發了世界一流的 Web 服務，每天都有數百萬的客戶使用。 也許您可以利用自己的網站體驗？* 關注客戶。 如果 Web 開發不是要提供客戶價值，則為 70％。 這是關于建立和管理數據中心的。 您最好將精力花在客戶身上，而不是浪費精力。* 更快上市。 縮放很難。 當您專注于增加用戶價值時，讓其他人擔心 。* 針對峰值負載進行設計非常昂貴。 因此，將固定成本變成可變成本。 假設您要處理來自 slashdot 或 digg 的高流量，或者您有很高的季節性需求，那么擁有適當的基礎結構來處理這些負載是一筆高固定成本。 您可以在其他地方更好地使用這筆錢。 創建一個可以自動和 臨時擴展資源以應對高峰需求的基礎架構是很有意義的。* 高可靠性和可用性。 專用服務可能比您可以創建的服務更可靠。 它說“可能”，因為亞馬遜未提供 SLA，因此您將無法獲得任何保證。 這個想法是，亞馬遜足夠便宜且可靠，因此很少有故障是可以接受的。 此外，SLA 通常會在出現問題時退還一些錢，它們 并不能真正保證任何事情。* 這是便宜的 CDN。 亞馬遜的存儲網絡可以服務于相對便宜的內容交付網絡。 在 [減少您的網站的帶寬使用情況](http://www.codinghorror.com/blog/archives/000807.html)中討論了此選項。 這個想法是，僅經常下載一個簡單的 [favicon.ico](http://www.hanselman.com/blog/FavIconicoCanBeABandwidthHog.aspx) 文件就可以使用很大一部分帶寬。 使用$ 3 /月的 S3 將 90％的帶寬卸載到外部主機是一個不錯的選擇。 但是，沒有 SLA 的 S3 不能被認為是正確的 CDN。 ### 亞馬遜 ECS（電子商務服務） * 該服務公開了 Amazon 的產品數據和電子商務功能： 有關所有 Amazon.com 產品的詳細產品信息，訪問產品圖像，與產品相關的所有客戶評論等。* 亞馬遜產品定價過高。* 我發現這項服務令人失望。 如果您想在 Amazon 之上建立商店，這似乎很棒，但是我沒有找到將自己的產品添加到商店的方法，因此我認為它通常沒有用。 ### Amazon S3（簡單存儲服務） * 該服務將數據存儲在 Amazon 的存儲網絡中。* 每個 GPB 每月$ .15 的存儲空間* $ .01（1000 至 10000 個請求）。* 每 GB 數據傳輸$ .10-$ .17。* 服務是：快速，可靠，可擴展，冗余，分散。* 您可以具有每個對象的 URL。 這意味著您可以直接使用 URL 引用圖像或其他文件，因此可以在網頁中使用。* 典型用途：CDN 和備份存儲。* 存儲分配到多個位置，因此您可以進行一定程度的地理分布。 ### Amazon SQS（簡單排隊服務） * 此服務提供用于存儲消息的 Internet 規模排隊服務。 分布式參與者將工作放在隊列中，而將工作從隊列中移出。* 每 1000 條郵件$ .10。* 每 GB 數據傳輸$ .10-$ .18。* 該服務是：可擴展，彈性，可靠，簡單，安全。* 典型用途：集中式工作隊列。 將作業放在隊列中，不同的參與者可以彈出隊列的工作并在獲得 CPU 時間時對其進行處理。* 截至 2007 年，預期的郵件延遲為 2-10 秒。 這對于許多應用程序來說是可怕的，對于許多其他應用程序來說卻并不壞。* 可擴展性的一部分。 有任何數量的生產者和消費者。 您不用擔心。* Queues are spread across multiple machines and multiple data centers. ### Amazon EC2（網格服務） * 該服務可在云中提供可調整大小的計算能力。 它旨在使開發人員更容易進行 Web 規模的計算。* 基本上，您可以為 Linux 發行版創建 Xen 映像，然后將其上傳到其“彈性計算云”中。 然后，您可以使用 API??啟動任意多個實例。* 典型用途：轉碼，音頻工作，負載測試。* 對服務器的根級別訪問以及對計算機的完全控制。* 可以按分鐘放大和縮小。* 對于實時處理，一個批評是較慢的 CPU（1.75 Ghz Xeon）。 如果您的應用程序以線性比例編寫，那么這可能不會成為問題。* EC2 實例不是持久性的，因此您無法在其中存儲數據庫。 您有一些本地存儲，但是當實例消失時，它就會消失。* 啟動和停止圖像需要花費幾分鐘，因此并不是真正需要的圖像。* You can add anything you want to an image. If you want a database you can add it in. ### GigaVox 媒體示例網絡規模架構 * 您可以開始了解 Amazon 的服務如何協同工作。 假設您有大量的 MP2，希望將其轉碼為 MP3。 您將原始媒體存儲到 S3 中，將工作請求放入 SQS 中，并使實例在 EC2 中運行以處理隊列并執行轉碼，然后將結果存儲回 S3 中。 這正是 GigaVox 所做的。* GigaVox 是一家播客公司。 -他們獲取原始錄音并將它們說出來的內容從 MP2 轉換為 MP3。 還執行許多其他代碼轉換。 -然后，根據制作節目，將這些大塊媒體組裝在一起成為一種交付格式。 例如，舊的播客可以每晚更新最新的廣告。 -大規模執行此操作將需要大量昂貴的資源。* 使用 Amazon 的服務，GigaVox 可以獲得地理上的冗余和故障轉移，從而獲得相對便宜的 CPU，帶寬和存儲費用， 和帶寬成本。 您沒有盒子或電線。 無需管理數據中心。 而且您可以以較小的固定成本進行增長。* 消息在隊列上帶有時間戳。 如果消息在隊列中等待的時間太長，則它們可以啟動更多 EC2 映像。 您可以平衡成本。 您還可以在基于客戶的優先級機制中分層。* 他們每個實例都有自己的消息隊列，用于命令和控制。* 出于安全原因，他們通過 ftp 將文件上傳到實例，而不是通過 S3。* 亞馬遜云的所有帶寬都是免費的。 這是使服務協同工作的重要業務考慮因素。* 另一組實例和隊列負責組合交付的媒體。* 使 GigaVox 以較低的啟動成本為客戶提供價值。 ## 得到教訓 * 建立或購買始終是一個艱難的決定。 如果某項服務無法正常工作，那么您可能會失去客戶，并且您無能為力，其他人還會向其他人發送緊急電子郵件。 這是一種可怕的感覺。 但是，如果確實可行，那么您可能會領先于游戲。 如何選擇？ 那會告訴:-) * 構建虛擬化層，以便您可以在其他提供商可用時切換到該提供商，或者可以用自己的服務替換它。 如果他們厭倦了提供服務或性能下降，這可以減少您對亞馬遜的依賴。 * 作為一家使用 Amazon 服務的初創公司，這并不是什么大風險，因為您已經處于危險境地。 極低的啟動成本可以緩解任何風險，而資金始終是初創企業的問題。 * 在許多情況下，購買自己的專用服務器可能仍然是更好的方法，因為您可以獲得更多的控制權，更低的延遲，并且相同的硬件可用于多種用途。 * 軟件即服務是一個強大而實用的想法。 它改變了您構建軟件的方式。 它迫使您圍繞界面對軟件進行分層。 并且一旦您的軟件由接口組成，您將擁有可以輕松更換的松散耦合的組件。 如果您想為客戶提供 API，那么您還具有平臺 API 的基礎。 最高的開發水平將使用您提供給客戶的相同 API 來構建服務。 * 松散耦合的，基于消息的體系結構與服務接口相結合，使您可以考慮抽象層的多個層次。 您不必費解，這使您可以釋放使用大型行為塊來構建應用程序的方式。 * 為異步交互界面設計 UI 帶來了一些挑戰。 可能需要一段時間才能執行操作，那么您如何與用戶交互以進行處理呢？ * 我本能地懷疑亞馬遜能否交付。 但是，如果您遇到的問題類型正確，則確實可以使用 Amazon 服務廉價地完成很多工作。 ## 也可以看看 * [Flickr](http://highscalability.com/flickr-architecture) 和 [YouTube](http://highscalability.com/youtube-architecture) 也處理服務級別 API。 * [在 Amazon EC2 和 Amazon S3 上運行 Hadoop MapReduce](http://developer.amazonwebservices.com/connect/entry.jspa?externalID=873&categoryID=112) 實用計算最終將成為現實且負擔得起。 小公司可以使用 Amazon，Hadoop 和 Hbase 與巨頭競爭嗎？ 實際上，甚至 Yahoo 最近都宣布了對 Hadoop 的支持：<cite>“展望未來，并思考大規模計算的經濟如何繼續改善，不難想象，在 Hadoop 和基于 Hadoop 的基礎架構如此普遍的時代 LAMP（Linux，Apache，MySQL，Perl / PHP / Python）堆棧有助于推動 Web 的先前發展。”</cite> 在此處閱讀更多信息： [http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html](http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html) 沒有“無限擴展”這樣的東西。 完美的可伸縮性意味著，如果您將資源增加一倍，則無論從速度，容量還是所測量的任何方面，都將獲得雙倍的性能。 實際上，您擁有無限的資源并不能使您的應用程序無限擴展。 這只是意味著您可以忽略一些可伸縮性問題，例如收益遞減。 “在 2006 年 4 月開始的將近 7 個小時中，Amazon 的 S3 存儲服務只返回了服務不可用的消息。該事件在 2007 年 1 月再次發生，破壞了 Amazon 99.99％的正常運行時間目標。” （摘自 [http://flud.org/blog/2007/04/26/eradicating-service-outages-once-and-for-all/“](<a rel=) >徹底消除服務中斷， 它還提出了一種用于*真正*可擴展和不受干擾的系統的替代架構。） 單獨使用 Amazon 應用程序如何擴展 500GB MySQL 數據庫？ 我知道這不一定是您在這里所說的，但是對于大多數 Web 應用程序而言，擴展意味著更多的 Web /應用程序服務器和更多的數據庫功能。 我看到在 Amazon 上解決此問題的一種解決方案是每 10 分鐘備份一次 MySQL 數據庫。 這可能適用于 50mb 的數據庫，但適用于 10GB 的數據庫，更不用說 50-100GB 的數據庫了？ 然后，當您的數據庫集群出現故障時，您如何向您的用戶解釋說，您選擇使用 Amazon“無限擴展”的最后幾個小時丟失了價值數小時的數據？ 只是好奇-我會很樂意以某種方式解決這個問題。 這仍然是早期技術-仍然太豐富和太慢。 當平均帶寬突破 10mb / s，而每次使用的價格又下降了一個數量級時，我們將面臨一場真正的革命。 在此之前，這些服務的市場有限。 本地存儲是您要查找的選項，現已可用（截至本周）。 然后，您可以將本地副本備份到 s3。 請記住，您不會為每個備份存儲 10GB，而是存儲更改增量，因此，實際上增量比您表示的要多得多。 您可以構建按地理位置分布的多集群環境，并且構建涉及輪循（m / m / m-環形拓撲）或 m / s / s 甚至 m / m（ m / s / s 和 m / s / su 形拓撲）。 這些技術還處于起步階段。 由于缺乏云故障轉移，目前唯一不可能的情況是服務故障。 在 Amazon 的情況下，使 SOAP 服務終止并不意味著您的服務（必定）終止，而是意味著您無法按需擴展等，并且您不能進行更改，直到 SOAP 服務恢復為止。 由于 s3 復制，目前針對 Amazon 的現有解決方案可能內置 20-40 秒的延遲（s3 的性能可能會有所不同），但是本地存儲可以在本地磁盤上排隊，然后從那里進行備份 ，減少問題的影響（即使服務崩潰，本地存儲也將保持不變）。 希望能有所幫助。 它可以進行架構設計，而這個問題不再是秀場停止。 很明顯，您不是財務專家。 當您超越“帶寬/存儲”比較，進入云計算的總運營成本時，我的分析一直顯示高性能站點的總體成本降低了 5-7 倍（這是 Sun Microsystems VS Amazon 上的 A / B ，而且我相信 Sun 是最有效的解決方案，因為它們具有很高的 CPU 密度），而在最壞的情況下，我看到的是 2 比 1 的降低。 第二個問題不受個人開發人員的考慮，但是對于使用基礎結構的公司來說，它的主要問題是調配的速度。 云將應用程序的配置從數天，數周或數月轉移到數小時，數分鐘和數秒。 而且，從本質上講，它們將為 SaaS 和其他企業技術提供復雜的應用程序（由于成本優勢，所謂的“企業云”將興起）。 IBM，VMWare，XEN，Microsoft，Google 和 Amazon 知道它還沒有為“ Enterprise”做好準備，但是它很快就會成熟。 考慮 Forrester 報告（ [http://tinyurl.com/6s5qyc）](http://tinyurl.com/6s5qyc),)，其中顯示： 云計算是否已為企業準備就緒？ “還沒有，但是這種破壞性的創新正在迅速成熟” 技術的成熟度是一個問題（安全性，可用性等），但是它將得到解決。 并期待*內部*云計算的興起，這將改變競爭環境，價格將不可避免地下降，隨著解決方案的成熟，對價格敏感度較低且有很多意料之外的麻煩的客戶將進入市場。