解析亞馬遜架構(gòu)技術(shù)！-ESG跨境

Amazon的系統(tǒng)構(gòu)造閱歷了偉大的變更，從最初的兩層系統(tǒng)構(gòu)造到供給許多不同運(yùn)用的散布式疏散服務(wù)平臺(tái)。

起初，只有一個(gè)運(yùn)用程序與后端交互，這是用C++完成的。

系統(tǒng)構(gòu)造將隨著時(shí)光的推移而發(fā)展。多年來，亞馬遜一直將其容量擴(kuò)大重點(diǎn)放在后端數(shù)據(jù)庫上，試圖使其容納更多商品數(shù)據(jù)、更多客戶數(shù)據(jù)和更多訂單數(shù)據(jù)，并使其支撐多個(gè)國際站點(diǎn)。到2001年，前端運(yùn)用程序顯然無法再盡力增長容量。數(shù)據(jù)庫分為許多小部分。環(huán)繞每個(gè)部件創(chuàng)立一個(gè)服務(wù)接口，該接口是拜訪數(shù)據(jù)的唯一方法。

數(shù)據(jù)庫已逐漸演化為共享資源，因此很難在所有業(yè)務(wù)的基本上增長容量。前端和后端處置的發(fā)展受到很大限制，因?yàn)樗鼈儽惶嗖煌膱F(tuán)隊(duì)和流程共享。他們的系統(tǒng)構(gòu)造是松散耦合的，并環(huán)繞服務(wù)構(gòu)建。面向服務(wù)的系統(tǒng)構(gòu)造供給的隔離使他們能夠迅速、獨(dú)立地完成許多軟件組件的開發(fā)。

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

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

Amazon不愛好中間件技巧，因?yàn)樗雌饋砀褚粋€(gè)框架，而不是一個(gè)工具。如果應(yīng)用中間件，它將受到該中間件所采取的軟件模式的困擾。你只能應(yīng)用他們的軟件。如果你想應(yīng)用不同的軟件，這幾乎是不可能的。你被困住了！資訊中間件、數(shù)據(jù)持久層中間件、Ajax等經(jīng)常涌現(xiàn)。它們都太龐雜了。如果中間件可以以更小的組件的情勢供給，并且更像是一個(gè)工具而不是一個(gè)框架，那么它可能對我們更有吸引力。

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

Amazon同時(shí)供給soap和RESTWeb服務(wù)。大約30%的用戶將soap用作web服務(wù)。它們似乎是Java和Java。Net用戶，并應(yīng)用WSD生成遠(yuǎn)程對象接口。大約70%的用戶應(yīng)用rest。它們似乎是PHP和每個(gè)用戶。

無論是應(yīng)用soap還是rest，開發(fā)人員都可以獲得拜訪Amazon的對象接口。開發(fā)人員愿望完成這項(xiàng)工作，而不必?fù)?dān)憂網(wǎng)絡(luò)電纜上傳輸?shù)膬?nèi)容。

亞馬遜愿望環(huán)繞他們的服務(wù)樹立一個(gè)開放的社區(qū)。他們選擇web服務(wù)是因?yàn)樗暮喡孕浴Ｊ聦?shí)上，它是一個(gè)面向服務(wù)的系統(tǒng)構(gòu)造。簡而言之，只能通過接口拜訪所需的數(shù)據(jù)。這些接口由WSD描寫，但它們采取自己的封裝和傳輸機(jī)制。

架構(gòu)（Architecture）開發(fā)團(tuán)隊(duì)是小型團(tuán)隊(duì)，環(huán)繞不同的服務(wù)組織。在亞馬遜，服務(wù)是獨(dú)立的功效交付單元。這就是亞馬遜組織內(nèi)部團(tuán)隊(duì)的方法。

如果你有一個(gè)新的商業(yè)籌劃書或者想解決一個(gè)問題，你可以組織一個(gè)團(tuán)隊(duì)。由于溝通成本，每個(gè)團(tuán)隊(duì)的人數(shù)限制為8~10人。他們被稱為兩支比薩餅隊(duì)。因?yàn)橛辛藘蓚€(gè)比薩餅，團(tuán)隊(duì)中的每個(gè)人都可以吃飽。

