互聯(lián)網(wǎng)電商系統(tǒng)架構(gòu)介紹

1、 互聯(lián)網(wǎng)電商系統(tǒng)架構(gòu)介紹聊聊架構(gòu) 微信號(hào) archtime功能介紹 在這里煮酒聊架構(gòu)。背景 說起架構(gòu)，大多人想到的是技術(shù)語言、技術(shù)框架、SOA、微服務(wù)、中間件等，這些都是純粹的系統(tǒng)架構(gòu)或基礎(chǔ)架構(gòu)，它們基本不受業(yè)務(wù)影響，大多可以獨(dú)立于具體業(yè)務(wù)進(jìn)行開發(fā)和發(fā)展，形成自己獨(dú)立的體系甚至標(biāo)準(zhǔn)化的技術(shù)產(chǎn)品。但實(shí)際上大多情況下 技術(shù)是為業(yè)務(wù)服務(wù) 的，我們開發(fā)的更多的是應(yīng)用系統(tǒng)或者稱之為業(yè)務(wù)系統(tǒng)，業(yè)務(wù)的不同特點(diǎn)決定了應(yīng)用（業(yè)務(wù)）架構(gòu)也必然有不同的特點(diǎn)。而這些不同的特點(diǎn)單純靠技術(shù)肯定解決不了，應(yīng)用架構(gòu)設(shè)計(jì)的一條重要原則是 技術(shù)中立，所以更多時(shí)候我們要從應(yīng)用的角度而不是技術(shù)的角度去考慮問題。我做過電商核心交易相關(guān)

2、系統(tǒng)，提起電商大家想到的自然是 PV、UV、高性能、高并發(fā)、高穩(wěn)定、搶購秒殺、訂單、庫存、分布式事務(wù) 等。這里的每一個(gè)點(diǎn)初聽起來都充滿著高深與神秘，以關(guān)心較多的秒殺為例（1000 萬人秒殺 100 塊100g 的金條）我們來分析看看。常規(guī)秒殺架構(gòu) 常規(guī)架構(gòu)如下 常規(guī)流量分布模型 展示層流量 應(yīng)用層流量 服務(wù)層流量 DB 層流量超 NB 的系統(tǒng)流量分布模型如下 展示層流量 = 應(yīng)用層流量 = 服務(wù)層流量 = DB 層流量我們知道 DB 是系統(tǒng)最底層也是流量的最大瓶頸，從上面幾個(gè)圖可以看到，超 NB 的公司解決了 DB 瓶頸所有流量可以一路直到 DB 層，每一層都可以任意擴(kuò)展，那么系統(tǒng)的壓力就可以

3、輕松化解。當(dāng)然一些沒有經(jīng)驗(yàn)的系統(tǒng)也是這么做的，但 DB 層甚至其他層擴(kuò)展做不好，所以系統(tǒng)經(jīng)常掛。而實(shí)際上再 NB 的公司也不會(huì)這么去做，即使技術(shù)上能做到也沒有必要，因?yàn)?代價(jià)實(shí)在太大。所以我們要從 DB 層之前想辦法梯形 逐層進(jìn)行流量過濾，也就成了上邊看到的常規(guī)流量分布模型，最好的結(jié)果就是到 DB 層流量只有實(shí)際的訂單數(shù) 100（100 塊金條）。秒殺流量過濾常規(guī)思路 回到常規(guī)流量分布模型，以下是一個(gè)常用的秒殺系統(tǒng)流量過濾過程：如果純考慮技術(shù)極致，那簡(jiǎn)單，把 DB 層的問題解決就好了，讓 DB 可以象應(yīng)用層和服務(wù)層一樣隨時(shí)分布式擴(kuò)展，可實(shí)際上 DB 做不到，DB 是最大的瓶頸，所以才有了 排隊(duì)

