# 亞馬遜建筑 > 原文： [http://highscalability.com/blog/2007/9/18/amazon-architecture.html](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) *這是基于喬亞希姆·羅德（Joachim Rohde）對亞馬遜 CTO 采訪的發現而提供的非常有用的亞馬遜更新。 您將了解 Amazon 如何圍繞服務組織團隊，構建可擴展系統的 CAP 定理，他們如何部署軟件等等。 還包括了“ ACM 隊列”文章中的許多新功能。* 亞馬遜從一個很小的在線書店發展成為地球上最大的商店之一。 他們做到了這一點，同時開創了對產品進行評分，評論和推薦的有趣新方法。 格雷格·林登（Greg Linden）在一系列博客文章中分享的是 Amazon 的出生困境 網站：http：//amazon.com ## 信息來源 * [早期亞馬遜作家，格雷格·林登](http://glinden.blogspot.com/2006/05/early-amazon-end.html)* [Linux 如何為 Amazon 節省了數百萬美元](http://news.com.com/2100-1001-275155.html)* [專訪 Werner Vogels](http://www.se-radio.net/index.php?post_id=157593) -亞馬遜的 CTO* 異步體系結構-Chris Loosley 的 Werner Vogels 演講的精彩[摘要](http://www.webperformancematters.com/journal/2007/8/21/asynchronous-architectures-4.html)* [向亞馬遜技術平臺學習](http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388)-與 Werner Vogels 的對話* [Werner Vogels 的 Weblog](http://www.allthingsdistributed.com) -構建可擴展且強大的分布式系統 ## 平臺 * 的 Linux* 甲骨文* C ++* 佩爾* 石匠* 爪哇* 博斯* Servlets ## 統計資料 * 超過 5500 萬活躍客戶帳戶。* 全球超過 100 萬活躍零售合作伙伴。* 訪問 100-150 之間的服務以構建頁面。 ## 架構 * 我們對可伸縮性的真正含義是什么？ 如果我們在系統中增加資源時以與添加資源成比例的方式提高性能，則該服務被稱為可伸縮的。 通常，提高性能意味著要服務更多的工作單元，但是也可以處理更大的工作單元，例如數據集增長時。 * 亞馬遜所做的重大體系結構更改是從兩層的整體架構轉變為可服務于許多不同應用程序的完全分布式，去中心化的服務平臺。* 作為一個與后端通信的應用程序啟動。 用 C ++編寫。* 它成長了。 多年來，亞馬遜的擴展工作一直致力于使后端數據庫進行擴展，以容納更多物品，更多客戶，更多訂單并支持多個國際站點。 在 2001 年，很明顯前端應用程序無法再擴展。 數據庫被分成幾個小部分，并圍繞每個部分創建了一個服務接口，這是訪問數據的唯一方法。* 數據庫成為共享資源，這使得很難擴展整個業務。 前端和后端流程的發展受到限制，因為它們被許多不同的團隊和流程共享。* 它們的體系結構是松散耦合的，并圍繞服務構建。 面向服務的體系結構為他們提供了隔離，使他們可以快速，獨立地構建許多軟件組件。* 聚集了數百個服務和大量應用程序服務器，這些服務服務器匯總了來自服務的信息。 呈現 Amazon.com 網頁的應用程序就是這樣一種應用程序服務器。 服務 Web 服務接口的應用程序，客戶服務應用程序和賣方接口也是如此。* 許多第三方技術很難擴展到亞馬遜的規模。 特別是通訊基礎設施技術。 它們會在一定規模下正常工作，然后失敗。 因此，他們被迫建立自己的。* 不拘泥于一種特定的方法。 在某些地方，他們使用 jboss / java，但僅使用 servlet，而不使用 J2EE 堆棧的其余部分。* C ++用于處理請求。 Perl / Mason 用于構建內容。* 亞馬遜不喜歡中間件，因為中間件往往是框架而不是工具。 如果您使用中間件軟件包，則會鎖定他們選擇的軟件模式。 您將只能使用他們的軟件。 因此，如果您想使用其他軟件包，則將無法使用。 你被困住了。 一個事件循環，用于消息傳遞，數據持久性， AJAX 等。太復雜了。 如果中間件可以在較小的組件中使用，而更多的是作為工具而不是框架使用，那么他們會更感興趣。* SOAP Web 堆棧似乎想再次解決所有相同的分布式系統問題。* 同時提供 SOAP 和 REST Web 服務。 30％使用 SOAP。 這些通常是 Java 和.NET 用戶，并使用 WSDL 文件生成遠程對象接口。 70％的人使用 REST。 這些往往是 PHP 或 PERL 用戶。* 在 SOAP 或 REST 中，開發人員都可以獲取到 Amazon 的對象接口。 開發人員只想完成工作。 他們不在乎導線上的內容。* 亞馬遜希望圍繞他們的服務建立一個開放的社區。 選擇 Web 服務是因為它很簡單。 但是帽子只在外圍。 在內部，它是一種面向服務的體系結構。 您只能通過界面訪問數據。 WSDL 中對此進行了描述，但是它們使用了自己的封裝和傳輸機制。* 團隊很小，并且圍繞服務 進行組織-服務是在 Amazon 內部提供功能的獨立單位。 這也是亞馬遜在團隊內部進行組織的方式。 -如果您有一個新的業務構想或問題，您想組成一個團隊來解決。 由于溝通困難，團隊人數不得超過 8-10 人。 他們被稱為兩個披薩隊。 您可以養活兩個比薩餅的人數。 -團隊很小。 他們被授予權限并有權以他們認為合適的方式解決問題，即服務。 -例如，他們創建了一個小組，以在書中查找文本唯一的短語。 該團隊為此功能構建了一個單獨的服務接口，他們有權執行所需的操作。 -廣泛的 A / B 測試用于集成新服務。 他們看到了影響并進行了廣泛的測量。* 部署 -他們創建用于管理依賴關系和進行部署的特殊基礎結構。 -目標是將所有合適的服務部署在一個盒子上。 所有應用程序代碼，監視，許可等都應放在包裝盒中。 -每個人都有一個解決這些問題的本地系統。 -部署過程的輸出是虛擬機。 您可以使用 EC2 來運行它們。* 從客戶后方進行工作以驗證是否值得進行一項新服務 -從客戶后方進行工作。 專注于您想要為客戶交付 的價值。 -迫使開發人員專注于交付給客戶的價值，而不是先構建技術然后再去思考如何使用它。 -從新聞稿開始，介紹用戶將看到的功能并向后工作以檢查您是否正在構建有價值的東西。 -最終以盡可能最小的設計完成。 如果您確實要構建大型分布式系統，那么簡單是關鍵。* 狀態管理是大規模系統 的核心問題-內部，它們可以提供無限的存儲空間。 -并不是所有的操作都是有狀態的。 結帳步驟是有狀態的。 -最近點擊的網頁服務具有基于會話 ID 的建議。 -無論如何，他們都會跟蹤所有事情，因此保持狀態無關緊要。 會話幾乎不需要保留單獨的狀態。 服務將已經保留了信息，因此您只需要使用服務即可。* Eric Brewer 的 CAP 定理或系統的三個屬性 -系統的三個屬性：一致性，可用性，對網絡分區的容忍度。 -對于任何共享數據系統，這三個屬性中最多可以有兩個。 -可分區性：將節點分為幾個小組，可以看到其他小組，但看不到所有人。 -一致性：寫入一個值，然后讀取該值，您將獲得相同的值。 在分區系統中，存在不正確的窗口。 -可用性：可能并不總是能夠寫入或讀取。 系統會說您不能寫，因為它想保持系統的一致性。 -要擴展，您必須進行分區，因此您只能為特定系統選擇高一致性或高可用性。 您必須找到可用性和一致性的正確重疊。 -根據服務需求選擇特定的方法。 -對于結帳流程，您始終希望兌現將商品添加到購物車的請求，因為它可以產生收益。 在這種情況下，您選擇高可用性。 對客戶隱藏錯誤，并在以后進行分類。 -當客戶提交訂單時，您希望保持一致性，因為多項服務（信用卡處理，運輸和處理，報告）正在同時訪問數據。 ## 得到教訓 * 您必須改變思路，才能構建真正可擴展的系統。 以概率的方式處理混亂，事情會順利進行。 在傳統系統中，我們提供了一個完美的世界，在這個完美的世界上一切都沒有失敗，然后我們在這個完美的世界上構建了復雜的算法（協議技術）。 相反，將其視為理所當然的東西會失敗，這是 現實，請接受它。 例如，使用快速重啟和快速恢復方法進行更多操作。 隨著數據和服務的良好傳播，您可能會接近 100％。 創建自我修復，自我組織的熄燈操作。 * 創建一個沒有共享的基礎架構。 基礎架構可以成為開發和部署的共享資源，其缺點與邏輯層和數據層中的共享資源相同。 它可能導致鎖定和阻塞以及死鎖。 面向服務的體系結構允許創建并行且隔離的開發流程，以擴展功能開發以適應您的增長。 * 使用 API??打開系統，您將在應用程序周圍創建一個生態系統。 * 管理大型分布式系統的唯一方法是使事情盡可能簡單。 通過確保設計中沒有隱藏的需求和隱藏的依賴關系，使事情變得簡單。 將技術減少到解決您所遇到的問題所需的最低限度。 這無助于公司創建人為的和不必要的復雜性層。 * 圍繞服務進行組織可提供敏捷性。 您可以并行執行的操作是因為輸出是服務。 這樣可以加快上市時間。 創建一個基礎結構，以允許快速構建服務。 * 在實際實現之前，任何會引起炒作的問題都存在問題 * 在內部使用 SLA 來管理服務。 * 任何人都可以非常快速地將 Web 服務添加到其產品中。 只需將產品的一部分作為服務實施并開始使用即可。 * 出于性能，可靠性和成本控制的原因，構建自己的基礎架構。 通過自己構建它，您不必說您倒閉，因為這是 X 公司的錯。 您的軟件可能不比其他軟件更可靠，但是與第三者合作時，您可以更快地進行修復，調試和部署。 * 用度量和客觀辯論將好與壞分開。 我去過前亞馬遜的幾場演講，而這正是亞馬遜給我的印象，與其他公司截然不同。 他們根深蒂固的道德操守是讓真正的客戶有選擇的余地，看看哪個最有效，并根據這些測試做出決策。 [Avinash Kaushik](http://highscalability.com/blog-occam-s-razor-avinash-kaushik) 稱這擺脫了 HiPPO（房間中收入最高的人）的影響。 這是通過 A / B 測試和 Web Analytics 等技術完成的。 如果您對應該如何編寫代碼有疑問，請讓人們使用它，然后看看哪種選擇可以為您提供所需的結果。 * 營造節儉文化。 例如，亞馬遜使用書桌門。 * 知道你需要什么。 亞馬遜在一個早期的推薦系統上經歷了糟糕的經歷，但并沒有奏效：“這不是亞馬遜所需要的。在亞馬遜上進行書推薦需要使用稀疏數據，只需進行幾次評級或購買即可。它必須要快。 該系統需要擴展到大量的客戶和龐大的目錄，還需要增強發現能力，使目錄中深處的書籍無法被讀者自己找到。” * 人們感興趣的旁人項目通常是您獲得最大價值和創新的項目。 永遠不要低估您最感興趣的地方徘徊的力量。 * 讓每個人都參與制作狗糧。 在圣誕節高峰期間，請進倉庫并整理書籍。 那是團隊合作。 * 創建一個登臺站點，在發布到野外之前，您可以在其中進行全面的測試。 * 一個健壯的，集群的，復制的，分布式文件系統非常適合 Web 服務器使用的只讀數據。 * 如果更新不起作用，有一種方法可以回滾。 如有必要，編寫工具。 * 切換到基于深度服務的體系結構（http://webservices.sys-con.com/read/262024.htm）。 * 在面試中尋找三件事：熱情，創造力，能力。 對 Amazon.com 成功的最大預測是熱情。 * 雇用鮑勃。 知道他們的東西，擁有令人難以置信的調試技能和系統知識的人，最重要的是，他們擁有一頭石頭就能解決僅憑跳進就可以想象到的最嚴重的高壓問題。* 創新只能來自底層。 那些最接近問題的人最有可能解決問題。 任何依賴創新的組織都必須擁抱混亂。 忠誠和服從不是您的工具。 * 創意必須無處不在。 * 每個人都必須能夠進行實驗，學習和迭代。 職位，服從和傳統不應該擁有任何權力。 為了使創新蓬勃發展，必須衡量。 * 擁抱創新。 在整個公司的面前，杰夫·貝佐斯（Jeff Bezos）會將一雙耐克舊鞋授予“勇于創新”的人，以表彰他們的創新精神。 * 不要為性能付出代價。 給予良好的待遇和高薪，但保持平穩。 以其他方式認可出色的工作。 績效工資聽起來不錯，但是在大型組織中幾乎不可能做到。 使用非金錢獎勵，例如舊鞋子。 這是說謝謝的方式，有人在乎。 * 快速變大。 像巴恩斯（Barnes）和諾貝爾（Nobel）這樣的大人物在你的尾巴上。 亞馬遜甚至不是網絡上的第一，第二，甚至第三本書店，但最終他們的愿景和驅動力勝出了。 * 在數據中心，只有 30％的員工時間花費在與價值創造相關的基礎架構問題上，其余 70％專門用于應對硬件采購，軟件管理，負載平衡，維護，可擴展性挑戰以及 以此類推。 * 禁止客戶端直接訪問數據庫。 這意味著您可以在不涉及客戶的情況下擴大服務范圍并提高可靠性。 這很像 Google 能夠獨立地在其堆棧中分發改進以使所有應用程序受益的能力。 * 創建一個統一的服務訪問機制。 這使得服務易于聚合，分散請求路由，分布式請求跟蹤以及其他高級基礎結構技術。 * 通過 Web 服務接口向世界上任何開發人員免費提供 Amazon.com 也是一項重大成功，因為它推動了許多創新，他們無法想到或自己建立。 * 開發人員自己最清楚哪些工具使它們最高效，哪些工具最適合工作。 * 不要對工程師施加太多限制。 為某些事情提供激勵，例如與監視系統和其他基礎結構工具集成。 但對于其余部分，允許團隊盡可能獨立地運作。 * 開發人員就像藝術家。 只要有自由，他們就可以發揮出自己最好的作品，但是他們需要好的工具。 有許多具有自助性質的支持工具。 為服務開發周圍的環境提供支持，而該環境永遠不會妨礙開發本身。 * 您構建它，然后運行它。 這使開發人員可以接觸到他們軟件的日常操作。 它還使他們與客戶進行日常聯系。 客戶反饋回路對于提高服務質量至關重要。 * 開發人員應每兩年花一些時間在客戶服務上。 他們實際上將收聽客戶服務電話，接聽客戶服務電子郵件，并真正了解他們作為技術人員所做的各種事情的影響。 * 使用“客戶的聲音”，這是客戶關于您網站體驗的某些特定部分的真實故事。 這可以幫助經理和工程師了解我們為實際人員構建這些技術的事實。 如果您做錯了什么或對客戶而言真正的痛點是什么，則客戶服務統計數據可以作為早期指示。 * 像 Google 一樣，Amazon 的基礎設施具有巨大的競爭優勢。 他們可以利用相對簡單的原始服務來構建非常復雜的應用程序。 他們可以獨立擴展業務規模，保持無與倫比的系統可用性，并快速引入新服務，而無需進行大量重新配置。 亞馬遜的首席技術官沃納·沃格斯（Werner Vogels）談到了 SE-Radio 的技術細節。 您可以在[下找到播客，網址為 http://www.se-radio.net/index.php?post_id=157593](http://www.se-radio.net/index.php?post_id=157593) 有趣的一集。 那是一次很好的采訪。 謝謝。 我將盡快添加新信息。 亞馬遜使用 Perl 和 Mason。 請參閱： [http://www.masonhq.com/?MasonPoweredSites](http://www.masonhq.com/?MasonPoweredSites) 如我所見，他們減少了 c ++部分并轉移到 j2ee？ 除非您是經理，否則我不確定您怎么能弄錯那個錯誤，但是即使那樣，某些工程師還是會在星期日之前教您。 感謝您抓住這一點。 我聽了幾次，有時我只是寫我聽到的內容，而不是我的意思。 我實際上在以下位置給出了可擴展性的詳細定義： [http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html“](<a rel=) >有關可擴展性的信息 我個人喜歡 [http://www.acmqueue.com/modules.php?name=內容& pa =顯示頁& pid = 388“](<a rel=) > ACM Queue 中的采訪最適合 高層視野 -維爾納 似乎他們使用 Java 來完成通常用 Perl 完成的工作。 >使用非貨幣獎勵，例如舊鞋。 這是 >說謝謝的一種方式，有人在乎。 有一次我愚蠢到參加亞馬遜全公司會議，而不是將其視為免費的入睡日，我看到貝索斯給了一個男人一雙鞋子。 我當時想：“這個家伙造了宇宙飛船，他把臭舊的網球鞋給高成就者？他們不喜歡打他嗎？自尊心在哪里？” 但是我想這就是為什么我是前亞馬遜人的原因。 當我放棄他們時，薪水提高了 20％，而且沒有傳呼機職責。 見，杰夫。 這是我一段時間以來最愚蠢的讀物之一。 一家聰明的公司為什么會花錢在員工的“獎勵”上，這對除了您從中獲得獎勵的人以外的任何人都沒有幫助？ 當亞馬遜表現出色時，他們就會獲得真正的高成就，而且股價在 90 美元左右，我知道他們的感覺還不錯。 我的猜測是他們想擁抱杰夫。 成就不佳的人很可能會對此表示不滿，然后去其他地方，他們在亞馬遜工作的事實很可能有助于這項工作，就像我確定的那樣。 而且，看來您離開并沒有對亞馬遜造成太大的傷害:) 以前的 Nikies 面向成就卓越的人的事情聽起來像是給 IBM 員工的（愚蠢的）文憑。如果您真的想感謝一個成就卓越的人，請給他們加薪或獎金，或者..不愿意參加巡航。 便秘的舊鞋子..多么可愛:)） >而且，看來您離開并未對亞馬遜造成太大的傷害:) 哦，我敢肯定，沒有我，amzn 很好。 但是亞馬遜員工的半衰期約為 18 個月，所以認為在那工作很糟糕的不只是我。 想一想，如果不必每 18 個月更換一半的員工，amzn 的運營效率就會提高多少。 我確信這將對其股價產生影響。 :) >如果公司 >表現不錯，并且股票價格在 90 美元左右，亞馬遜的真正成就就會得到回報，我知道他們對 >感覺很好。 我的猜測是他們想擁抱杰夫。 當然，現在股價飛漲，我為那里的人感到高興，他們為此賺了很多錢。 但是 amzn 按照市場標準支付工資，并依靠股票來提高工資。 我對你的薪水賭博并不酷。 算上我過去幾年的全部收入...如果我的所有 amzn 贈款都以每筆$ 90 支付，如果我呆在那里，我可能會多賺$ 15-25K。 但是，2.5 萬美元的保費（或每年 625 萬美元，因為需要花費 4 年的歸屬時間）并不足以讓我進入亞馬遜，考慮到要換取這筆保費，我需要工作 10- 每周多 30 小時。 我認為基于權益的補償是針對傻瓜的。 用權益補償來換取巨大的每周工作量需求是……更大的吸盤。 我目前的公司為我提供了真正的現金紅利和額外的帶薪休假，以使他們表現良好。 我要把它接在笨拙的舊鞋子上！ 錢用來說話； 像 bulsh * t 這樣的鞋子，是用來走路的。 作為對您的文章的深入研究的副作用，我將其翻譯為德語： [http://habacht.blogspot.com/2007/10/amazon-architecture.html](http://habacht.blogspot.com/2007/10/amazon-architecture.html) 為什么？ perl 是用于文本處理的常用工具：） java 不僅限于 perl 由于謙虛，我傾向于說 Java 并不適合所有傳統的業務術語。 效率，投資回報。 我今天經營一家公司，并且相信我，從長遠來看，Java 并不是設計大型&關鍵應用程序的最終選擇。 只有偽專家和偽 IT 經理才將 Java 視為明天編程問題的第一個答案。 我建議您檢查 J2EE 后面的語言/框架環境。 以 Perl 6 為例。 我在開玩笑 ？ 并不是的。 我們的最后一個 Web 服務完全使用 Perl 和 Ruby 中的接口進行了完全設計。 開明的用戶想知道它是否是 struts + hibernate + weblogic + oracle（可能帶有 SAP R / 3 連接器）。 現在的現實已經大不相同：我們必須考慮純粹的業務。 Java 的？ 好的，我今天將檢查 Sun 的博客。 我也愛 Java。 真的很有趣，喜歡閱讀。 但是，我覺得如果您真的想感謝一個成就卓越的人，請給他們加薪或獎金！ 那就是我最欣賞的，畢竟我們是為了錢而工作。 大部分內容非常有用（特別是我同意的部分；） 梅森對我來說是新的！ 非常好的帖子。 [http://evandro.net/“](<a rel=) > Evandro [http://www.poker73.com/”](<a rel=) >坐下&轉到 Very informative for the most part (specially the parts I agree with ;) 您能否解釋一下“ DOM”的含義 那是一篇關于亞馬遜建筑大師的好書。 在下周對亞馬遜的采訪中肯定會有所幫助。 亞馬遜是一家偉大的公司。 真的啟發了我。 [http://www.csscatwalk.com“](<a rel=) style =” color：#FFFFFF;“ > CSS 畫廊 謝謝！ 非常感謝您提供如此詳細的信息。 它無疑幫助我了解了有關構建可擴展網站的更多事實。 That was a nice read about amazon architecutre. Would definitely help during the interview with amazon next week. 大多數情況下非常有用