Amazon的系統構造閱歷了偉大的變更，從最初的兩層系統構造到供給許多不同運用的散布式疏散服務平臺。

起初，只有一個運用程序與后端交互，這是用C++完成的。

系統構造將隨著時光的推移而發展。多年來，亞馬遜一直將其容量擴大重點放在后端數據庫上，試圖使其容納更多商品數據、更多客戶數據和更多訂單數據，并使其支撐多個國際站點。到2001年，前端運用程序顯然無法再盡力增長容量。數據庫分為許多小部分。環繞每個部件創立一個服務接口，該接口是拜訪數據的唯一方法。

數據庫已逐漸演化為共享資源，因此很難在所有業務的基本上增長容量。前端和后端處置的發展受到很大限制，因為它們被太多不同的團隊和流程共享。他們的系統構造是松散耦合的，并環繞服務構建。面向服務的系統構造供給的隔離使他們能夠迅速、獨立地完成許多軟件組件的開發。

逐漸地，Amazon擁有數百個服務和多個運用程序服務器來聚合服務中的信息。生成http://Amazon.com 站點頁面的運用程序位于這樣的運用程序服務器上。對于供給web服務接口、客戶服務運用程序和賣方接口的運用程序也是如此。

許多第三方技巧難以適應亞馬遜等網站的范圍，尤其是通訊基本設施技巧。它們在必定規模內工作良好，但如果規模擴展，它們將不實用。因此，亞馬遜必需開發自己的根本技巧。不要“掛”在技巧上。Amazon在某些處所應用JBoss/Java，但它只應用服務器，沒有充足應用J2EE中涉及的技巧。用C++開發的程序用于處置要求。per/Mason開發的程序用于生成頁面中的內容。

Amazon不愛好中間件技巧，因為它看起來更像一個框架，而不是一個工具。如果應用中間件，它將受到該中間件所采取的軟件模式的困擾。你只能應用他們的軟件。如果你想應用不同的軟件，這幾乎是不可能的。你被困住了！資訊中間件、數據持久層中間件、Ajax等經常涌現。它們都太龐雜了。如果中間件可以以更小的組件的情勢供給，并且更像是一個工具而不是一個框架，那么它可能對我們更有吸引力。

與Soap相干的web解決計劃似乎愿望再次解決散布式體系的所有問題。

Amazon同時供給soap和RESTWeb服務。大約30%的用戶將soap用作web服務。它們似乎是Java和Java。Net用戶，并應用WSD生成遠程對象接口。大約70%的用戶應用rest。它們似乎是PHP和每個用戶。

無論是應用soap還是rest，開發人員都可以獲得拜訪Amazon的對象接口。開發人員愿望完成這項工作，而不必擔憂網絡電纜上傳輸的內容。

亞馬遜愿望環繞他們的服務樹立一個開放的社區。他們選擇web服務是因為它的簡略性。事實上，它是一個面向服務的系統構造。簡而言之，只能通過接口拜訪所需的數據。這些接口由WSD描寫，但它們采取自己的封裝和傳輸機制。

架構（Architecture）開發團隊是小型團隊，環繞不同的服務組織。在亞馬遜，服務是獨立的功效交付單元。這就是亞馬遜組織內部團隊的方法。

如果你有一個新的商業籌劃書或者想解決一個問題，你可以組織一個團隊。由于溝通成本，每個團隊的人數限制為8~10人。他們被稱為兩支比薩餅隊。因為有了兩個比薩餅，團隊中的每個人都可以吃飽。

團隊范圍很小。他們被授權以任何他們愛好的方法解決問題或改良服務。

例如，他們創立了一個團隊，其職能是在書中查找奇特的單詞和短語。團隊已經為該功效創立了一個單獨的服務接口，并且有權履行他們以為須要履行的任何操作。

安排

他們創立了一個特別的基本設施來管理依附關系和安排服務。

目的是所有準確的服務都可以安排在一臺主機上。所有運用程序代碼、監控機制、允許機制等應位于一個“主機”中。

每個人都有自己的體系來解決這些問題。

安排進程的輸出是一個虛擬機，可以應用EC2運行它們。

從客戶的角度來看服務

為了驗證新服務的后果，值得從客戶的角度來審視服務。

從客戶的角度看服務，關注愿望向用戶供給的價值。

迫使開發人員關注交付給客戶的價值，而不是首先斟酌如何構建技巧，然后再斟酌如何應用技巧。

從用戶將看到的扼要功效開端，然后從客戶的角度檢討您構建的服務是否有價值。

以最小化的設計停止設計進程。如果您想構建一個大型散布式體系，簡略性是癥結。

對于大范圍可擴大體系，狀況管理是核心問題。

在內部，它們可以供給無窮的存儲空間。

并非所有操作都是有狀況的。停止步驟是有狀況的。

通過火析最近單擊的頁面的會話ID，此服務可以向用戶供給推舉產品和建議。

它們跟蹤并存儲所有數據，因此保護狀況不是問題。有一些單獨的狀況須要為會話保護。所供給的服務將始終保存信息，因此您只須要應用這些服務。

Eric brewers的cap理論——或體系的三個屬性

體系的三個屬性：一致性、可用性、網絡分區容差。

對于任何共享數據的體系，它至少具有這三個屬性中的兩個。

網絡分區容差：將節點劃分為小組。它們可以看到其他組，但無法看到所有其他節點。

一致性：寫入一個值，然后讀取它。得到的返回值應當與您寫入的值雷同。分區體系中并非如此。

可用性：不總是可讀寫的。體系可能會告知您無法寫入數據，因為您須要堅持數據一致性。

對于可伸縮性，必需對體系進行分區，因此對于特定的體系，您必需在高一致性或高可用性之間進行選擇。在可用性和一致性之間找到準確的重疊。

依據服務的須要選擇特定的實現辦法。

對于結賬進程，您總是愿望在客戶的購物車中放置更多的商品，因為這可以發生收入。在這種情形下，您須要選擇高可用性。毛病是對客戶隱蔽的，稍后將進行剖析。

當客戶提交訂單時，我們應當更加重視堅持高一致性。因為有幾種不同的服務——信譽卡服務、分銷服務、報告功效等——可以同時拜訪這些數據。

點擊咨詢現在有哪些新興平臺值得關注 >>>

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。