4、系統(tǒng) 和 預(yù)約系統(tǒng)。緩存是一定要用到的，但秒殺往往是瞬間的事，緩存的時(shí)效性導(dǎo)致緩存系統(tǒng)在這樣的大流量對(duì) DB 的瞬間沖擊時(shí)幾乎沒有幫助。如對(duì)秒殺商品的庫存更新使得大量的 udpate sql 直接到了 DB，DB 壓力非常大。我們嘗試了在 mysql 下先 select，有庫存時(shí)再 update，效果比較明顯，特別是秒殺單 sku 或少量 sku 的場(chǎng)景，因?yàn)?select 和 update 對(duì) DB 的壓力大家懂的，有興趣的可以自行測(cè)試下看。排隊(duì)系統(tǒng)是目前大多秒殺場(chǎng)景最常用的，本質(zhì)是 異步處理放緩流量、削平瞬間峰值，降低對(duì)后續(xù)服務(wù)層和 DB 層的流量沖擊。預(yù)約系統(tǒng)的作用在于 提前預(yù)知流量，雖

5、然預(yù)約量本身不可控，但秒殺前可以針對(duì)已知流量提前做好預(yù)案，讓 系統(tǒng)處于可控狀態(tài)。預(yù)約 + 排隊(duì) 的方式已經(jīng)可以滿足大多搶購秒殺場(chǎng)景的需要。秒殺流量過濾來點(diǎn)新思路 預(yù)約和排隊(duì)畢竟是 外掛系統(tǒng)，各層之間是否有必要做好自己的預(yù)案和防范呢，我們?cè)偕蟼€(gè)圖逐層來看看想點(diǎn)辦法：DB 層 DB 層不能任意或隨時(shí)擴(kuò)展，是最大的瓶頸和最后的底線，是絕對(duì)不能破的，一是 DB 并發(fā)連接不能超過最大連接數(shù)，二是 DB 壓力不能太大，所以流量必須在前端控制。服務(wù)層 服務(wù)層雖然可以分布式擴(kuò)展，但受限于 DB 連接，并不意味著可以無限擴(kuò)展。如果是公共服務(wù)層不區(qū)分秒殺業(yè)務(wù)和普通業(yè)務(wù)，是不好做流量過濾的，因?yàn)闀?huì)影響到普通業(yè)務(wù)的正

6、常流量，這種情況下只能從應(yīng)用層想辦法。如果是單獨(dú)為秒殺流程服務(wù)，或者說流量來源能區(qū)分出秒殺業(yè)務(wù)或其他業(yè)務(wù)的，那還是有思路的，辦法總比困難多，如：隨機(jī)數(shù)過濾將一定百分比的用戶請(qǐng)求直接過濾返回給應(yīng)用層包裝，以友好的方式返回提示給用戶。預(yù)設(shè)閥值限流設(shè)定單機(jī)在單位時(shí)間的處理最大閥值，如單機(jī)的實(shí)際處理能力 TPS 最大是 10000/ 秒，設(shè)定閥值為 20，當(dāng)單機(jī)單位時(shí)間內(nèi)（秒）的并發(fā)請(qǐng)求達(dá)到閥值時(shí)，后續(xù)請(qǐng)求直接返回給應(yīng)用層，以友好的方式返回提示給用戶。此時(shí)系統(tǒng)并不處理業(yè)務(wù)邏輯和進(jìn)行 DB 操作，只是簡(jiǎn)單地判斷和響應(yīng)返回，所以單機(jī)的處理能力 20+X 是遠(yuǎn)大于 10000/ 秒的。注：上述兩種方法 并不

7、是 串行或有依賴的，兩者都是一種可選的方法，它們的本質(zhì)都是 流量過濾 和 提升單機(jī)處理能力 保護(hù)系統(tǒng)以免被沖垮。在保證一定用戶體驗(yàn)（單機(jī)處理能力）的情況下將流量過濾最大化，如第 2 種方案中單機(jī)僅 20 的流量能到 DB 層，保證 DB 層絕對(duì)沒問題，如果服務(wù)層壓力依然大，可以繼續(xù)加分布式服務(wù)器和降低預(yù)設(shè)閥值。第 2 種方案實(shí)際上是第 1 種的升級(jí)版，更可控。應(yīng)用層 1、隨機(jī)數(shù)過濾，同上。2、預(yù)設(shè)閥值限流，設(shè)定單機(jī)在單位時(shí)間的處理最大閥值，同上。3、通過 Tomcat 最大連接數(shù)控制，超過最大連接數(shù)的請(qǐng)求 直接拒絕服務(wù)，但用戶體驗(yàn)很不好，系統(tǒng)假死崩潰的感覺，盡量通過加分布式服務(wù)器的方式解決。（

