亞馬遜的技術架構是怎麼樣的？
01-26
似乎很少看到相關討論，雖然它的雲平台很強大
平台
l Linuxl oraclel C++l Perll Masonl Javal Jbossl Servlets狀態l 超過5500萬活動顧客帳號
l 世界範圍內超過100萬活動零售合作商l 構建一個頁面所需訪問的服務介於100至150個之間體系結構l 我們說的可伸縮性到底意味著什麼？對於一個服務來說，當我們增加為其分配的系統資源之後，它的性能增長能夠與投入的資源按比例提升，我們就說這個服務具有可伸縮性。通常意義上的性能提升，意味著能夠提供更多的服務單元，也可以為更大的工作單元提供服務，比如增長的數據集等。l Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分散式的、去中心化的服務平台，提供許多種不同的應用。l 最開始只有一個應用來和後端交互，是用C++來完成的。l 架構會隨著時間而演進。多年來，Amazon將增容的主要精力放在後端的資料庫上，試圖讓其容納更多的商品數據，更多的客戶數據，更多的訂單數據，並讓其支持多個國際站點。到2001年，前端應用很明顯不能再做任何增容方面的努力了。資料庫被分為很多個小部分，圍繞每個部分會創建一個服務介面，並且該介面是訪問數據的唯一途徑。l 資料庫逐漸演變成共享資源，這樣就很難再在全部業務的基礎之上進行增容操作了。前端與後端處理的演進受到很大限制，因為他們被太多不同的團隊和流程所共享了。l 他們的架構是鬆散耦合的的，並且圍繞著服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟體組件的開發。l 逐漸地，Amazon擁有了數百個服務，並有若干應用伺服器，從服務中聚合信息。生成http://Amazon.com站點頁面的應用就位於這樣的一台應用伺服器之上。提供web服務介面、顧客服務應用以及賣家介面的應用也都是類似的情況。
l 許多第三方的技術難以適用Amazon這種網站的規模，特別是通訊基礎架構技術。它們在一定範圍內工作的很好，但是如果範圍再擴大的話，它們就不適用了。因此，Amazon只好自己開發相應的基礎技術。l 不在一種技術上"弔死"。Amazon在有的地方使用jboss/java,不過只是使用servlets，並沒有完全使用j2ee中所涉及到的技術。l C++開發的程序被用來處理請求。Perl/Mason開發的程序用來生成頁面中的內容。l Amazon不喜歡採用中間件技術，因為它看起來更像一種框架而不是一個工具。如果採用了某種中間件，那麼就會被那種中間件所採用的軟體模式所困擾。你也就只能選用他們的軟體。如果你想採用不同的軟體幾乎是不可能的。你被困住了！經常發生的情況就是消息中間件，數據持久層中間件，Ajax等等。它們都太複雜了。如果中間件能夠以更小的組件的方式提供，更像一個工具而不是框架，或許對我們的吸引力會更大一些。l SOAP 相關的web解決方案看起來想再次解決所有分散式系統的問題。l Amazon提供SOAP和REST這兩種Web 服務。大概有30%的用戶採用SOAP這種Web Services。他們看起來似乎是Java和.NET的用戶，而且使用WSDL來生成遠程對象介面。大概有70%的用戶使用REST。他們看起來似乎是PHP和PERL的用戶。l 無論採用SOAP還是REST，開發人員都可以得到訪問Amazon的對象介面。開發人員想要的是把工作完成，而不需要關心網線上傳輸的是什麼東西。l Amazon想要圍繞他們的服務構建一個開放的社區。他們之所以選擇Web Services是因為它的簡單。事實上它是一個面向服務的體系架構。簡單來說，你只有通過介面才能訪問到需要的數據，這些介面是用WSDL描述的，不過它們採用自己的封裝和傳輸機制。l 架構開發團隊都是小規模團隊，而且都是圍繞不同的服務進行組織。n 在Amazon服務是獨立的功能交付單元。這也是Amazon如何組織他的內部團隊的。
n 如果你有一個新的業務建議，或者想解決一個問題，你就可以組織一個團隊。由於溝通上的成本，每個團隊都限制到8~10個人。他們被稱為two pizza teams。因為用兩個比薩餅，就可以讓團隊成員每個人都吃飽了。n 團隊都是小規模的。他們被授權可以採取他們所中意的任何方式來解決一個問題或者增強一個服務。n 例如，他們創建了這樣一個團隊，其功能是在一本書中查找特有的文字和短語。這個團隊為那個功能創建了一個獨立的服務介面，而且有權做任何他們認為需要做的事情。l 部署n 他們創建了一個特殊的基礎設施，來完成對依賴性的管理和對完成服務的部署。n 目標是讓所有正確的服務可以在一個主機中部署。所有的應用代碼、監控機制、許可證機制等都應該在一個「主機」中。n 每個人都有一個自己的系統來解決這些問題。n 部署進程的輸出是一個虛擬機，你可以用EC2來運行他們。l 為了驗證新服務的效果，從客戶的角度去看待服務，這樣做是值得的。n 從客戶的角度去看待服務，聚焦於你想交付給用戶的價值。
n 強迫開發人員將關注點放在交付給客戶的價值上，而不是先考慮如何構建技術再考慮如何使用技術。n 從用戶將要看到的簡要特性開始，再從客戶考慮的角度檢查你構建的服務是否有價值。n 以最小化的設計來結束設計過程。如果想要構建一個很大的分散式系統，簡單性是關鍵。l 對於大型可伸縮系統來說狀態管理是核心問題n 內部而言，他們可以提供無限存儲空間。n 並不是所有的操作是有狀態的。結賬的步驟是有狀態的。n 通過分析最近點擊過的頁面的SessionID，這種服務可以為用戶提供推薦商品建議。n 他們追蹤、保存著所有的數據，所以保持狀態不是一個問題。有一些分離的狀態需要為一個session來保持。提供的服務們會一直保留信息，所以你只要使用這些服務就可以了。l Eric Brewers" CAP理論——或稱為系統的三個屬性n 系統的三個屬性：一致性，可用性，網路分區容忍度。
n 對於任何一個共享數據的系統都至少具備這三個屬性中的兩個。n 網路分區容忍度：把節點分割成一些小的分組，它們可以看到其他的分組但是無法看到其他全部節點。n 一致性：寫入一個值然後再讀出來，你得到的返回值應該和寫入的是同一個值。在一個分區系統中有些情況並非如此。n 可用性：並非總是可讀或者可寫。系統可能會告訴你無法寫入數據因為需要保持數據的一致性。n 為了可伸縮性，你必須對系統進行分區，因此針對特定的系統，你要在高一致性或者高可用性之間做出選擇。你必須找到可用性和一致性的恰當重疊部分。n 基於服務的需要來選擇特定的實現方法。n 對於結賬的過程，你總是想讓更多的物品放入顧客的購物車，因為這樣可以產生收入。在這種情況下你需要選擇高可用性。錯誤對顧客是隱藏的，過後才會被拿出來分析。n 當一個顧客提交訂單過來時，我們要將關注點更多的放在保持高一致性上。因為幾個不同的服務——信用卡處服務、配送服務、報表功能等——在同時訪問那些數據。汲取的教訓l 為了構建真正的可伸縮的系統，你必須改變你的想法或者心態。混沌方法在概率意義上可能工作的很好。在傳統的系統中我們展示的是一個完美的世界，沒有什麼東西會出現問題、停止運轉，之後我們在這個完美的世界上構造複雜的演算法。實際上，事情總是會出問題的，這就是你必須要接受的事實。例如，試著多想想如何快速完成伺服器重啟和如何快速恢複數據。合適的分布數據和服務，你可能向100%無故障又邁進了一步。創建可自愈的（self-healing）、自組織的（self-organizing）系統架構。
l 創建一個沒有分享的基礎架構。對於開發和部署來說，基礎架構也是共享資源，就像在邏輯層和數據層共享的資源一樣，你也會遭遇到出問題的時候。可能會導致鎖機制和屏蔽機制，併產生死鎖。一個面向服務的架構，允許採取並行和分離的開發流程，這樣可以使得功能特性的開發也具有「可伸縮性」，與系統的增長相匹配l 將系統及其API同時開放，這樣你會圍繞著你的應用創建了一個生態系統。l 管理巨大的分散式系統的唯一方法，就是讓所有的事情儘可能的簡單。保持事情簡單的辦法就是保證設計的時候沒有隱藏的需求和隱藏的依賴關係。採用儘可能少的技術來解決你解決的問題。人為的創造一些不需要的複雜系統層次架構對公司並沒有益處。l 圍繞服務進行組織可以提供敏捷性。你可以並行的做事情，因為輸出結果是一個服務。這使得縮短了產品和服務投放到市場去的時間。需要創建一個基礎架構來保證服務可以被很快的構建起來。l 任何事情，在有真正的實現之前，就來了一堆炒作消息，這其中肯定存在著問題。l 在內部使用服務品質協議（Service Level Agreement，簡稱SLA）來管理服務。l 任何人都可以很快的為他們的產品添加Web Services。以服務的形式來實現你的一部分產品，並開始使用這些服務。l 由於性能，可靠性和成本控制的原因，可能需要自己來構建基礎設施架構。自己構建這些基礎架構即便Amazon關門了也不必說是某某公司的錯誤導致的。自己構建的系統可能沒有其他的易用，不過相對使用第三方的東西來說，你可以更快地對自己構建的基礎架構進行修補、調試和部署。l 採用「『方法』和『目的』」這樣的思辨方式，來區分好與壞。我曾參加過幾次前Amazon員工做的演講，從中發現，這是Amazon和其他公司很不一樣的獨特而有趣之處。其深層道理是，通過將選擇的權利交給真正的顧客，來看哪種做法最合適，並基於這些測試來發現顧客的真正需要。Avinash Kaushik把這個叫做避免HiPPO（the highest paid people in the room，屋子裡拿薪水最高的人）的影響。通過A/B測試和Web Analytics等技術手段可以達成目的。如果你對應該做什麼有疑問，先開發一些功能，讓人們使用這些功能，再看哪一種變通使用方式能夠帶給你想要的結果。l 創建一個節儉的環境。例如，Amazon就把門當桌子來用。
l 了解你需要什麼。Amazon早期有一個很糟糕的經歷，就是沒有達成預期目標的推薦系統： 「這不是我們所需要的圖書推薦系統。Amazon需要的是一個可以基於少量分散的數據，例如一些顧客的評分和購買記錄，就可以很好的工作的圖書推薦系統。而且它的反應速度要足夠快。這個系統也需要適應大量的數據和大量的圖書類別。而且它還可以幫助讀者發現一些他們真正需要卻自己無法發現的圖書需求。」l 人性化的項目——人們跟隨這個項目是因為他們對其感興趣——可以激發更多的價值和創造力。不要低估因為興趣而激發的力量。l 在創建產品的過程中，讓每個人都參與進來。在聖誕大採購來臨之時，去倉庫打包圖書吧，這樣才是團隊精神。l 創建一個可以用來測試的站點，測試通過之後才可以真正的向大眾推出。l 對於Web伺服器使用的只讀數據來說，一個健壯的、集群式的、冗餘的、分散式文件系統是完美的。l 如果更新沒有成功的話，要有可以回滾到以前正常的狀態的運作方式。必要的話開發一個工具。l 轉向更深入的基於服務的架構l 面試的時候需要關注參加面試者的三個要點：熱情，創造力和熟練程度。在Amazon，成功的最大特徵就是對工作的熱情。l 要僱傭這樣的員工，他們有著驚人的調試技術和系統知識，最重要的是，他們可以在高度壓力的狀況下，應對非常棘手的問題。l 創新只能來自於底層。最了解問題的人才是最有可能解決問題的人。任何一個依賴於創新的組織必須可以容納一定程度的混沌。忠誠和服從不是你的工具。
l 創新精神必須無處不在。l 任何人都應該有機會去嘗試，去學習，去實踐。職位的變遷，服從，傳統的習慣都不應該有多大的權利。創新的蓬勃發展，必須要有一套行之有效的考核辦法。l 擁抱創新。在整個公司員工的面前，Jeff Bezos會親自頒發"Just do it"獎，一雙舊的耐克鞋，給那些具有創新精神員工。l 不要基於績效給付薪酬。給予好的福利和高的薪酬，但是要讓大部分人都能享受到。通過其他的方式來表達出對一些表現非常優異的員工的認可。"按勞分配"聽起來不錯，但是在一個大公司內是不可能做到公平的。採用一些非貨幣的獎勵，例如一雙舊的耐克鞋其實也是很好的。那也是一種用來表達感謝的方式，說明有人在關心他們。l 迅速擴張。像Barnes Nobel這樣的大型對手緊跟在你的後面。Amazon曾經不是互聯網上最大的書店，不是第二名，甚至也不是第三名。但是他們的遠景規劃和執行方式最終讓他們笑到了最後。l 在數據中心，員工花在解決基礎設施問題上面的時間只有30%是和利潤創造相關的。其他的70%的時間則是花在"繁重"的硬體採購、軟體管理、負載均衡、維護、應對增容挑戰等其他事情上。l 嚴禁客戶直接訪問數據。這意味著你可以讓你的服務具有可伸縮性，並在不影響客戶的前提下，具有更好的可靠性。這有些類似於Google的能力，他們能夠通過對伺服器棧的獨立、分布的改進，來提升所有的應用。l 創建統一的服務訪問機制。這使得服務易於集成，還可以完成請求路由去中心化、分布請求追蹤、以及其他一些高級的基礎架構技術。l 讓世界上任何開發人員都能夠通過Web服務介面，免費訪問http://Amazon.com。這也是成功的一個重要因素。因為它引發的諸多創新，僅靠Amazon自己的隊伍是無法想像出來或者無法實現的。l 開發人員自己知道哪些工具用起來最順手，什麼樣的工具最適合目前的工作。l 不要在工程師身上強加過多的限制。為某些功能的完成提供一些激勵措施，比如與監控系統的集成，或者與其他基礎架構工具的集成等功能。但是對於其他的功能，要保證團隊的獨立性。l 開發人員與藝術家類似，如果有足夠的自由，他們就可以把工作做到最好，但是他們也需要好的工具。提供盡量多的支持工具，圍繞著服務的開發，提供環境的支持，使得環境不會成為開發工作的阻礙。l 誰構建，誰運行。這讓開發人員與他們所開發的軟體的日常運營工作相聯繫。也帶給他們與顧客之間的日常聯繫。這種顧客反饋循環對於提升服務質量來說是至關重要的。l 每隔兩年，開發人員就應該與客戶服務部門在一起待一段時間。在那裡，他們可以聽到真實的客服電話，回答客服電子郵件，並深刻領會他們作為技術人員所開發的東西造成的影響。l 讓大家聆聽「來自顧客的聲音」，內容是一個顧客講述自己使用網站所產生的用戶體驗的真實故事。這可以讓管理層和工程師們體會到，我們是在為實實在在的人們開發這些技術。通過客服統計數據，我們可以提早發現做錯了哪些事情，或是發現哪些是客戶的真實痛點。l 就像Google一樣，Amazon的基礎架構是他們的巨大核心競爭力。通過一些相對簡單的底層服務，他們可以構建出非常複雜的應用。他們可以彼此獨立地完成各個服務的增容，維護非並行系統的可用性，並在不需要修改大量系統配置的情況下，快速發布新的服務。不讓說
推薦閱讀：
※怎樣批量刪除在亞馬遜伺服器上的已經推送到 Kindle 上的內容？
※Kindle Paperwhite 為啥不做窄邊框的機型？
※很多人在黑亞馬遜嗎？
※亞馬遜客服到底是怎麼一群人？
※為什麼卓越亞馬遜有些商品的差評那麼嚴重？
TAG:亞馬遜Amazoncom | 技術架構 |