1號店交易系統架構如何向「高并發高可用」演進

輕量級電商的架構和痛點

大家看上圖，1個輕量級的電商網站利用架構就是這樣的，比如說你現在想做1個電商網站，你是創業公司，兩3個人開始做，估計架構就是這樣的。前端有PC、App和H5，有表現層、業務邏輯層和數據訪問層等。

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

1些輕量級電商網站的架構痛點是甚么？

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

痛點也很多，首先是代碼耦合，1開始可能就1個人就全部弄定了。由于1開始就1、兩個人，不需要那末多。但從業務真個增長來看，1、兩個人進行業務支持就有問題了，業務響應慢，業務相互影響。還有在出現問題時定位很難，有的時候還會責任不清，遇到1些相互扯皮的情況，表現出來的就是系統不穩定。

表結構也非?；靵y，今天來1個業務加1個，明天來個業務又加1個。數據庫單點，也是我們非常大的痛點，1旦數據庫掛了系統就完全崩潰了。

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

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

電商網站演進之路

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

這個例子可以類比我們的架構變化。首先是業務變化，這相當于課程的變化；第2，架構變化，就相當于學校的范圍大了以后，相干的配套設施都要跟上；第3個就是人員擴大了，就是我們的開發保護人員多了，這個時候我們不可能還像之前那樣，幾百號人在那里弄1個工程，你必須要進行分割剝離。

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

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

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

我們的技術團隊也是從1個小團隊發展到上千人的范圍，網站也經歷這樣1個變革，剛開始的時候就是1個簡單的MVC架構，后來這個架構不適應業務的發展和人員范圍了。在35百人的時候我們還是那個架構，很多人在保護1個大的工程項目，常常出問題。

而且剛剛開始的時候是沒有沒有線真個，無線端也是近幾年才開始做起來的。

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

架構演進的準備工作

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

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

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

核心Service計劃

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

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

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

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

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

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

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

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

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

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

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

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

定單水平拆庫

接下來我們談談數據庫。我們最早用的Oracle，很龐大，支持的量也很大，1般的業務量是沒有問題的。但是甚么情況會出問題呢？1個是單點故障，數據庫1掛了，全部網站就全掛了，另外不支持水平擴大，包括它的存儲、性能、數據量，Oracle再利害，它不可能幾百億、幾千億的數據都放進去。所以我們后來選擇了Mysql，對數據庫進行了水平拆分，這樣的話單點故障率會小1點，這么多的物理數據庫，掛1個，其他的還可以運行，不至于影響全局。同時做了水平拆分以后，擴大能力非常強，從理論上來講可以無窮擴大，由于它不過就是加服務器，你只要加1些硬件就能夠了。

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

比如說定單，你第1要斟酌業務場景，查詢定單是哪些用戶：其1是前真個用戶；其2是后真個用戶商家和客服。

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

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

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

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

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

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

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

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

拆庫時怎樣做壓測

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

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

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

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

SOA中間件

我剛剛說了兩個，1個是Service化做了技術架構上的拆分，1個是做了數據庫的水平拆分。這是剛剛提到的準備工作，Service化和水平拆庫的同時，我們的很多中間件技術也發展起來了，由于你的量上來了、架構調劑了，配套設施也要上來，不是說簡單的教室1拆分就完了，學校沒有保安，要上體育課沒有操場是不行的，因此沒有相應的中間件沒有是不行的。

SOA中間件本身也是1個成心思的發展，包括散布式服務SOA中間件、數據庫中間件、緩存平臺、消息中間件、任務調度中間件和全局配置中心等。日志和監控系統也非常有必要，這都是系統穩定的基礎。

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

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

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

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

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

這是我們的核心交易架構，我們如何讓它更完善1些，怎樣讓它的穩定性更高1些？我們有前臺用戶，前臺用戶作為普通消費者去下單、查詢，同時也有很多后臺的操作。

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

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

多活機房架構

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

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

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

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

但數據中心我是否是可以作為后端利用來使用呢？后真個利用走數據中心，由于它對數據的實時性要求相對不是特別高，而前端只保證核心交易業務，后端保證非核心交易業務，這是多活利用架構拆分的思路。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