誰也沒想到，之前一個小小的網上書店，現在居然成了全球商品品種最多的網上零售商和全球第2大互聯網公司，它叫Amazon。相信很多朋友都知道Amazon，那就不多作介紹了，下面我們主要來探討一下Amazon的網站架構方面的話題。另外，本文很多內容也是來自互聯網，如有侵權方面的內容請留言，我會及時處理。
一、平臺以及狀態
Linux、oracle、C++、Perl、Mason、Java、Jboss、Servlets
--超過5500萬活動顧客帳號
--世界範圍內超過100萬活動零售合作商
--構建一個頁面所需訪問的服務介於100至150個之間
二、架構概述
l 我們說的可伸縮性到底意味着什麼？對於一個服務來說，當我們增加爲其分配的系統資源之後，它的性能增長能夠與投入的資源按比例提升，我們就說這個服務具有可伸縮性。通常意義上的性能提升，意味着能夠提供更多的服務單元，也可以爲更大的工作單元提供服務，比如增長的數據集等。
l Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分佈式的、去中心化的服務平臺，提供許多種不同的應用。
l 最開始只有一個應用來和後端交互，是用C++來完成的。
l 架構會隨着時間而演進。多年來，Amazon將增容的主要精力放在後端的數據庫上，試圖讓其容納更多的商品數據，更多的客戶數據，更多的訂單數據，並讓其支持多個國際站點。到2001年，前端應用很明顯不能再做任何增容方面的努力了。數據庫被分爲很多個小部分，圍繞每個部分會創建一個服務接口，並且該接口是訪問數據的唯一途徑。
l 數據庫逐漸演變成共享資源，這樣就很難再在全部業務的基礎之上進行增容操作了。前端與後端處理的演進受到很大限制，因爲他們被太多不同的團隊和流程所共享了。
l 他們的架構是鬆散耦合的的，並且圍繞着服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟件組件的開發。
l 逐漸地，Amazon擁有了數百個服務，並有若干應用服務器，從服務中聚合信息。生成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 架構開發團隊都是小規模團隊，而且都是圍繞不同的服務進行組織。
-- 在Amazon服務是獨立的功能交付單元。這也是Amazon如何組織他的內部團隊的。
-- 如果你有一個新的業務建議，或者想解決一個問題，你就可以組織一個團隊。由於溝通上的成本，每個團隊都限制到8~10個人。他們被稱爲two pizza teams。因爲用兩個比薩餅，就可以讓團隊成員每個人都吃飽了。
-- 團隊都是小規模的。他們被授權可以採取他們所中意的任何方式來解決一個問題或者增強一個服務。
-- 例如，他們創建了這樣一個團隊，其功能是在一本書中查找特有的文字和短語。這個團隊爲那個功能創建了一個獨立的服務接口，而且有權做任何他們認爲需要做的事情。
l 部署
-- 他們創建了一個特殊的基礎設施，來完成對依賴性的管理和對完成服務的部署。
-- 目標是讓所有正確的服務可以在一個主機中部署。所有的應用代碼、監控機制、許可證機制等都應該在一個“主機”中。
-- 每個人都有一個自己的系統來解決這些問題。
-- 部署進程的輸出是一個虛擬機，你可以用EC2來運行他們。
l 爲了驗證新服務的效果，從客戶的角度去看待服務，這樣做是值得的。
-- 從客戶的角度去看待服務，聚焦於你想交付給用戶的價值。
-- 強迫開發人員將關注點放在交付給客戶的價值上，而不是先考慮如何構建技術再考慮如何使用技術。
-- 從用戶將要看到的簡要特性開始，再從客戶考慮的角度檢查你構建的服務是否有價值。
-- 以最小化的設計來結束設計過程。如果想要構建一個很大的分佈式系統，簡單性是關鍵。
l 對於大型可伸縮系統來說狀態管理是核心問題
-- 內部而言，他們可以提供無限存儲空間。
-- 並不是所有的操作是有狀態的。結賬的步驟是有狀態的。
-- 通過分析最近點擊過的頁面的SessionID，這種服務可以爲用戶提供推薦商品建議。
-- 他們追蹤、保存着所有的數據，所以保持狀態不是一個問題。有一些分離的狀態需要爲一個session來保持。提供的服務們會一直保留信息，所以你只要使用這些服務就可以了。
l Eric Brewers' CAP理論——或稱爲系統的三個屬性
-- 系統的三個屬性：一致性，可用性，網絡分區容忍度。
-- 對於任何一個共享數據的系統都至少具備這三個屬性中的兩個。
-- 網絡分區容忍度：把節點分割成一些小的分組，它們可以看到其他的分組但是無法看到其他全部節點。
-- 一致性：寫入一個值然後再讀出來，你得到的返回值應該和寫入的是同一個值。在一個分區系統中有些情況並非如此。
-- 可用性：並非總是可讀或者可寫。系統可能會告訴你無法寫入數據因爲需要保持數據的一致性。
-- 爲了可伸縮性，你必須對系統進行分區，因此針對特定的系統，你要在高一致性或者高可用性之間做出選擇。你必須找到可用性和一致性的恰當重疊部分。
-- 基於服務的需要來選擇特定的實現方法。
-- 對於結賬的過程，你總是想讓更多的物品放入顧客的購物車，因爲這樣可以產生收入。在這種情況下你需要選擇高可用性。錯誤對顧客是隱藏的，過後纔會被拿出來分析。
-- 當一個顧客提交訂單過來時，我們要將關注點更多的放在保持高一致性上。因爲幾個不同的服務——信用卡處服務、配送服務、報表功能等——在同時訪問那些數據。
上段文字引自：http://www.yaosansi.com/post/1147.html
下面是一張Amazon的Dynamo Key-Value存儲架構圖：
Dynamo是亞馬遜的key-value模式的存儲平臺，可用性和擴展性都很好，性能也不錯：讀寫訪問中99.9%的響應時間都在300ms內。
按分佈式系統常用的哈希算法切分數據，分放在不同的node上。Read操作時，也是根據key的哈希值尋找對應的node。Dynamo使用了 Consistent Hashing算法，node對應的不再是一個確定的hash值，而是一個hash值範圍，key的hash值落在這個範圍內，則順時針沿ring找，碰到的第一個node即爲所需。
Dynamo對Consistent Hashing算法的改進在於：它放在環上作爲一個node的是一組機器（而不是memcached把一臺機器作爲node），這一組機器是通過同步機制保證數據一致的。
有關Dynamo的更多信息請參看：http://baike.baidu.com/view/2982765.html?fromTaglist
Amazon的雲架構圖如下：
以下是運行原理：
工作啓動器——工作從網站或其它軟件子系統進入，在隊列服務中排隊等候處理。工作不一定非是大請求，可以是整個管線中獨立的一小部分。不要把狀態保存到工作執行器裏。把需要做的事打包進工作請求，放回到隊列服務中等候處理。
規劃服務——它是亞馬遜的基礎設施，允許實例根據工作負載自動伸縮。這是與自有的虛擬服務器（VPS）或典型的數據中心方案主要的不同之處。它有一套啓停AMIS的API，以及自動配置、運行VM的機制。
工作執行器——它們從隊列中取出工作，完成具體處理。對SmugMug來說，工作結果存儲在S3之上，但你也可以存儲在自己的數據庫、SimpleDB或其它地方。
隊列服務——隊列存儲工作執行器要接受的工作。SmugMug建立了自己的隊列服務，你也可以直接使用亞馬遜的SQS，用起來同樣簡單。創建一個可伸縮、分佈式、高性能、高可用的隊列服務並非易事，所以你可以考慮一下“Flickr——先完成必不可少的工作，其它的放進隊列”中推薦的大量隊列產品。
控制器——該組件監控工作流相關的大量變量，並以最優化一小組參數爲目標，決定需要多少EC2實例。按需增減實例。
每家供應商都有他們自己的解決方案，預計以後還會出現不同的解決方案。各家的雲都還沒有得到充分的探究，目前都正在緩慢而穩步地推敲着雲的架構解決方案。
好了，有關Amazon架構就介紹到這裏，希望能給路過的朋友一點啓發，謝謝閱讀！
補充：摘自http://www.itivy.com/ivy/archive/2011/8/16/the-architecture-of-amazon.html