1號店交易系統(tǒng)架構(gòu)如何向「高并發(fā)高可用」演進(jìn)

輕量級電商的架構(gòu)和痛點(diǎn)

大家看上圖，1個輕量級的電商網(wǎng)站利用架構(gòu)就是這樣的，比如說你現(xiàn)在想做1個電商網(wǎng)站，你是創(chuàng)業(yè)公司，兩3個人開始做，估計(jì)架構(gòu)就是這樣的。前端有PC、App和H5，有表現(xiàn)層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層等。

重量級的電商網(wǎng)站利用架構(gòu)是怎樣重的呢？很簡單，隨著業(yè)務(wù)的擴(kuò)大，業(yè)務(wù)量多了、代碼量多了、數(shù)據(jù)量大了、并發(fā)量高了。1號店是1家電商網(wǎng)站，但嚴(yán)格來說其實(shí)不是百分之百的互聯(lián)網(wǎng)公司，我們更多是業(yè)務(wù)驅(qū)動型而不是技術(shù)驅(qū)動型公司。由于技術(shù)是為業(yè)務(wù)服務(wù)的，反過來講，技術(shù)也能夠驅(qū)動業(yè)務(wù)，如果我們的技術(shù)能力支持不到1號店的業(yè)務(wù)體量的增長，支持不了那末高的并發(fā)量的話，網(wǎng)站很容易就掛了。

1些輕量級電商網(wǎng)站的架構(gòu)痛點(diǎn)是甚么？

首先說它的特點(diǎn)，業(yè)務(wù)高速發(fā)展，業(yè)務(wù)情勢多樣，人員范圍爆增。這里所說的人員更多是技術(shù)人員，1開始是兩3個人，多是面對面的，后來變成幾10人、幾百人乃至是幾千人上萬人的范圍。固然它的要求量、并發(fā)量、數(shù)據(jù)存儲量都非常的高。

痛點(diǎn)也很多，首先是代碼耦合，1開始可能就1個人就全部弄定了。由于1開始就1、兩個人，不需要那末多。但從業(yè)務(wù)真?zhèn)€增長來看，1、兩個人進(jìn)行業(yè)務(wù)支持就有問題了，業(yè)務(wù)響應(yīng)慢，業(yè)務(wù)相互影響。還有在出現(xiàn)問題時定位很難，有的時候還會責(zé)任不清，遇到1些相互扯皮的情況，表現(xiàn)出來的就是系統(tǒng)不穩(wěn)定。

表結(jié)構(gòu)也非?；靵y，今天來1個業(yè)務(wù)加1個，明天來個業(yè)務(wù)又加1個。數(shù)據(jù)庫單點(diǎn)，也是我們非常大的痛點(diǎn)，1旦數(shù)據(jù)庫掛了系統(tǒng)就完全崩潰了。

還有監(jiān)控預(yù)警的問題，這是1個非常大的痛點(diǎn)。我們知道類似支付寶紅包、微信紅包等的監(jiān)控預(yù)警乃至是秒級的，分鐘級確切是不夠用，不可能說發(fā)1個紅包，1分鐘還沒有搶到，用戶會1直不停地戳屏幕，對系統(tǒng)帶來的壓力反而更大。

所以，這個時候我們就需要做1些擴(kuò)大性的工作。最簡單的就是按業(yè)務(wù)擴(kuò)大，1個小公司大概到10個、幾10個人左右，大概會做這樣的工作。如網(wǎng)站上的表現(xiàn)層，1開始頁面代碼都耦合在1起，然后我們會把詳情頁、搜索頁、團(tuán)購辨別，包括域名也會辨別開。漸漸的業(yè)務(wù)多了以后，會把普通購物、團(tuán)購、虛擬業(yè)務(wù)等剝離開來，從數(shù)據(jù)庫層來講，漸漸會把產(chǎn)品、用戶、定單及其他1些業(yè)務(wù)數(shù)據(jù)等都進(jìn)行分拆，主要是從物理上隔離開來。這個時候整體來講，架構(gòu)本身變化不大，只是簡單的切分1下。固然這個時候產(chǎn)品、用戶、定單等這個層面的劃分要有1定的規(guī)則和邊界。

電商網(wǎng)站演進(jìn)之路

