一丶 單服務(wù)器-俗稱all in one

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ù)分離

我們將數(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)程分布式緩存

使用緩存

因?yàn)?80% 的業(yè)務(wù)訪問都集中在 20% 的數(shù)據(jù)上，也就是我們經(jīng)常說的28法則。如果我們能將這部分?jǐn)?shù)據(jù)緩存下來，性能一下子就上來了。而緩存又分為兩種：本地緩存和遠(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. 各適合什么場景？

打個比方，我們有輪詢，權(quán)重，地址散列，地址散列又分為原ip地址散列hash，目標(biāo)ip地址散列hash，最少連接，加權(quán)最少連接，還有繼續(xù)升級的很多種策略......

Session管理-Session Sticky粘滯會話：

打個比方就是如果我們每次吃飯都要保證我們用的是自己的碗筷，而只要我們在一家飯店里存著我們的碗筷，只要我們每次去這家飯店吃飯就好了。

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

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

1.一臺服務(wù)器運(yùn)行的服務(wù)掛掉，或者重啟，上面的 session 都沒了。

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

Session管理-Session 復(fù)制

就像我們在所有的飯店里都存一份自己的碗筷。我們隨意去哪一家飯店吃飯都OK，不適合做大規(guī)模集群，適合機(jī)器不多的情況。

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

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

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

Session管理-基于Cookie

打個比方，就是我們每次去飯店吃飯，都自己帶著自己的碗筷。

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

1.cookie 的長度限制。

2.cookie存于瀏覽器，安全性是一個問題。

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

打個比方，就是我們的碗筷都存在了一個龐大的櫥柜里，我們?nèi)ト魏我患绎埖瓿燥?，都可以從櫥柜中拿到屬于我們自己的碗筷?/p>

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

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

2.我們在寫應(yīng)用時需要做調(diào)整存儲session的業(yè)務(wù)邏輯

打個比方，我們?yōu)榱颂岣遱ession server的可用性，可以繼續(xù)給session server做集群。

四丶數(shù)據(jù)庫讀寫分離

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

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

五丶 使用反向代理和 CDN 加速網(wǎng)站響應(yīng)

反向代理和 CDN 加速網(wǎng)站響應(yīng)

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

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

六丶 分布式文件系統(tǒng)

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

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

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

3. 是否需要重新做域名解析？

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

七丶數(shù)據(jù)垂直拆分

數(shù)據(jù)垂直拆分

數(shù)據(jù)庫專庫專用，如圖Products、Users、Deal庫。

解決寫數(shù)據(jù)時，并發(fā)，量大的問題。

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

2. 應(yīng)用的配置項(xiàng)多了

3. 如何跨庫進(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ù)庫的瓶頸。

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

2. 水平拆分的時候如何清洗數(shù)據(jù)？

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

4. 主鍵的策略會有不同。

5. 假設(shè)我們系統(tǒng)中需要查詢2017年4月份已經(jīng)下單過的用戶名的明細(xì)，而這些用戶分布在user1和user2上，我們后臺運(yùn)營系統(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ǎng)站技術(shù)架構(gòu)的原理與分析就結(jié)束了，，不足之處還望大家多多包涵?。∮X得收獲的話可以點(diǎn)個關(guān)注收藏轉(zhuǎn)發(fā)一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和大家交流幾點(diǎn)編程的經(jīng)驗(yàn)：

1、多寫多敲代碼，好的代碼與扎實(shí)的基礎(chǔ)知識一定是實(shí)踐出來的

2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發(fā)的就不只是代碼，可能還會聲名狼藉。

3丶 簡化算法，代碼如惡魔，在你完成編碼后，應(yīng)回頭并且優(yōu)化它。從長遠(yuǎn)來看，這里或那里一些的改進(jìn)，會讓后來的支持人員更加輕松。