大型電商項(xiàng)目的服務(wù)端架構(gòu)

我們以淘寶架構(gòu)為例埃跷，了解下大型電商項(xiàng)目的服務(wù)端架構(gòu)是怎樣的，如圖所示：

在這里插入圖片描述

• 上面是一些安全體系系統(tǒng)邮利，如數(shù)據(jù)安全體系弥雹、應(yīng)用安全體系、前端安全體系等延届。

• 中間是業(yè)務(wù)運(yùn)營(yíng)服務(wù)系統(tǒng)剪勿，如會(huì)員服務(wù)、商品服務(wù)方庭、店鋪服務(wù)厕吉、交易服務(wù)等酱固。

• 還有共享業(yè)務(wù)，如分布式數(shù)據(jù)層头朱、數(shù)據(jù)分析服務(wù)运悲、配置服務(wù)、數(shù)據(jù)搜索服務(wù)等项钮。

• 最下面是中間件服務(wù)班眯，如MQS即隊(duì)列服務(wù)，OCS即緩存服務(wù)等烁巫。

圖中也有一些看不到署隘，例如高可用的體現(xiàn)、實(shí)現(xiàn)雙機(jī)房容災(zāi)和異地機(jī)房單元化部署亚隙，為淘寶業(yè)務(wù)提供穩(wěn)定磁餐、高效和易于維護(hù)的基礎(chǔ)架構(gòu)支撐。

這是一個(gè)含金量非常高的架構(gòu)恃鞋，也是一個(gè)非常復(fù)雜而龐大的架構(gòu)崖媚。當(dāng)然這個(gè)架構(gòu)不是一天兩天演進(jìn)而成，也不是一上來就設(shè)計(jì)并開發(fā)成這么高大上的恤浪。

這邊我想說的是畅哑，小型公司要怎么做架構(gòu)呢？對(duì)很多創(chuàng)業(yè)公司而言水由，很難在初期就預(yù)估到流量十倍荠呐、百倍以及千倍以后的網(wǎng)站架構(gòu)會(huì)是一個(gè)怎樣的狀況。同時(shí)砂客，如果系統(tǒng)初期就設(shè)計(jì)一個(gè)千萬級(jí)并發(fā)的流量架構(gòu)泥张，也很難有公司可以支撐這個(gè)成本。

因此鞠值，一個(gè)大型服務(wù)系統(tǒng)都是從一步一步走過來的媚创，在每個(gè)階段，找到對(duì)應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問題彤恶，然后在不斷解決這些問題钞钙，在這個(gè)過程中整個(gè)架構(gòu)會(huì)一直演進(jìn)。

一声离、單服務(wù)器-俗稱all in one

image.png

從一個(gè)小網(wǎng)站說起芒炼。一臺(tái)服務(wù)器也就足夠了。文件服務(wù)器术徊，數(shù)據(jù)庫本刽，還有應(yīng)用都部署在一臺(tái)機(jī)器，俗稱ALL IN ONE。

隨著我們用戶越來越多子寓，訪問越來越大暗挑，硬盤、CPU斜友、內(nèi)存等都開始吃緊窿祥，一臺(tái)服務(wù)器已經(jīng)滿足不了。這時(shí)看到下一步演進(jìn)蝙寨。

二、數(shù)據(jù)服務(wù)與應(yīng)用服務(wù)分離

image.png

我們將數(shù)據(jù)服務(wù)和應(yīng)用服務(wù)分離嗤瞎，給應(yīng)用服務(wù)器配置更好的CPU和內(nèi)存墙歪，給數(shù)據(jù)服務(wù)器配置更好更大的硬盤。

分離之后提高一定的可用性贝奇，例如Files Server掛了虹菲，我們還是可以操作應(yīng)用和數(shù)據(jù)庫等。

隨著訪問QPS越來越高掉瞳，降低接口訪問時(shí)間毕源，提高服務(wù)性能和并發(fā)，成為了我們下一個(gè)目標(biāo)陕习，同時(shí)發(fā)現(xiàn)有很多業(yè)務(wù)數(shù)據(jù)不需要每次都從數(shù)據(jù)庫獲取霎褐。

三、使用緩存

image.png

包括本地緩存该镣、遠(yuǎn)程緩存冻璃、遠(yuǎn)程分布式緩存。

因?yàn)?80% 的業(yè)務(wù)訪問都集中在 20% 的數(shù)據(jù)上损合，也就是我們經(jīng)常說的28法則省艳。如果能將這部分?jǐn)?shù)據(jù)緩存下來，性能一下子就上來了嫁审。而緩存又分為兩種：本地緩存和遠(yuǎn)程緩存緩存跋炕，以及遠(yuǎn)程分布式緩存，我們這里面的遠(yuǎn)程緩存圖上畫的是分布式的緩存集群(Cluster)律适。