1個小網(wǎng)站變成1個大網(wǎng)站是1個架構(gòu)演進(jìn)的進(jìn)程。舉例子來講，現(xiàn)在有1個老師，他講課的時候有很多學(xué)生都在同1個教室，這邊是1年級的，這邊是2年級的，這邊是3年級的，先給1年級講課23年級的自己溫習(xí)做作業(yè)，再給2年級的講課13年級的溫習(xí)做作業(yè)，在前期還能忙過來。但到了1定的時候，學(xué)生開始多了，教室坐不下了。業(yè)務(wù)也多了，我不光教語文、數(shù)學(xué)，我還要教體育、音樂、美術(shù)了，這個時候?qū)W校的范圍大了。學(xué)校的范圍大了以后，相干的配套設(shè)施就要隨著上去。這個時候要有校長、主任、班主任、音樂英語老師…有后勤的，乃至是保潔阿姨，乃至還有食堂了，和大學(xué)1樣了。

這個例子可以類比我們的架構(gòu)變化。首先是業(yè)務(wù)變化，這相當(dāng)于課程的變化；第2，架構(gòu)變化，就相當(dāng)于學(xué)校的范圍大了以后，相干的配套設(shè)施都要跟上；第3個就是人員擴(kuò)大了，就是我們的開發(fā)保護(hù)人員多了，這個時候我們不可能還像之前那樣，幾百號人在那里弄1個工程，你必須要進(jìn)行分割剝離。

那末我們怎樣把它做大？沒有別的路，就是拆分?jǐn)U大，而且擴(kuò)大不能是簡單的橫向擴(kuò)大，不能說來1個業(yè)務(wù)就簡單地按業(yè)務(wù)來拆。由于可能1個業(yè)務(wù)量就非常的大，比如說我們的團(tuán)購體量就非常大，僅僅團(tuán)購業(yè)務(wù)的定單量已很大了，自己本身不能再擴(kuò)了那怎樣辦？從我的總結(jié)來講就是拆，把大的拆成小的，不斷地拆。包括現(xiàn)在提到的微服務(wù)，固然現(xiàn)在微服務(wù)還沒有明確的定義。這和我們的SOA架構(gòu)是分不開的，只不過是1種情勢而已。

現(xiàn)在IT界有很多的概念，就好像敏捷1樣，兩個星期做1個迭代，之前是1個項(xiàng)目做好幾個月。1開始我不太理解甚么是敏捷，有甚么變化呢？我覺得大概就是把大的拆成小的，之前是做兩個月的，我們把它分成N個兩個星期的，在兩個星期的迭代當(dāng)中，你該做的還是逃不了，你還是要做需求分析，做設(shè)計(jì)，做開發(fā)，做測試，做上線。這個進(jìn)程沒有變，只是說把任務(wù)給拆分小了。

在拆的時候，從表現(xiàn)層來看，可以從UI展現(xiàn)和UI邏輯上進(jìn)行拆分。在邏輯層上，比如說你要提交定單，在提交定單后面的操作包括有定單的服務(wù)、接口，這是我們的后端業(yè)務(wù)邏輯控制層。拆的時候，原來業(yè)務(wù)邏輯和數(shù)據(jù)訪問都在1層，大家知道，之前在JSP上可以在頁面上直接去連數(shù)據(jù)庫進(jìn)行DB操作。 我們從業(yè)務(wù)邏輯層進(jìn)行拆分，拆分成控制層和Service層及數(shù)據(jù)庫操作層。Service層就觸及到剛剛講到的微服務(wù)，而Service層也分為復(fù)雜的Service和簡單的Service?；A(chǔ)Service層相對來講業(yè)務(wù)邏輯比較單1，但是又相對照較完全，聚合Service則包括了完全的業(yè)務(wù)邏輯。

我們的技術(shù)團(tuán)隊(duì)也是從1個小團(tuán)隊(duì)發(fā)展到上千人的范圍，網(wǎng)站也經(jīng)歷這樣1個變革，剛開始的時候就是1個簡單的MVC架構(gòu)，后來這個架構(gòu)不適應(yīng)業(yè)務(wù)的發(fā)展和人員范圍了。在35百人的時候我們還是那個架構(gòu)，很多人在保護(hù)1個大的工程項(xiàng)目，常常出問題。

