大型網(wǎng)站技術(shù)架構(gòu)的原理與分析
一丶 單服務(wù)器-俗稱all in one
all in one
從一個(gè)小網(wǎng)站說(shuō)起。一臺(tái)服務(wù)器也就足夠了。文件服務(wù)器,數(shù)據(jù)庫(kù),還有應(yīng)用都部署在一臺(tái)機(jī)器,俗稱ALL IN ONE。
隨著我們用戶越來(lái)越多,訪問(wèn)越來(lái)越大,硬盤,CPU,內(nèi)存等都開(kāi)始吃緊,一臺(tái)服務(wù)器已經(jīng)滿足不了。
這個(gè)時(shí)候看一下下一步演進(jìn)。
數(shù)據(jù)服務(wù)與應(yīng)用服務(wù)分離
數(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ù)庫(kù)等。
隨著訪問(wèn)qps越來(lái)越高,降低接口訪問(wèn)時(shí)間,提高服務(wù)性能和并發(fā),成為了我們下一個(gè)目標(biāo),發(fā)現(xiàn)有很多業(yè)務(wù)數(shù)據(jù)不需要每次都從數(shù)據(jù)庫(kù)獲取。
二丶使用緩存,包括本地緩存,遠(yuǎn)程緩存,遠(yuǎn)程分布式緩存
使用緩存
因?yàn)?80% 的業(yè)務(wù)訪問(wèn)都集中在 20% 的數(shù)據(jù)上,也就是我們經(jīng)常說(shuō)的28法則。如果我們能將這部分?jǐn)?shù)據(jù)緩存下來(lái),性能一下子就上來(lái)了。而緩存又分為兩種:本地緩存和遠(yuǎn)程緩存緩存,以及遠(yuǎn)程分布式緩存,我們這里面的遠(yuǎn)程緩存圖上畫的是分布式的緩存集群(Cluster)。
三丶使用負(fù)載均衡,進(jìn)行服務(wù)器集群
使用負(fù)載均衡,進(jìn)行服務(wù)器集群
增加了負(fù)載均衡,服務(wù)器集群之后,我們可以橫向擴(kuò)展服務(wù)器,解決了服務(wù)器處理能力的瓶頸。
1. 負(fù)載均衡的調(diào)度策略都有哪些?
2.各有什么優(yōu)缺點(diǎn)?
3. 各適合什么場(chǎng)景?
打個(gè)比方,我們有輪詢,權(quán)重,地址散列,地址散列又分為原ip地址散列hash,目標(biāo)ip地址散列hash,最少連接,加權(quán)最少連接,還有繼續(xù)升級(jí)的很多種策略......
Session管理-Session Sticky粘滯會(huì)話:
打個(gè)比方就是如果我們每次吃飯都要保證我們用的是自己的碗筷,而只要我們?cè)谝患绎埖昀锎嬷覀兊耐肟?,只要我們每次去這家飯店吃飯就好了。
對(duì)于同一個(gè)連接中的數(shù)據(jù)包,負(fù)載均衡會(huì)將其轉(zhuǎn)發(fā)至后端固定的服務(wù)器進(jìn)行處理。
解決了我們session共享的問(wèn)題,但是它有什么缺點(diǎn)呢?
1.一臺(tái)服務(wù)器運(yùn)行的服務(wù)掛掉,或者重啟,上面的 session 都沒(méi)了。
2. 負(fù)載均衡器成了有狀態(tài)的機(jī)器,為以后實(shí)現(xiàn)容災(zāi)造成了羈絆。
Session管理-Session 復(fù)制
就像我們?cè)谒械娘埖昀锒即嬉环葑约旱耐肟?。我們隨意去哪一家飯店吃飯都OK,不適合做大規(guī)模集群,適合機(jī)器不多的情況。
解決了我們session共享的問(wèn)題,但是它有什么缺點(diǎn)呢?
1. 應(yīng)用服務(wù)器間帶寬問(wèn)題,因?yàn)樾枰粩嗤絪ession數(shù)據(jù)。
2. 大量用戶在線時(shí),服務(wù)器占用內(nèi)存過(guò)多。
Session管理-基于Cookie

打個(gè)比方,就是我們每次去飯店吃飯,都自己帶著自己的碗筷。
解決了我們session共享的問(wèn)題,但是它有什么缺點(diǎn)呢?
1.cookie 的長(zhǎng)度限制。
2.cookie存于瀏覽器,安全性是一個(gè)問(wèn)題。
Session管理-Session 服務(wù)器

打個(gè)比方,就是我們的碗筷都存在了一個(gè)龐大的櫥柜里,我們?nèi)ト魏我患绎埖瓿燥垼伎梢詮臋还裰心玫綄儆谖覀冏约旱耐肟辍?/p>
解決了我們session共享的問(wèn)題,這種方案需要思考哪些問(wèn)題呢?
1. 保證 session 服務(wù)器的可用性,session服務(wù)器單點(diǎn)如何解決?
2.我們?cè)趯憫?yīng)用時(shí)需要做調(diào)整存儲(chǔ)session的業(yè)務(wù)邏輯
打個(gè)比方,我們?yōu)榱颂岣遱ession server的可用性,可以繼續(xù)給session server做集群。
四丶數(shù)據(jù)庫(kù)讀寫分離

