大型電商項目的服務(wù)端架構(gòu)
我們以淘寶架構(gòu)為例，了解下大型電商項目的服務(wù)端架構(gòu)是怎樣的，如圖所示：
上面是一些安全體系系統(tǒng)，如數(shù)據(jù)安全體系、應(yīng)用安全體系、前端安全體系等。
中間是業(yè)務(wù)運營服務(wù)系統(tǒng)，如會員服務(wù)、商品服務(wù)、店鋪服務(wù)、交易服務(wù)等。
還有共享業(yè)務(wù)，如分布式數(shù)據(jù)層、數(shù)據(jù)分析服務(wù)、配置服務(wù)、數(shù)據(jù)搜索服務(wù)等。
最下面是中間件服務(wù)，如MQS即隊列服務(wù)，OCS即緩存服務(wù)等。
圖中也有一些看不到，例如高可用的體現(xiàn)、實現(xiàn)雙機(jī)房容災(zāi)和異地機(jī)房單元化部署，為淘寶業(yè)務(wù)提供穩(wěn)定、高效和易于維護(hù)的基礎(chǔ)架構(gòu)支撐。
這是一個含金量非常高的架構(gòu)，也是一個非常復(fù)雜而龐大的架構(gòu)。當(dāng)然這個架構(gòu)不是一天兩天演進(jìn)而成，也不是一上來就設(shè)計并開發(fā)成這么高大上的。
這邊我想說的是，小型公司要怎么做架構(gòu)呢？對很多創(chuàng)業(yè)公司而言，很難在初期就預(yù)估到流量十倍、百倍以及千倍以后的網(wǎng)站架構(gòu)會是一個怎樣的狀況。同時，如果系統(tǒng)初期就設(shè)計一個千萬級并發(fā)的流量架構(gòu)，也很難有公司可以支撐這個成本。
因此，一個大型服務(wù)系統(tǒng)都是從一步一步走過來的，在每個階段，找到對應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問題，然后在不斷解決這些問題，在這個過程中整個架構(gòu)會一直演進(jìn)。
一、單服務(wù)器-俗稱all in one
從一個小網(wǎng)站說起。一臺服務(wù)器也就足夠了。文件服務(wù)器，數(shù)據(jù)庫，還有應(yīng)用都部署在一臺機(jī)器，俗稱ALL IN ONE。
隨著我們用戶越來越多，訪問越來越大，硬盤、CPU、內(nèi)存等都開始吃緊，一臺服務(wù)器已經(jīng)滿足不了。這時看到下一步演進(jìn)。
二、數(shù)據(jù)服務(wù)與應(yīng)用服務(wù)分離
我們將數(shù)據(jù)服務(wù)和應(yīng)用服務(wù)分離，給應(yīng)用服務(wù)器配置更好的CPU和內(nèi)存，給數(shù)據(jù)服務(wù)器配置更好更大的硬盤。
分離之后提高一定的可用性，例如Files Server掛了，我們還是可以操作應(yīng)用和數(shù)據(jù)庫等。
隨著訪問QPS越來越高，降低接口訪問時間，提高服務(wù)性能和并發(fā)，成為了我們下一個目標(biāo)，同時發(fā)現(xiàn)有很多業(yè)務(wù)數(shù)據(jù)不需要每次都從數(shù)據(jù)庫獲取。
三、使用緩存
包括本地緩存、遠(yuǎn)程緩存、遠(yuǎn)程分布式緩存。
因為 80% 的業(yè)務(wù)訪問都集中在 20% 的數(shù)據(jù)上，也就是我們經(jīng)常說的28法則。如果能將這部分?jǐn)?shù)據(jù)緩存下來，性能一下子就上來了。而緩存又分為兩種：本地緩存和遠(yuǎn)程緩存緩存，以及遠(yuǎn)程分布式緩存，我們這里面的遠(yuǎn)程緩存圖上畫的是分布式的緩存集群(Cluster)。
思考的點
具有哪種業(yè)務(wù)特點數(shù)據(jù)使用緩存？
具有哪種業(yè)務(wù)特點的數(shù)據(jù)使用本地緩存？
具有哪種務(wù)特點的數(shù)據(jù)使用遠(yuǎn)程緩存？
分布式緩存在擴(kuò)容時會碰到什么問題？如何解決？分布式緩存的算法都有哪幾種？各有什么優(yōu)缺點？
這個時候隨著訪問QPS的提高，服務(wù)器的處理能力會成為瓶頸。雖然可以通過購買更強(qiáng)大的硬件解決，但總會有上限，而且這個到后期成本就是指數(shù)級增長了，這時，我們需要服務(wù)器的集群來橫向擴(kuò)展，所以就必須加個新東西：負(fù)載均衡調(diào)度服務(wù)器。
四、使用負(fù)載均衡，進(jìn)行服務(wù)器集群
增加了負(fù)載均衡、服務(wù)器集群之后，我們可以橫向擴(kuò)展服務(wù)器，解決了服務(wù)器處理能力的瓶頸。
思考的點
負(fù)載均衡的調(diào)度策略都有哪些？
各有什么優(yōu)缺點？
各適合什么場景？
打個比方，我們有輪詢、權(quán)重、地址散列，地址散列又分為原ip地址散列hash、目標(biāo)ip地址散列hash，最少連接，加權(quán)最少連接，還有繼續(xù)升級的很多種策略......我們都來分析一下。
典型負(fù)載均衡策略分析
輪詢：優(yōu)點-實現(xiàn)簡單，缺點-不考慮每臺服務(wù)器處理能力
權(quán)重：優(yōu)點-考慮了服務(wù)器處理能力的不同
地址散列：優(yōu)點-能實現(xiàn)同一個用戶訪問同一個服務(wù)器
最少連接：優(yōu)點-使集群中各個服務(wù)器負(fù)載更加均勻
加權(quán)最少連接：在最少連接的基礎(chǔ)上，為每臺服務(wù)器加上權(quán)值。算法為(活動連接數(shù)*256+非活動連接數(shù))/權(quán)重，計算出來的值小的服務(wù)器優(yōu)先被選擇。
繼續(xù)引出問題的場景
我們登錄時登錄了A服務(wù)器，session信息存儲到A服務(wù)器上了，假設(shè)我們使用的負(fù)載均衡策略是ip hash，那么登錄信息還可以從A服務(wù)器上訪問，但這個有可能造成某些服務(wù)器壓力過大，某些服務(wù)器又沒有什么壓力，這時壓力過大的機(jī)器(包括網(wǎng)卡帶寬)有可能成為瓶頸，并且請求不夠分散。
這時候我們使用輪詢或者最小連接負(fù)載均衡策略，就導(dǎo)致了第一次訪問A服務(wù)器，第二次可能訪問到B服務(wù)器，這時存儲在A服務(wù)器上的session信息在B服務(wù)器上讀取不到。
Session管理-Session Sticky粘滯會話
打個比方，如果我們每次吃飯都要保證用的是自己的碗筷，只要我們在一家飯店里存著自己的碗筷，并且每次去這家飯店吃飯就好了。
對于同一個連接中的數(shù)據(jù)包，負(fù)載均衡會將其轉(zhuǎn)發(fā)至后端固定的服務(wù)器進(jìn)行處理。
解決了我們session共享的問題，但是它有什么缺點呢？
一臺服務(wù)器運行的服務(wù)掛掉，或者重啟，上面的 session 都沒了。
負(fù)載均衡器成了有狀態(tài)的機(jī)器，為以后實現(xiàn)容災(zāi)造成了羈絆。
Session管理-Session 復(fù)制
就像我們在所有的飯店里都存一份自己的碗筷。這樣隨意去哪一家飯店吃飯都OK，不適合做大規(guī)模集群，適合機(jī)器不多的情況。
解決了我們session共享的問題，但是它有什么缺點呢？
應(yīng)用服務(wù)器間帶寬問題，因為需要不斷同步session數(shù)據(jù)。
大量用戶在線時，服務(wù)器占用內(nèi)存過多。
Session管理-基于Cookie
打個比方，就是我們每次去飯店吃飯，都帶著自己的碗筷去。
解決了我們session共享的問題，但是它有什么缺點呢？
cookie 的長度限制。
cookie存于瀏覽器，安全性是一個問題。
Session管理-Session 服務(wù)器
打個比方，就是我們的碗筷都存在了一個龐大的櫥柜里，我們?nèi)ト魏我患绎埖瓿燥?，都可以從櫥柜中拿到屬于我們自己的碗筷?/p>
解決了我們session共享的問題，這種方案需要思考哪些問題呢？
保證 session 服務(wù)器的可用性，session服務(wù)器單點如何解決？
我們在寫應(yīng)用時需要做調(diào)整存儲session的業(yè)務(wù)邏輯。
打個比方，為了提高session server的可用性，我們可以繼續(xù)給session server做集群。
五、中間總結(jié)
所以網(wǎng)站架構(gòu)在遇到某些指標(biāo)瓶頸、演進(jìn)的過程中，都有哪些解決方案？它們都有什么優(yōu)缺點？業(yè)務(wù)功能上如何取舍？如何做出選擇？這個過程才是最重要的。
在解決了橫向擴(kuò)展應(yīng)用服務(wù)器之后，我們繼續(xù)回到目前的架構(gòu)圖：
數(shù)據(jù)庫的讀及寫操作都還需要經(jīng)過數(shù)據(jù)庫。當(dāng)用戶量達(dá)到一定量，數(shù)據(jù)庫將會成為瓶頸。又該如何解決呢？
六、數(shù)據(jù)庫讀寫分離
使用數(shù)據(jù)庫提供的熱備功能，將所有的讀操作引入slave 服務(wù)器，因為數(shù)據(jù)庫的讀寫分離了，所以我們的應(yīng)用程序也得做出相應(yīng)的變化。我們實現(xiàn)了一個數(shù)據(jù)訪問模塊(圖中的data access module)，使上層寫代碼的人不知道讀寫分離的存在。這樣多數(shù)據(jù)源讀寫分離就對業(yè)務(wù)代碼沒有了侵入。同時這里引出了代碼層次的演變。
思考的點
如何支持多數(shù)據(jù)源？
如何封裝對業(yè)務(wù)沒有侵入？
如何使用目前業(yè)務(wù)的ORM框架完成主從讀寫分離？是否需要更4. 換ORM模型？ORM模型之間各有什么優(yōu)缺點？
如何取舍？
數(shù)據(jù)庫讀寫分離會遇到如下問題：
在master和slave復(fù)制的時候，考慮延時問題、數(shù)據(jù)庫的支持、復(fù)制條件的支持。
當(dāng)為了提高可用性，將數(shù)據(jù)庫分機(jī)房后，跨機(jī)房傳輸同步數(shù)據(jù)，這個更是問題。
應(yīng)用對于數(shù)據(jù)源的路由問題。
七、使用反向代理和CDN加速網(wǎng)站響應(yīng)
使用 CDN 可以很好地解決不同的地區(qū)的訪問速度問題，反向代理則在服務(wù)器機(jī)房中緩存用戶資源。
訪問量越來越大，我們文件服務(wù)器也出現(xiàn)了瓶頸。
八、分布式文件系統(tǒng)
思考的點
分布式文件系統(tǒng)如何不影響已部署在線上的業(yè)務(wù)訪問？不能讓某個圖片突然訪問不到呀。
是否需要業(yè)務(wù)部門清洗數(shù)據(jù)？
是否需要重新做域名解析？
這時數(shù)據(jù)庫又出現(xiàn)了瓶頸。
九、數(shù)據(jù)垂直拆分
數(shù)據(jù)庫專庫專用，如圖Products、Users、Deal庫。解決寫數(shù)據(jù)時并發(fā)量大的問題。
思考的點
跨業(yè)務(wù)的事務(wù)如何解決？使用分布式事務(wù)、去掉事務(wù)或不追求強(qiáng)事務(wù)。
應(yīng)用的配置項多了。
如何跨庫進(jìn)行數(shù)據(jù)的join操作？
這個時候，某個業(yè)務(wù)的數(shù)據(jù)表的數(shù)據(jù)量或者更新量達(dá)到了單個數(shù)據(jù)庫的瓶頸。
十、數(shù)據(jù)水平拆分
如圖，我們把User拆成了User1和User2，將同一個表的數(shù)據(jù)拆分到兩個數(shù)據(jù)庫中，解決了單數(shù)據(jù)庫的瓶頸。
思考的點
水平拆分的策略都有哪些？各有什么優(yōu)缺點？
水平拆分的時候如何清洗數(shù)據(jù)？
SQL的路由問題，需要知道某個User在哪個數(shù)據(jù)庫上。
主鍵的策略會有不同。
假設(shè)系統(tǒng)中需要查詢2017年4月份已經(jīng)下單過的用戶名的明細(xì)，而這些用戶分布在user1和user2上，我們后臺運營系統(tǒng)在展示時如何分頁？
這個時候，公司對外部做了流量導(dǎo)入，我們應(yīng)用中的搜索量飆升，繼續(xù)演進(jìn)。
十一、拆分搜索引擎
使用搜索引擎，解決數(shù)據(jù)查詢問題。部分場景可使用NoSQL提高性能，開發(fā)數(shù)據(jù)統(tǒng)一訪問模塊，解決上層應(yīng)用開發(fā)的數(shù)據(jù)源問題。如圖data access module 可以訪問數(shù)據(jù)庫、搜索引擎、NoSQL。
總結(jié)
本文只是一個舉例演示，各個服務(wù)的技術(shù)架構(gòu)需要根據(jù)自己業(yè)務(wù)特點進(jìn)行優(yōu)化和演進(jìn)，所以大家的過程也不完全相同。
最后的這個示例也不是完美的，例如負(fù)載均衡還是一個單點，也需要集群，我們這個架構(gòu)也只是冰山一角。因為在架構(gòu)演進(jìn)的過程中，還要考慮系統(tǒng)的安全性、數(shù)據(jù)分析、監(jiān)控、反作弊等，同時往后繼續(xù)發(fā)展，也要考慮到SOA架構(gòu)、服務(wù)化、消息隊列、任務(wù)調(diào)度、多機(jī)房等。
從以上對架構(gòu)演進(jìn)的講解，也可以看出來，所有大型項目的架構(gòu)和代碼，都是一步一步根據(jù)實際的業(yè)務(wù)場景和發(fā)展情況發(fā)展演變而來，在不同的階段，會使用的不同的技術(shù)，不同的架構(gòu)來解決實際的問題，所以說，高大上的項目技術(shù)架構(gòu)和開發(fā)設(shè)計實現(xiàn)不是一蹴而就的。
正是所謂的萬丈高樓平地起。在架構(gòu)演進(jìn)的過程中，小到核心模塊代碼，大到核心架構(gòu)，都會不斷演進(jìn)的，這個過程值得我們?nèi)ド钊雽W(xué)習(xí)和思考。