而且剛剛開始的時候是沒有沒有線真?zhèn)€，無線端也是近幾年才開始做起來的。

后來要做無線端，怎樣辦？把PC真?zhèn)€代碼包復(fù)制1份給無線端用，這個時候問題就不斷的來了，由于PC真?zhèn)€邏輯不可能完全符合無線真?zhèn)€要求。

架構(gòu)演進(jìn)的準(zhǔn)備工作

這樣我們開始做比較大的架構(gòu)層面的計(jì)劃，最大的1個就是業(yè)務(wù)邏輯層的拆分-SOA服務(wù)化，另外一個是DB層的水平拆庫。拆分以后，理論上它就具有了無窮的擴(kuò)大能力，比如說定單庫，我可以把它依照1定的維度，去拆成很多的定單庫。

拆分和解耦是分不開的，1方面是代碼和業(yè)務(wù)的解耦，另外一方面對人員和工作來講也是1種解耦。一樣還要做1些異步工作，由于之前業(yè)務(wù)特別重，下單流程非常長，操作步驟非常多，但是很多東西其實(shí)不是用戶都要馬上關(guān)注的。比如說下單給用戶送積分，這個積分其實(shí)不是說下單的時候必須馬上就要給到客戶的，可以略微延遲幾秒乃至是幾分鐘，它不應(yīng)當(dāng)影響下單業(yè)務(wù)。但是如果由于積分出現(xiàn)問題，致使下單出現(xiàn)問題那就是本末顛倒了。因此我們做了異步，它掛了，我們可以做補(bǔ)償。

固然有1些是不能做異步的，比如說積分兌換商品的定單，下單時要去扣積分，由于積分就是錢，我們還有禮品卡支付，這個是不能做異步的。我記得之前有過1個例子，好像是1個網(wǎng)站用積分可以充話費(fèi)，結(jié)果話費(fèi)充成功了，積分沒扣，就變成了可以無窮的充?，F(xiàn)在是互聯(lián)網(wǎng)時期，信息散布的很快，聽說1兩個小時就是幾個億的損失。還有讀寫分離，讀和寫是可以完全分開的。為了保證下單的流暢，我們把讀和寫分開，在不同的庫里進(jìn)行讀和寫，這樣可以很大地減輕下單壓力。

核心Service計(jì)劃

這張圖是我們核心Service的計(jì)劃。大家想象1下1個電商網(wǎng)站有哪些基本特點(diǎn)，哪怕你的網(wǎng)站上只有1個頁面1個商品，比如說你只賣蘋果手機(jī)或是小米手機(jī)，網(wǎng)站就1個頁面顯示這個商品，你點(diǎn)商品就能夠直接進(jìn)行購物。首先它要有商品的描寫信息，第2是商品的價(jià)格，第3是商品的庫存，固然庫存數(shù)字你可以不顯示，有就賣，沒有就不賣，以上這些是商品基本的信息。

有了商品的信息，如果你想買這個商品，你要先注冊用戶，注冊用戶以后要登陸，這是用戶信息；然后你就能夠下單了，生成1個定單，定單以后是對定單進(jìn)行相應(yīng)的物流信息跟蹤。同時也能夠做線上支付，固然你也能夠只做貨到付款不做線上支付。

這是1個電商網(wǎng)站最基本的核心要素。1個是產(chǎn)品，第2個是用戶&支付，再就是定單。這3大塊構(gòu)成了1個電商網(wǎng)站最核心的3個部份，這就是我們核心Service的架構(gòu)計(jì)劃，捉住核心是服務(wù)化的重要理念。從Service角度來講，產(chǎn)品服務(wù)、價(jià)格服務(wù)相對來講比較簡單和單1，對產(chǎn)品的價(jià)格來講用戶主要是查；但是對定單來講，我們把庫寄存到定單這個層面來，而不是放到產(chǎn)品上，是由于庫存和定單是息息相干的，生成定單的時候要扣庫存的，庫存不足的話，定單是沒法完成的。

剛開始的時候我們沒有服務(wù)化，定單有兩個問題：第1個是寫，生成定單。寫的業(yè)務(wù)是很多的，比如說加購物車生成定單，充值是1種業(yè)務(wù)的定單，電子卡是1種業(yè)務(wù)的定單，都在寫；第2個是讀，定單寫了以后，用戶要來讀、后真?zhèn)€客服商家也在讀。

