大型網(wǎng)站架構(gòu)的發(fā)展演變過程

?

?原文地址

什么是大型網(wǎng)站

如何定義一個網(wǎng)站是不是大型網(wǎng)站，一般我們會從兩個緯度去考衡，訪問量以及數(shù)據(jù)量，二者缺一不可。

我們以javaweb為例，來搭建一個簡單的電商系統(tǒng)，從這個系統(tǒng)中來看系統(tǒng)的演變歷史；要注意的是，接下來的演示模型，關(guān)注的是數(shù)據(jù)量、訪問量提升，網(wǎng)站結(jié)構(gòu)發(fā)生的變化， 而不是具體關(guān)注業(yè)務(wù)功能點。其次，這個過程是為了讓大家更好的了解網(wǎng)站演進過程中的一些問題和應(yīng)對策略。

假如我們系統(tǒng)具備以下功能：

用戶模塊：用戶注冊和管理

商品模塊：商品展示和管理

交易模塊：創(chuàng)建交易及支付結(jié)算

?

架構(gòu)的發(fā)展演變過程

?

階段一 ?單應(yīng)用架構(gòu)

網(wǎng)站的初期也可以認為是互聯(lián)網(wǎng)發(fā)展的早起，我們經(jīng)常會在單機上跑我們所有的程序和軟件。

把所有軟件和應(yīng)用都部署在一臺機器上，這樣就完成一個簡單系統(tǒng)的搭建，這個時候的講究的是效率

單體架構(gòu)的缺陷

1.復(fù)雜性高 整個項目包含的模塊非常多，模塊的邊界模糊，依賴關(guān)系不清晰，代碼質(zhì)量參差不齊,整個項目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn)，甚至添加一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。 2.技術(shù)債務(wù)逐漸上升 隨著時間推移、需求變更和人員更迭，會逐漸形成應(yīng)用程序的技術(shù)債務(wù)，并且越積越多。已使用的系統(tǒng)設(shè)計或代碼難以修改，因為應(yīng)用程序的其他模塊可能會以意料之外的方式使用它。 3.部署速度逐漸變慢 隨著代碼的增加，構(gòu)建和部署的時間也會增加。而在單體應(yīng)用中，每次功能的變更或缺陷的修復(fù)都會導(dǎo)致我們需要重新部署整個應(yīng)用。全量部署的方式耗時長、影響范圍大、風(fēng)險高，這使得單體應(yīng)用項目上線部署的頻率較低，從而又導(dǎo)致兩次發(fā)布之間會有大量功能變更和缺陷修復(fù)，出錯概率較高。 4.擴展能力受限，無法按需伸縮 單體應(yīng)用只能作為一個整體進行擴展，無法結(jié)合業(yè)務(wù)模塊的特點進行伸縮。 5.阻礙技術(shù)創(chuàng)新 單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發(fā)語言和架構(gòu)，想要引入新的框架或技術(shù)平臺非常困難。 由于單體架構(gòu)的缺陷日益明顯，所以越來越多的公司采用微服務(wù)架構(gòu)范式解決上面提到的單體架構(gòu)中的問題。 不同于構(gòu)建單一、龐大的應(yīng)用，微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)。

?

?

階段二 應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器分離

?

隨著網(wǎng)站的上線，訪問量逐步上升，服務(wù)器的負載慢慢提高，在服務(wù)器還沒有超載的時候，我們應(yīng)該做好規(guī)劃，提升網(wǎng)站的負載能力。假如代碼層面的優(yōu)化已經(jīng)沒辦法繼續(xù)提高，在不提高單臺機器的性能，增加機器是一個比較好的方式，投入產(chǎn)出比非常高。這個階段增加機器的主要目的是講web服務(wù)器和數(shù)據(jù)庫服務(wù)器拆分，這樣不僅提高了單機的負載能力，也提高了容災(zāi)能力

?

?

?

階段三 ?應(yīng)用服務(wù)器集群-應(yīng)用服務(wù)器負載告警，如何讓應(yīng)用服務(wù)器走向集群

?隨著訪問量的繼續(xù)增加，單臺應(yīng)用服務(wù)器已經(jīng)無法滿足需求。在假設(shè)數(shù)據(jù)庫服務(wù)器還沒有遇到性能問題的時候，我們可以增加應(yīng)用服務(wù)器，通過應(yīng)用服務(wù)器集群將用戶請求分流到各個服務(wù)器中，從而繼續(xù)提升負載能力。此時多臺應(yīng)用服務(wù)器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對外提供服務(wù)

?

架構(gòu)發(fā)展到這個階段，各種問題也會慢慢呈現(xiàn)

用戶請求由誰來轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器

用戶如果每次訪問到的服務(wù)器不一樣，那么如何維護session

?

?

?

階段四 ?數(shù)據(jù)庫壓力變大，數(shù)據(jù)庫讀寫分離

　　架構(gòu)演變到這里，并不是終點。上面我們把應(yīng)用層的性能拉上來了，但是數(shù)據(jù)庫的負載也在慢慢增大，那么怎么去提高數(shù)據(jù)庫層面的負載呢？有了前面的思路以后，自然會想到增加服務(wù)器。但是假如我們單純的把數(shù)據(jù)庫一分為二，然后對于后續(xù)數(shù)據(jù)庫的請求，分別負載到兩臺數(shù)據(jù)庫服務(wù)器上，那么一定會造成數(shù)據(jù)庫不統(tǒng)一的問題。所以我們一般先考慮讀寫分離的方式

這個架構(gòu)的變化會帶來幾個問題