團(tuán)隊(duì)范圍很小。他們被授權(quán)以任何他們愛好的方法解決問題或改良服務(wù)。

例如，他們創(chuàng)立了一個(gè)團(tuán)隊(duì)，其職能是在書中查找奇特的單詞和短語。團(tuán)隊(duì)已經(jīng)為該功效創(chuàng)立了一個(gè)單獨(dú)的服務(wù)接口，并且有權(quán)履行他們以為須要履行的任何操作。

安排

他們創(chuàng)立了一個(gè)特別的基本設(shè)施來管理依附關(guān)系和安排服務(wù)。

目的是所有準(zhǔn)確的服務(wù)都可以安排在一臺(tái)主機(jī)上。所有運(yùn)用程序代碼、監(jiān)控機(jī)制、允許機(jī)制等應(yīng)位于一個(gè)“主機(jī)”中。

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

安排進(jìn)程的輸出是一個(gè)虛擬機(jī)，可以應(yīng)用EC2運(yùn)行它們。

從客戶的角度來看服務(wù)

為了驗(yàn)證新服務(wù)的后果，值得從客戶的角度來審視服務(wù)。

從客戶的角度看服務(wù)，關(guān)注愿望向用戶供給的價(jià)值。

迫使開發(fā)人員關(guān)注交付給客戶的價(jià)值，而不是首先斟酌如何構(gòu)建技巧，然后再斟酌如何應(yīng)用技巧。

從用戶將看到的扼要功效開端，然后從客戶的角度檢討您構(gòu)建的服務(wù)是否有價(jià)值。

以最小化的設(shè)計(jì)停止設(shè)計(jì)進(jìn)程。如果您想構(gòu)建一個(gè)大型散布式體系，簡略性是癥結(jié)。

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

在內(nèi)部，它們可以供給無窮的存儲(chǔ)空間。

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

通過火析最近單擊的頁面的會(huì)話ID，此服務(wù)可以向用戶供給推舉產(chǎn)品和建議。

它們跟蹤并存儲(chǔ)所有數(shù)據(jù)，因此保護(hù)狀況不是問題。有一些單獨(dú)的狀況須要為會(huì)話保護(hù)。所供給的服務(wù)將始終保存信息，因此您只須要應(yīng)用這些服務(wù)。

Eric brewers的cap理論——或體系的三個(gè)屬性

體系的三個(gè)屬性：一致性、可用性、網(wǎng)絡(luò)分區(qū)容差。

對于任何共享數(shù)據(jù)的體系，它至少具有這三個(gè)屬性中的兩個(gè)。

網(wǎng)絡(luò)分區(qū)容差：將節(jié)點(diǎn)劃分為小組。它們可以看到其他組，但無法看到所有其他節(jié)點(diǎn)。

一致性：寫入一個(gè)值，然后讀取它。得到的返回值應(yīng)當(dāng)與您寫入的值雷同。分區(qū)體系中并非如此。

可用性：不總是可讀寫的。體系可能會(huì)告知您無法寫入數(shù)據(jù)，因?yàn)槟氁獔?jiān)持?jǐn)?shù)據(jù)一致性。

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

依據(jù)服務(wù)的須要選擇特定的實(shí)現(xiàn)辦法。

對于結(jié)賬進(jìn)程，您總是愿望在客戶的購物車中放置更多的商品，因?yàn)檫@可以發(fā)生收入。在這種情形下，您須要選擇高可用性。毛病是對客戶隱蔽的，稍后將進(jìn)行剖析。

當(dāng)客戶提交訂單時(shí)，我們應(yīng)當(dāng)更加重視堅(jiān)持高一致性。因?yàn)橛袔追N不同的服務(wù)——信譽(yù)卡服務(wù)、分銷服務(wù)、報(bào)告功效等——可以同時(shí)拜訪這些數(shù)據(jù)。

點(diǎn)擊咨詢現(xiàn)在有哪些新興平臺(tái)值得關(guān)注 >>>

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