讀不是簡單的僅僅讀定單表，還有很多其他的關(guān)聯(lián)表。比如說抽獎有抽獎系統(tǒng)有自己的很多表，抽完獎給用戶發(fā)1個獎品，就生成1個定單，但抽獎系統(tǒng)要知道哪個用戶是通過甚么樣的方式取得這個定單、定單里有甚么東西，必定要關(guān)聯(lián)查詢。所以定單查詢是非常復(fù)雜的，有沒有數(shù)的點(diǎn)可以查，而且這個查詢1定是有沒有數(shù)張表可以關(guān)聯(lián)查的，乃至是跨表、跨庫的。

那末Service怎樣做呢？如果說我把所有的定單相干表都關(guān)聯(lián)起來，都納入到Service范圍的話，基本上可以把70%⑻0%的業(yè)務(wù)都納入其中了。由于幾近所有的業(yè)務(wù)都要圍繞定單來轉(zhuǎn)，所以Service化1定要有1個邊界。邊界是甚么？比如說我剛剛說的，你抽獎的信息我關(guān)不關(guān)心呢？如果說我關(guān)心的話，你的抽獎業(yè)務(wù)就納入進(jìn)來了。這就是1個邊界，所以我只能只關(guān)心我的定單，這就是定單的邊界。

上圖這句話我覺得說的非常好。1個出色的演講1定要很短，1定也要很長。這對我們來講是非常成心義的。這1塊來說怎樣樣很短，怎樣樣又很長？

回到核心Service的規(guī)則。既要很短，又要很長，比如說定單的生成，它有很多的業(yè)務(wù)，要給客戶積分，要生成定單表數(shù)據(jù)，要把抵用券扣掉，還有相干的支付信息，這些業(yè)務(wù)是不能剝離開來，必須要融會在1起，這當(dāng)中要包括所有的能想到的業(yè)務(wù)場景，因此在定單生成業(yè)務(wù)上，我們要做到足夠長，把所有的業(yè)務(wù)都包括進(jìn)來。有1些是需要同步的，有1些是需要異步的，但是不管是同步還是異步的，我們都要納入進(jìn)來。

但對查詢來講，業(yè)務(wù)是可以分開的，比如商品詳情頁，可能先是調(diào)商品的基本信息Service，然后再去調(diào)價(jià)格信息Service，然后再調(diào)用庫存服務(wù)Service，生成1個頁面需要很多的服務(wù)，這些服務(wù)可以是各自獨(dú)立的，所以在查詢Service上，我們可以做的很短。價(jià)格、庫存等都可以做成獨(dú)立的業(yè)務(wù)Service單元。

固然獨(dú)立其實(shí)不1定是最簡單，它也要有自己完全的業(yè)務(wù)邏輯。比如庫存其實(shí)不是簡單地看庫存表里的數(shù)字是大于0還是小于0的問題，比如是說某1個地方銷售不銷售，或說我們雖然有庫存，我們現(xiàn)在是不賣它的，這些都是庫存，庫存不是1個簡單的數(shù)字，如果說這個商品暫時不賣，我就顯示說無庫存，但是我的倉庫里是有實(shí)物庫存的。

我理解所謂的微服務(wù)，在底層這1塊更多像微服務(wù)，微服務(wù)是否是拆分的越多越好，也不1定。比如說庫存，如果看這個商品有無庫存，首先你調(diào)1個服務(wù)看這個商品是否是在這個區(qū)域里賣，再調(diào)1個服務(wù)看商品是否是上架，再調(diào)1個服務(wù)看庫存是否是大于0，那就太多了。

舉個例子，打開1個詳情頁會調(diào)用很多的服務(wù)，類目信息、商品信息、價(jià)格信息、庫存信息、評論等等。這么多服務(wù)，怎樣保證性能呢，如果拆的非常細(xì)的話，僅1個庫存服務(wù)就能夠拆成7、8個子服務(wù)，這樣的話服務(wù)就要調(diào)78次，網(wǎng)絡(luò)交互也是78次，單個Service性能再好又怎樣樣呢？哪怕你的服務(wù)性能到達(dá)1毫秒，夠快了吧，你調(diào)用10次要10毫秒，調(diào)用100次要100毫秒，你的性能還是在降落，所以其實(shí)不是越微越好，這個長和短的粒度要劃分好。記住兩個關(guān)鍵詞：邊界和粒度。