主從數(shù)據(jù)庫之間的數(shù)據(jù)同步 ； 可以使用mysql自帶的master-slave方式實現(xiàn)主從復(fù)制

對應(yīng)數(shù)據(jù)源的選擇 ； 采用第三方數(shù)據(jù)庫中間件，例如mycat

?

?

階段五 ? 使用搜索引擎緩解讀庫的壓力

　　數(shù)據(jù)庫做讀庫的話，嘗嘗對模糊查找效率不是特別好，像電商類的網(wǎng)站，搜索是非常核心的功能，即便是做了讀寫分離，這個問題也不能有效解決。那么這個時候就需要引入搜索引擎了

使用搜索引擎能夠大大提高我們的查詢速度，但是同時也會帶來一些附加的問題，比如維護索引的構(gòu)建。

?

?

?

階段六 ?引入緩存機制緩解數(shù)據(jù)庫的壓力

　　隨著訪問量的持續(xù)增加，逐漸出現(xiàn)許多用戶訪問統(tǒng)一部分內(nèi)容的情況，對于這些熱點數(shù)據(jù)，沒必要每次都從數(shù)據(jù)庫去讀取，我們可以使用緩存技術(shù)，比如memcache、redis來作為我們應(yīng)用層的緩存；另外在某些場景下，比如我們對用戶的某些IP的訪問頻率做限制，那這個放內(nèi)存中又不合適，放數(shù)據(jù)庫又太麻煩，這個時候可以使用Nosql的方式比如mongDB來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫

?

?

階段七 ?數(shù)據(jù)庫的水平/垂直拆分

　　我們的網(wǎng)站演進的變化過程，交易、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中，盡管采取了增加緩存，讀寫分離的方式，但是隨著數(shù)據(jù)庫的壓力持續(xù)增加，數(shù)據(jù)庫的瓶頸仍然是個最大的問題。因此我們可以考慮對數(shù)據(jù)的垂直拆分和水平拆分

垂直拆分：把數(shù)據(jù)庫中不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫

水平拆分：把同一個表中的數(shù)據(jù)拆分到兩個甚至跟多的數(shù)據(jù)庫中，水平拆分的原因是某些業(yè)務(wù)數(shù)據(jù)量已經(jīng)達到了單個數(shù)據(jù)庫的瓶頸，這時可以采取講表拆分到多個數(shù)據(jù)庫中

?

?

?

階段八 ?應(yīng)用的拆分

　　?隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來越多，應(yīng)用的壓力越來越大。工程規(guī)模也越來越龐大。這個時候就可以考慮講應(yīng)用拆分，按照領(lǐng)域模型講我們的用戶、商品、交易拆分成多個子系統(tǒng)。

這樣拆分以后，可能會有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會導(dǎo)致每個系統(tǒng)都會有用戶查詢訪問相關(guān)操作。這些相同的操作一定是要抽象出來，否則就會是一個坑。所以通過走服務(wù)化路線的方式來解決

?

那么服務(wù)拆分以后，各個服務(wù)之間如何進行遠程通信呢？

通過RPC技術(shù)，比較典型的有：webservice、hessian、http、RMI等等

前期通過這些技術(shù)能夠很好的解決各個服務(wù)之間通信問題，but，互聯(lián)網(wǎng)的發(fā)展是持續(xù)的，所以架構(gòu)的演變和優(yōu)化還在持續(xù)。

?

?

?

總結(jié)

我們通過這個例子來講解了電商網(wǎng)站的架構(gòu)演進。我要強調(diào)一下，這個架構(gòu)的演進不是某個網(wǎng)站真實的例子，實際上是通過這樣一個演進過程給大家?guī)硪粋€全局的觀念和感受。以及給大家在后續(xù)課程學(xué)習(xí)過程中的一些思路。

如何把單擊擴展到分布式

前面我們講到了馮.諾依曼模型，計算機一共由5個部分組成，從用戶角度來看，分布式系統(tǒng)就像一臺超級計算機。理論上也應(yīng)該由輸入、輸出、運算、存儲和控制這5部分組成。

輸入設(shè)備的變化

在分布式系統(tǒng)架構(gòu)中，輸入設(shè)備可以分兩類，第一類是互相連接的多個節(jié)點，在接收其他節(jié)點傳來的信息作為該節(jié)點的輸入；另一種就是傳統(tǒng)意義上的人機交互的輸入設(shè)備了

輸出設(shè)備的變化

輸出和輸入類似，也有兩種，一種是系統(tǒng)中的節(jié)點向其他節(jié)點傳輸信息時，該節(jié)點可以看作是輸出設(shè)備；另一種就是傳統(tǒng)意義上的人際交互的輸出設(shè)備，比如用戶的終端

控制器的變化

在單機中，控制器指的是CPU中的控制器，在分布式系統(tǒng)中，控制器主要的作用是協(xié)調(diào)或控制節(jié)點之間的動作和行為；比如硬件負載均衡器；LVS軟負載；規(guī)則服務(wù)器等

運算器

在分布式系統(tǒng)中，運算器是由多個節(jié)點來組成的。運用多個節(jié)點的計算能力來協(xié)同完成整體的計算任務(wù)

存儲器

在分布式系統(tǒng)中，我們需要把承擔(dān)存儲功能的多個節(jié)點組織在一起，組成一個整體的存儲器；比如數(shù)據(jù)庫、redis（key-value存儲）

轉(zhuǎn)載于:https://www.cnblogs.com/-wenli/p/10956930.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的大型网站架构的发展演变过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。