8、服務(wù)層一定要通過應(yīng)用層控制不能超過最大連接數(shù)，展示層和應(yīng)用層直接取決于用戶量，很難控制，可以使用預(yù)約系統(tǒng)讓流量可控）展示層 隨機(jī)數(shù)過濾，將一定百分比的流量請(qǐng)求直接以友好的方式提示給用戶。正常講展示層是 不應(yīng)該過濾 的，請(qǐng)求都沒有到服務(wù)器 攤手，但從業(yè)務(wù)角度看，搶購秒殺本身就是一個(gè)概率事件，并不是完全取決于先后順序 (有時(shí)后來的反而能搶到，這取決于分布式服務(wù)器處理、網(wǎng)絡(luò)、排隊(duì)系統(tǒng)的異步處理等)。雖然對(duì)技術(shù)人來說欺騙用戶的感覺很不恥，但關(guān)鍵時(shí)刻偶爾抱一下佛腳也是一種辦法，總比系統(tǒng)被沖垮了好。以上說的對(duì)幾個(gè)層的處理，并不是很好的方案或架構(gòu)，只是想說明，一個(gè)小的思路或方案就可能解決不少問題，完全靠技術(shù)

9、我們不一定能解決的了，而這些架構(gòu)或方案與高深的技術(shù)本身并無太多直接關(guān)系。對(duì)分布式事務(wù)的思考 再說一個(gè)例子。很多人非常關(guān)心怎么保證分布式事務(wù)，特別是異構(gòu)系統(tǒng)和異構(gòu) DB，我也知道至少目前還沒有很好的技術(shù)手段來 徹底解決 這個(gè)問題，目前通用的方式就是回滾和補(bǔ)償。當(dāng)然很多人還少做了一招，即 數(shù)據(jù)對(duì)賬，但凡沒有事后進(jìn)行回滾補(bǔ)償或數(shù)據(jù)對(duì)賬的架構(gòu)方案，在分布式事務(wù)的最終數(shù)據(jù)一致性上都會(huì)有問題，畢竟這是異構(gòu)的系統(tǒng)或 DB。如圖：如果說秒殺還有些技術(shù)要求，那這里的分布式事務(wù)處理方案技術(shù)含量更少，只要 把細(xì)節(jié)做好(回滾、補(bǔ)償、對(duì)賬)，數(shù)據(jù)的準(zhǔn)確性依舊 100%。然而我們很多人把重點(diǎn)放在了分布式事務(wù)架構(gòu)或技術(shù)方案

10、，過于追求極致忽略或不削于這些容易的細(xì)節(jié)，系統(tǒng)反而問題不斷，無安寧之日。某品牌手機(jī)為追求極致在一款高端手機(jī)上采用了特殊工藝的后蓋技術(shù)，結(jié)果因?yàn)榧夹g(shù)原因?qū)е略摵笊w良品率低產(chǎn)量低，反而影響了核心產(chǎn)品手機(jī)的正常銷售量，得不償失。兩者有異曲同工之妙吧。總結(jié) 應(yīng)用架構(gòu)很容易也很難，容易的在于 不需過多關(guān)注技術(shù)實(shí)現(xiàn)，難的在于 必須根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景和業(yè)務(wù)需要及時(shí)間、成本、資源等給出當(dāng)下最合適、一定不是最完美的架構(gòu)方案。之前看過關(guān)于架構(gòu)是設(shè)計(jì)出來的還是演進(jìn)來的的討論，其實(shí)這個(gè)也簡(jiǎn)單，在某個(gè)特定的階段或時(shí)間點(diǎn)，如系統(tǒng)初期，它一定是設(shè)計(jì)出來的。但縱觀一個(gè)系統(tǒng)的架構(gòu)歷程，或者說一定要在兩者間選擇一個(gè)的話，它一定是 演進(jìn)而來 的。所有的大型互聯(lián)網(wǎng)系統(tǒng)在初期一定不是設(shè)計(jì)成現(xiàn)在這個(gè)樣子的，都是伴隨著業(yè)務(wù)從小到大、從少到多、從簡(jiǎn)單到復(fù)雜的過程演進(jìn)而來，架構(gòu)