定單水平拆庫

接下來我們談?wù)?a href="http://www.jyygyx.com/db/" target="_blank">數(shù)據(jù)庫。我們最早用的Oracle，很龐大，支持的量也很大，1般的業(yè)務(wù)量是沒有問題的。但是甚么情況會出問題呢？1個是單點(diǎn)故障，數(shù)據(jù)庫1掛了，全部網(wǎng)站就全掛了，另外不支持水平擴(kuò)大，包括它的存儲、性能、數(shù)據(jù)量，Oracle再利害，它不可能幾百億、幾千億的數(shù)據(jù)都放進(jìn)去。所以我們后來選擇了Mysql，對數(shù)據(jù)庫進(jìn)行了水平拆分，這樣的話單點(diǎn)故障率會小1點(diǎn)，這么多的物理數(shù)據(jù)庫，掛1個，其他的還可以運(yùn)行，不至于影響全局。同時做了水平拆分以后，擴(kuò)大能力非常強(qiáng)，從理論上來講可以無窮擴(kuò)大，由于它不過就是加服務(wù)器，你只要加1些硬件就能夠了。

那末水平拆分怎樣拆？要斟酌哪些因素？

比如說定單，你第1要斟酌業(yè)務(wù)場景，查詢定單是哪些用戶：其1是前真?zhèn)€用戶；其2是后真?zhèn)€用戶商家和客服。

第2，它的存儲量，定單的數(shù)據(jù)量是非常大的。但對商品和庫存來講，它是有1定的范圍的，不會無窮的大，由于1個網(wǎng)站或1個商店，你賣的SKU數(shù)量是有限的。1個大超市多是幾萬個SKU，1個小門店多是幾百個，它不會無窮擴(kuò)大的。

數(shù)據(jù)增量也是如此，1個大超市賣的SKU也就是幾萬個，電商平臺多是百萬級千萬級，但是它也不是無窮增長的，這更多取決于商家的體量，所以它的數(shù)據(jù)量即便有增長也是非常緩慢的。這和定單不1樣，定單是幾何式的增長。

再看讀和寫，定單、庫存的讀和寫頻率都很高。但是對商品、價(jià)格來說，讀肯定是很高的，由于不停地在閱讀，但是寫是很少的，改價(jià)格的機(jī)率很低，不停地改商品信息的機(jī)率也是很低的。

另外是事務(wù)的1致性。對定單和庫存1定是要保持1致性，商品信息寫的話比較少，不太觸及到事務(wù)，除非是批量修改，相對來講事務(wù)性1致性略微弱1些。

還有緩存，庫存可以有緩存，但是緩存的時間是很短的，庫存的緩存時效不多是以天、以小時為級別的，幾分鐘級別已是不錯了。很多時候前端顯示還是有庫存，后面可能已沒有了，所以庫存有時效性的要求。但為了減輕數(shù)據(jù)庫壓力，在前端展現(xiàn)會有庫存的緩存，比如有時候大家會遇到，在閱讀的時候發(fā)現(xiàn)它是有庫存的，但是下單就沒有了，那就是由于前端是緩存的，但是下單的是實(shí)時的庫存，已沒有了。但對商品和價(jià)格信息來講，緩存時效就能夠長1些，可以通過緩存技術(shù)減輕數(shù)據(jù)庫的壓力。

熱門數(shù)據(jù)也是1樣的。數(shù)據(jù)庫的水平拆分怎樣拆，從哪些維度去拆，比如說定單，可以有幾個維度，你可以根據(jù)定單號去拆，根據(jù)產(chǎn)用戶、商家去拆。對響應(yīng)速度來講，用戶要求響應(yīng)速度是最高的；而對商家來講，用戶下完定單以后，略微延遲1會兒他也能接受。

如果依照用戶去拆，熱門數(shù)據(jù)的幾率就很低，很難出現(xiàn)1個用戶1下子出現(xiàn)幾千個幾萬個定單；但是如果按對商家來拆，有1些大的商家，1個雙101可能幾個小時就有上千萬的單，這個量就非常大。