思考的點(diǎn)

• 具有哪種業(yè)務(wù)特點(diǎn)數(shù)據(jù)使用緩存辐烂？

• 具有哪種業(yè)務(wù)特點(diǎn)的數(shù)據(jù)使用本地緩存？

• 具有哪種務(wù)特點(diǎn)的數(shù)據(jù)使用遠(yuǎn)程緩存擦耀？

分布式緩存在擴(kuò)容時(shí)會(huì)碰到什么問題棉圈？如何解決？分布式緩存的算法都有哪幾種眷蜓？各有什么優(yōu)缺點(diǎn)分瘾？

這個(gè)時(shí)候隨著訪問QPS的提高，服務(wù)器的處理能力會(huì)成為瓶頸。雖然可以通過購(gòu)買更強(qiáng)大的硬件解決德召，但總會(huì)有上限白魂，而且這個(gè)到后期成本就是指數(shù)級(jí)增長(zhǎng)了，這時(shí)上岗，我們需要服務(wù)器的集群來橫向擴(kuò)展福荸，所以就必須加個(gè)新東西：負(fù)載均衡調(diào)度服務(wù)器。

四肴掷、使用負(fù)載均衡敬锐，進(jìn)行服務(wù)器集群

image.png

增加了負(fù)載均衡、服務(wù)器集群之后呆瞻，我們可以橫向擴(kuò)展服務(wù)器台夺，解決了服務(wù)器處理能力的瓶頸。

思考的點(diǎn)

負(fù)載均衡的調(diào)度策略都有哪些痴脾？

各有什么優(yōu)缺點(diǎn)颤介？

各適合什么場(chǎng)景？

打個(gè)比方赞赖，我們有輪詢滚朵、權(quán)重、地址散列前域，地址散列又分為原ip地址散列hash辕近、目標(biāo)ip地址散列hash，最少連接匿垄，加權(quán)最少連接亏推，還有繼續(xù)升級(jí)的很多種策略......我們都來分析一下。

典型負(fù)載均衡策略分析

輪詢：優(yōu)點(diǎn)-實(shí)現(xiàn)簡(jiǎn)單年堆，缺點(diǎn)-不考慮每臺(tái)服務(wù)器處理能力

權(quán)重：優(yōu)點(diǎn)-考慮了服務(wù)器處理能力的不同

地址散列：優(yōu)點(diǎn)-能實(shí)現(xiàn)同一個(gè)用戶訪問同一個(gè)服務(wù)器

最少連接：優(yōu)點(diǎn)-使集群中各個(gè)服務(wù)器負(fù)載更加均勻

加權(quán)最少連接：在最少連接的基礎(chǔ)上吞杭，為每臺(tái)服務(wù)器加上權(quán)值。算法為(活動(dòng)連接數(shù)*256+非活動(dòng)連接數(shù))/權(quán)重变丧，計(jì)算出來的值小的服務(wù)器優(yōu)先被選擇芽狗。

繼續(xù)引出問題的場(chǎng)景

我們登錄時(shí)登錄了A服務(wù)器，session信息存儲(chǔ)到A服務(wù)器上了痒蓬，假設(shè)我們使用的負(fù)載均衡策略是ip hash童擎，那么登錄信息還可以從A服務(wù)器上訪問，但這個(gè)有可能造成某些服務(wù)器壓力過大攻晒，某些服務(wù)器又沒有什么壓力顾复，這時(shí)壓力過大的機(jī)器(包括網(wǎng)卡帶寬)有可能成為瓶頸，并且請(qǐng)求不夠分散鲁捏。

這時(shí)候我們使用輪詢或者最小連接負(fù)載均衡策略芯砸，就導(dǎo)致了第一次訪問A服務(wù)器，第二次可能訪問到B服務(wù)器，這時(shí)存儲(chǔ)在A服務(wù)器上的session信息在B服務(wù)器上讀取不到假丧。

Session管理-Session Sticky粘滯會(huì)話

image.png

打個(gè)比方双揪，如果我們每次吃飯都要保證用的是自己的碗筷，只要我們?cè)谝患绎埖昀锎嬷约旱耐肟臧悖⑶颐看稳ミ@家飯店吃飯就好了渔期。

對(duì)于同一個(gè)連接中的數(shù)據(jù)包，負(fù)載均衡會(huì)將其轉(zhuǎn)發(fā)至后端固定的服務(wù)器進(jìn)行處理渴邦。

解決了我們session共享的問題疯趟，但是它有什么缺點(diǎn)呢？

一臺(tái)服務(wù)器運(yùn)行的服務(wù)掛掉谋梭，或者重啟迅办，上面的 session 都沒了。