數(shù)據(jù)庫(kù)讀寫分離
使用數(shù)據(jù)庫(kù)提供的熱備功能,將所有的讀操作引入slave 服務(wù)器,因?yàn)閿?shù)據(jù)庫(kù)的讀寫分離了,所以,我們的應(yīng)用程序也得做相應(yīng)的變化。我們實(shí)現(xiàn)一個(gè)數(shù)據(jù)訪問(wèn)模塊(圖中的data access module)使上層寫代碼的人不知道讀寫分離的存在。這樣多數(shù)據(jù)源讀寫分離就對(duì)業(yè)務(wù)代碼沒(méi)有了侵入。這里就引出了代碼層次的演變。
五丶 使用反向代理和 CDN 加速網(wǎng)站響應(yīng)

反向代理和 CDN 加速網(wǎng)站響應(yīng)
使用 CDN 可以很好的解決不同的地區(qū)的訪問(wèn)速度問(wèn)題,反向代理則在服務(wù)器機(jī)房中緩存用戶資源。
訪問(wèn)量越來(lái)越大,我們文件服務(wù)器也出現(xiàn)了瓶頸。
六丶 分布式文件系統(tǒng)

分布式文件系統(tǒng)
分布式文件系統(tǒng)如何不影響已部署在線上的業(yè)務(wù)訪問(wèn)?不能讓某個(gè)圖片突然訪問(wèn)不到呀
是否需要業(yè)務(wù)部門清洗數(shù)據(jù)?
是否需要重新做域名解析?
這個(gè)時(shí)候數(shù)據(jù)庫(kù)又出現(xiàn)了瓶頸。
七丶數(shù)據(jù)垂直拆分

數(shù)據(jù)垂直拆分
數(shù)據(jù)庫(kù)專庫(kù)專用,如圖Products、Users、Deal庫(kù)。
解決寫數(shù)據(jù)時(shí),并發(fā),量大的問(wèn)題。
跨業(yè)務(wù)的事務(wù)?如何解決?使用分布式事務(wù)、去掉事務(wù)或不追求強(qiáng)事務(wù)
應(yīng)用的配置項(xiàng)多了
如何跨庫(kù)進(jìn)行數(shù)據(jù)的join操作
這個(gè)時(shí)候,某個(gè)業(yè)務(wù)的數(shù)據(jù)表的數(shù)據(jù)量或者更新量達(dá)到了單個(gè)數(shù)據(jù)庫(kù)的瓶頸。
八丶數(shù)據(jù)水平拆分

如圖,我們把User拆成了User1和User2,將同一個(gè)表的數(shù)據(jù)拆分到兩個(gè)數(shù)據(jù)庫(kù)中,解決了單數(shù)據(jù)庫(kù)的瓶頸。
水平拆分的策略都有哪些?各有什么優(yōu)缺點(diǎn)?
水平拆分的時(shí)候如何清洗數(shù)據(jù)?
SQL 的路由問(wèn)題,需要知道某個(gè) User 在哪個(gè)數(shù)據(jù)庫(kù)上。
主鍵的策略會(huì)有不同。
假設(shè)我們系統(tǒng)中需要查詢2017年4月份已經(jīng)下單過(guò)的用戶名的明細(xì),而這些用戶分布在user1和user2上,我們后臺(tái)運(yùn)營(yíng)系統(tǒng)在展示時(shí)如何分頁(yè)?
這個(gè)時(shí)候,公司對(duì)外部做了流量導(dǎo)入,我們應(yīng)用中的搜索量飆升,繼續(xù)演進(jìn)。
九丶拆分搜索引擎

使用搜索引擎,解決數(shù)據(jù)查詢問(wèn)題。部分場(chǎng)景可使用 NoSQL 提高性能,開(kāi)發(fā)數(shù)據(jù)統(tǒng)一訪問(wèn)模塊,解決上層應(yīng)用開(kāi)發(fā)的數(shù)據(jù)源問(wèn)題。如圖data access module 可以訪問(wèn)數(shù)據(jù)庫(kù),搜索引擎,NoSQL。
總結(jié)
到這里,大型網(wǎng)站技術(shù)架構(gòu)的原理與分析就結(jié)束了,,不足之處還望大家多多包涵!!覺(jué)得收獲的話可以點(diǎn)個(gè)關(guān)注收藏轉(zhuǎn)發(fā)一波喔,謝謝大佬們支持。(吹一波,233~~)
下面和大家交流幾點(diǎn)編程的經(jīng)驗(yàn):
1、多寫多敲代碼,好的代碼與扎實(shí)的基礎(chǔ)知識(shí)一定是實(shí)踐出來(lái)的
2丶 測(cè)試、測(cè)試再測(cè)試,如果你不徹底測(cè)試自己的代碼,那恐怕你開(kāi)發(fā)的就不只是代碼,可能還會(huì)聲名狼藉。
3丶 簡(jiǎn)化算法,代碼如惡魔,在你完成編碼后,應(yīng)回頭并且優(yōu)化它。從長(zhǎng)遠(yuǎn)來(lái)看,這里或那里一些的改進(jìn),會(huì)讓后來(lái)的支持人員更加輕松。