而對商品信息來講，如果說你的量沒有像天貓、淘寶級別的話，并且主要是靠緩存來讀，1般的電商網(wǎng)站，是不需要拆分的。

拆庫時怎樣做壓測

在做定單水平拆庫的時候，不可能網(wǎng)站停下來去做這個項(xiàng)目，所以我們說是飛機(jī)開的時候換發(fā)動機(jī)，在汽車跑的時候換輪胎。我們在做數(shù)據(jù)庫拆庫的時候要做壓測。怎樣做壓測呢？

Oracle改Mysql的時候，當(dāng)時我們對性能是沒有絕對的信心的，由于Mysql的硬朗性沒有Oracle強(qiáng)大，有1次1個badsql直接把我們的1個mysql數(shù)據(jù)庫給弄掛了，對性能要求特別高，但是在業(yè)務(wù)層，我們很難去摹擬。我們可以在Service或sql上1步1步的分析，1步1步的優(yōu)化，但是畢竟有很多業(yè)務(wù)場景是摹擬不出來的。

當(dāng)時我們做了Tcpcopy壓測，原理就是把線上要求的包抓下來，放到測試環(huán)境中，測試的數(shù)據(jù)庫盡可能保持和線上1致，保持環(huán)境1致。壓測會動態(tài)調(diào)劑流量，把原來的流量比如說1小時千萬級的提升到億級的，提升了很多倍，主要是測試看能不能把數(shù)據(jù)庫壓垮，會不會出現(xiàn)問題。

固然這個場景也不可能完全覆蓋我們的現(xiàn)實(shí)利用場景，由于在線上抓包的時候，我們抓了1天，但這1天中數(shù)據(jù)庫的數(shù)據(jù)是不斷變化，不斷有insert和update，而線下的測試數(shù)據(jù)是1個靜態(tài)的數(shù)據(jù)，所以還有1些業(yè)務(wù)場景我們是摹擬不到的。因此摹擬結(jié)果和線上還是有1定的差距，但還是給我們吃了1顆很大的定心丸。

SOA中間件

我剛剛說了兩個，1個是Service化做了技術(shù)架構(gòu)上的拆分，1個是做了數(shù)據(jù)庫的水平拆分。這是剛剛提到的準(zhǔn)備工作，Service化和水平拆庫的同時，我們的很多中間件技術(shù)也發(fā)展起來了，由于你的量上來了、架構(gòu)調(diào)劑了，配套設(shè)施也要上來，不是說簡單的教室1拆分就完了，學(xué)校沒有保安，要上體育課沒有操場是不行的，因此沒有相應(yīng)的中間件沒有是不行的。

SOA中間件本身也是1個成心思的發(fā)展，包括散布式服務(wù)SOA中間件、數(shù)據(jù)庫中間件、緩存平臺、消息中間件、任務(wù)調(diào)度中間件和全局配置中心等。日志和監(jiān)控系統(tǒng)也非常有必要，這都是系統(tǒng)穩(wěn)定的基礎(chǔ)。

還有實(shí)時的分析系統(tǒng)，比如說雙101，大家都關(guān)注著淘寶的數(shù)字，那個數(shù)字是怎樣出來的，1定是實(shí)時出來的，你不能說到了第2天才告知人家前1天晚上1點(diǎn)的時候是甚么樣的數(shù)據(jù)，1定是剛過1點(diǎn)就馬上就都出來了。

一樣還要做灰度發(fā)布，甚么叫高可用，就是不出問題系統(tǒng)1直處于可用狀態(tài)。但我們還要發(fā)布啊，發(fā)布的時候怎樣辦，所以灰度發(fā)布的價(jià)值就體現(xiàn)出來了，有了它我們的系統(tǒng)就有了100%可用的理論可能。

這是我們的1個簡單的架構(gòu)圖。提交定單的時候，可以同步也能夠異步提交，異步走的是秒殺系統(tǒng)，它不是提交以后馬上生成定單，而是要有排隊(duì)系統(tǒng)進(jìn)行排隊(duì)的。我剛剛在前面還說過負(fù)載均衡，我們開發(fā)了自己的SOA中間件做負(fù)載均衡，它有自己的邏輯控制，購物流程到到定單服務(wù)是通過SOA中間件做負(fù)載均衡和調(diào)用的。