負(fù)載均衡器成了有狀態(tài)的機(jī)器章蚣，為以后實(shí)現(xiàn)容災(zāi)造成了羈絆。

Session管理-Session 復(fù)制

image.png

就像我們?cè)谒械娘埖昀锒即嬉环葑约旱耐肟暌碳小＿@樣隨意去哪一家飯店吃飯都OK纤垂，不適合做大規(guī)模集群，適合機(jī)器不多的情況磷账。

解決了我們session共享的問題峭沦，但是它有什么缺點(diǎn)呢？

應(yīng)用服務(wù)器間帶寬問題逃糟，因?yàn)樾枰粩嗤絪ession數(shù)據(jù)吼鱼。

大量用戶在線時(shí)，服務(wù)器占用內(nèi)存過多绰咽。

Session管理-基于Cookie

image.png

打個(gè)比方菇肃，就是我們每次去飯店吃飯，都帶著自己的碗筷去取募。

解決了我們session共享的問題琐谤，但是它有什么缺點(diǎn)呢？

cookie 的長(zhǎng)度限制玩敏。

cookie存于瀏覽器斗忌，安全性是一個(gè)問題。

Session管理-Session 服務(wù)器

image.png

打個(gè)比方旺聚，就是我們的碗筷都存在了一個(gè)龐大的櫥柜里织阳，我們?nèi)ト魏我患绎埖瓿燥垼伎梢詮臋还裰心玫綄儆谖覀冏约旱耐肟辍?/p>

解決了我們session共享的問題砰粹，這種方案需要思考哪些問題呢唧躲？

保證 session 服務(wù)器的可用性，session服務(wù)器單點(diǎn)如何解決？

我們?cè)趯憫?yīng)用時(shí)需要做調(diào)整存儲(chǔ)session的業(yè)務(wù)邏輯惊窖。

打個(gè)比方刽宪，為了提高session server的可用性，我們可以繼續(xù)給session server做集群界酒。

五圣拄、中間總結(jié)

所以網(wǎng)站架構(gòu)在遇到某些指標(biāo)瓶頸、演進(jìn)的過程中毁欣，都有哪些解決方案庇谆？它們都有什么優(yōu)缺點(diǎn)？業(yè)務(wù)功能上如何取舍凭疮？如何做出選擇饭耳？這個(gè)過程才是最重要的。

在解決了橫向擴(kuò)展應(yīng)用服務(wù)器之后执解，我們繼續(xù)回到目前的架構(gòu)圖：

數(shù)據(jù)庫的讀及寫操作都還需要經(jīng)過數(shù)據(jù)庫寞肖。當(dāng)用戶量達(dá)到一定量，數(shù)據(jù)庫將會(huì)成為瓶頸衰腌。又該如何解決呢新蟆？

六、數(shù)據(jù)庫讀寫分離

使用數(shù)據(jù)庫提供的熱備功能右蕊，將所有的讀操作引入slave 服務(wù)器琼稻，因?yàn)閿?shù)據(jù)庫的讀寫分離了，所以我們的應(yīng)用程序也得做出相應(yīng)的變化饶囚。我們實(shí)現(xiàn)了一個(gè)數(shù)據(jù)訪問模塊(圖中的data access module)帕翻，使上層寫代碼的人不知道讀寫分離的存在。這樣多數(shù)據(jù)源讀寫分離就對(duì)業(yè)務(wù)代碼沒有了侵入萝风。同時(shí)這里引出了代碼層次的演變嘀掸。

思考的點(diǎn)

如何支持多數(shù)據(jù)源？

如何封裝對(duì)業(yè)務(wù)沒有侵入规惰？

如何使用目前業(yè)務(wù)的ORM框架完成主從讀寫分離横殴？是否需要更4. 換ORM模型？ORM模型之間各有什么優(yōu)缺點(diǎn)卿拴？

如何取舍衫仑？

數(shù)據(jù)庫讀寫分離會(huì)遇到如下問題：

在master和slave復(fù)制的時(shí)候，考慮延時(shí)問題堕花、數(shù)據(jù)庫的支持文狱、復(fù)制條件的支持。

當(dāng)為了提高可用性缘挽，將數(shù)據(jù)庫分機(jī)房后瞄崇，跨機(jī)房傳輸同步數(shù)據(jù)呻粹，這個(gè)更是問題。

應(yīng)用對(duì)于數(shù)據(jù)源的路由問題苏研。

七等浊、使用反向代理和CDN加速網(wǎng)站響應(yīng)

image.png

使用 CDN 可以很好地解決不同的地區(qū)的訪問速度問題，反向代理則在服務(wù)器機(jī)房中緩存用戶資源。

訪問量越來越大，我們文件服務(wù)器也出現(xiàn)了瓶頸栓票。

八、分布式文件系統(tǒng)

image.png

思考的點(diǎn)

