Amazon架構優缺點？

Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分布式的、去中心化的服務平臺，提供許多種不同的應用。

最開始只有一個應用來和后端交互，是用C++來完成的。

架構會隨著時間而演進。多年來，Amazon將增容的主要精力放在后端的數據庫上，試圖讓其容納更多的商品數據，更多的客戶數據，更多的訂單數據，并讓其支持多個國際站點。到2001年，前端應用很明顯不能再做任何增容方面的努力了。數據庫被分為很多個小部分，圍繞每個部分會創建一個服務接口，并且該接口是訪問數據的唯一途徑。

數據庫逐漸演變成共享資源，這樣就很難再在全部業務的基礎之上進行增容操作了。前端與后端處理的演進受到很大限制，因為他們被太多不同的團隊和流程所共享了。

他們的架構是松散耦合的的，并且圍繞著服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟件組件的開發。

逐漸地，Amazon擁有了數百個服務，并有若干應用服務器，從服務中聚合信息。生成http://Amazon.com站點頁面的應用就位于這樣的一臺應用服務器之上。提供web服務接口、顧客服務應用以及賣家接口的應用也都是類似的情況。

許多第三方的技術難以適用Amazon這種網站的規模，特別是通訊基礎架構技術。它們在一定范圍內工作的很好，但是如果范圍再擴大的話，它們就不適用了。因此，Amazon只好自己開發相應的基礎技術。

不在一種技術上"吊死"。Amazon在有的地方使用jboss/Java,不過只是使用servets，并沒有完全使用j2ee中所涉及到的技術。

C++開發的程序被用來處理請求。Per/Mason開發的程序用來生成頁面中的內容。

Amazon不喜歡采用中間件技術，因為它看起來更像一種框架而不是一個工具。如果采用了某種中間件，那么就會被那種中間件所采用的軟件模式所困擾。你也就只能選用他們的軟件。如果你想采用不同的軟件幾乎是不可能的。你被困住了！經常發生的情況就是消息中間件，數據持久層中間件，Ajax等等。它們都太復雜了。如果中間件能夠以更小的組件的方式提供，更像一個工具而不是框架，或許對我們的吸引力會更大一些。

SOAP 相關的web解決方案看起來想再次解決所有分布式系統的問題。

Amazon提供SOAP和REST這兩種Web 服務。大概有30%的用戶采用SOAP這種Web Services。他們看起來似乎是Java和.NET的用戶，而且使用WSD來生成遠程對象接口。大概有70%的用戶使用REST。他們看起來似乎是PHP和PER的用戶。

無論采用SOAP還是REST，開發人員都可以得到訪問Amazon的對象接口。開發人員想要的是把工作完成，而不需要關心網線上傳輸的是什么東西。

Amazon想要圍繞他們的服務構建一個開放的社區。他們之所以選擇Web Services是因為它的簡單。事實上它是一個面向服務的體系架構。簡單來說，你只有通過接口才能訪問到需要的數據，這些接口是用WSD描述的，不過它們采用自己的封裝和傳輸機制。