同時我們還有數(shù)據(jù)庫中間件，我們和數(shù)據(jù)庫的交互怎樣辦？1個定單查詢，如何定位到它所在的數(shù)據(jù)庫。如果是根據(jù)用戶維度拆庫，用戶來查詢馬上可以定位到相應(yīng)的數(shù)據(jù)庫，但是商家來查詢怎樣辦？他的定單多是覆蓋所有的數(shù)據(jù)庫，這個時候需要做1些聚合、排序。這就要通過數(shù)據(jù)庫中間件，它對前端是透明的，它去做1些排序等，利用層只須常規(guī)的寫自己的SQL就好了。

一樣，我們還有消息中間件，比如前面提到的下單后送積分，就能夠通過消息異步處理。

這是我們的核心交易架構(gòu)，我們?nèi)绾巫屗晟?些，怎樣讓它的穩(wěn)定性更高1些？我們有前臺用戶，前臺用戶作為普通消費(fèi)者去下單、查詢，同時也有很多后臺的操作。

比如對消費(fèi)者來講，下完單后要做支付，固然他可能會定單取消，要把定單變成取消狀態(tài)；再1個他會修改收貨地址，也就是這些簡單的幾個update操作。而后真?zhèn)€，運(yùn)營也好，客服也好，對這個定單是有很多的操作的?？赡苓€有審核系統(tǒng)，還有發(fā)貨、出庫等等的系統(tǒng)都要對定單進(jìn)行操作，因此我們后真?zhèn)€反而是更復(fù)雜的。后真?zhèn)€操作必定會影響到數(shù)據(jù)庫，如果不注意也會出現(xiàn)很多的問題，把數(shù)據(jù)庫夯住了，影響了前真?zhèn)€交易。

Service層可以不斷的拆，但從用戶層角度來講，還是要斟酌前端和后真?zhèn)€拆開。比如代碼可之前端1套，后端1套，把它物理隔離開。我們主要目的是保前真?zhèn)€交易，后端系統(tǒng)略微延遲1點(diǎn)沒有問題的，但是大家看到，前后端代碼物理上雖然隔開了，但是DB還是在1起，后端寫的代碼把數(shù)據(jù)庫弄掛了，前端還是照樣掛，這是1個很大的問題。

多活機(jī)房架構(gòu)

最后說1下多活，多活的架構(gòu)比較大，可以專門作為1個主題來，我這里只是給大家引伸1下。

剛剛講到，前端用戶、后端用戶雖然代碼甚么的可以隔開，但是DB這1層還是在1起。因此我們也要想辦法把DB分開，但這個時候，兩個DB的數(shù)據(jù)要保持同步，固然我今天說的只是1個思路而不是解決方案。

這是我在網(wǎng)上搜來的1張雙活的圖，想一想雙活和多活實(shí)際上是1樣的。我們可以有不同的機(jī)房，也能夠在1個機(jī)房內(nèi)部有多個獨(dú)立的單元，多個機(jī)房或單元物理獨(dú)立。這樣的話，1定要有1個統(tǒng)1的數(shù)據(jù)中心，這兩個數(shù)據(jù)要同步，由于前端用戶下完單以后，商家在看定單的時候，不可能要看這邊的定單到這個系統(tǒng)，要看那邊定單到另外1個系統(tǒng)去看，因此必須要有數(shù)據(jù)中心。如果說我們有多個機(jī)房，多是3個5個，像淘寶的級別就是非常多的機(jī)房。我理解它1定要有1個數(shù)據(jù)中心把數(shù)據(jù)匯總起來。

固然我這是從利用層來講，從利用隔離的角度去看的。多活的目的不是簡單的隔離，它斟酌的是1旦產(chǎn)生地震、災(zāi)害等如何保證不出問題，這個時候數(shù)據(jù)中心對多活也是必要的。

但數(shù)據(jù)中心我是否是可以作為后端利用來使用呢？后真?zhèn)€利用走數(shù)據(jù)中心，由于它對數(shù)據(jù)的實(shí)時性要求相對不是特別高，而前端只保證核心交易業(yè)務(wù)，后端保證非核心交易業(yè)務(wù)，這是多活利用架構(gòu)拆分的思路。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