分布式文件系統(tǒng)如何不影響已部署在線上的業(yè)務(wù)訪問撒踪？不能讓某個(gè)圖片突然訪問不到呀。

是否需要業(yè)務(wù)部門清洗數(shù)據(jù)大渤？

是否需要重新做域名解析制妄？

這時(shí)數(shù)據(jù)庫又出現(xiàn)了瓶頸。

九泵三、數(shù)據(jù)垂直拆分

image.png

數(shù)據(jù)庫專庫專用耕捞，如圖Products、Users烫幕、Deal庫俺抽。解決寫數(shù)據(jù)時(shí)并發(fā)量大的問題。

思考的點(diǎn)

跨業(yè)務(wù)的事務(wù)如何解決纬霞？使用分布式事務(wù)、去掉事務(wù)或不追求強(qiáng)事務(wù)驱显。

應(yīng)用的配置項(xiàng)多了诗芜。

如何跨庫進(jìn)行數(shù)據(jù)的join操作？

這個(gè)時(shí)候埃疫，某個(gè)業(yè)務(wù)的數(shù)據(jù)表的數(shù)據(jù)量或者更新量達(dá)到了單個(gè)數(shù)據(jù)庫的瓶頸伏恐。

十、數(shù)據(jù)水平拆分

image.png

如圖栓霜，我們把User拆成了User1和User2翠桦，將同一個(gè)表的數(shù)據(jù)拆分到兩個(gè)數(shù)據(jù)庫中，解決了單數(shù)據(jù)庫的瓶頸胳蛮。

思考的點(diǎn)

水平拆分的策略都有哪些销凑？各有什么優(yōu)缺點(diǎn)？

水平拆分的時(shí)候如何清洗數(shù)據(jù)仅炊？

SQL的路由問題斗幼，需要知道某個(gè)User在哪個(gè)數(shù)據(jù)庫上。

主鍵的策略會(huì)有不同抚垄。

假設(shè)系統(tǒng)中需要查詢2017年4月份已經(jīng)下單過的用戶名的明細(xì)蜕窿，而這些用戶分布在user1和user2上谋逻，我們后臺(tái)運(yùn)營(yíng)系統(tǒng)在展示時(shí)如何分頁？

這個(gè)時(shí)候桐经，公司對(duì)外部做了流量導(dǎo)入毁兆，我們應(yīng)用中的搜索量飆升，繼續(xù)演進(jìn)阴挣。

十一气堕、拆分搜索引擎

image.png

使用搜索引擎，解決數(shù)據(jù)查詢問題屯吊。部分場(chǎng)景可使用NoSQL提高性能送巡，開發(fā)數(shù)據(jù)統(tǒng)一訪問模塊，解決上層應(yīng)用開發(fā)的數(shù)據(jù)源問題盒卸。如圖data access module 可以訪問數(shù)據(jù)庫骗爆、搜索引擎、NoSQL蔽介。

總結(jié)

本文只是一個(gè)舉例演示摘投，各個(gè)服務(wù)的技術(shù)架構(gòu)需要根據(jù)自己業(yè)務(wù)特點(diǎn)進(jìn)行優(yōu)化和演進(jìn)，所以大家的過程也不完全相同虹蓄。

最后的這個(gè)示例也不是完美的犀呼，例如負(fù)載均衡還是一個(gè)單點(diǎn)，也需要集群薇组，我們這個(gè)架構(gòu)也只是冰山一角外臂。因?yàn)樵诩軜?gòu)演進(jìn)的過程中，還要考慮系統(tǒng)的安全性律胀、數(shù)據(jù)分析宋光、監(jiān)控、反作弊等炭菌，同時(shí)往后繼續(xù)發(fā)展罪佳，也要考慮到SOA架構(gòu)、服務(wù)化黑低、消息隊(duì)列赘艳、任務(wù)調(diào)度、多機(jī)房等克握。

從以上對(duì)架構(gòu)演進(jìn)的講解蕾管，也可以看出來，所有大型項(xiàng)目的架構(gòu)和代碼菩暗，都是一步一步根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景和發(fā)展情況發(fā)展演變而來娇掏，在不同的階段，會(huì)使用的不同的技術(shù)勋眯，不同的架構(gòu)來解決實(shí)際的問題婴梧，所以說下梢，高大上的項(xiàng)目技術(shù)架構(gòu)和開發(fā)設(shè)計(jì)實(shí)現(xiàn)不是一蹴而就的。

正是所謂的萬丈高樓平地起塞蹭。在架構(gòu)演進(jìn)的過程中孽江，小到核心模塊代碼，大到核心架構(gòu)番电，都會(huì)不斷演進(jìn)的岗屏，這個(gè)過程值得我們?nèi)ド钊雽W(xué)習(xí)和思考。