2021-02-12 分類: 網(wǎng)站建設
我們以Java Web為例,來搭建一個簡單的電商系統(tǒng),看看這個系統(tǒng)可以如何一步步演變。
該系統(tǒng)具備的功能:
階段一、單機構(gòu)建網(wǎng)站
網(wǎng)站的初期,我們經(jīng)常會在單機上跑我們所有的程序和軟件。此時我們使用一個容器,如Tomcat、Jetty、Jboss,然后直接使用JSP/Servlet技術(shù),或者使用一些開源的框架如Maven + Spring + Struts + Hibernate、Maven + Spring + Spring MVC + Mybatis。最后再選擇一個數(shù)據(jù)庫管理系統(tǒng)來存儲數(shù)據(jù),如MySQL、SqlServer、Oracle,然后通過JDBC進行數(shù)據(jù)庫的連接和操作。
把以上的所有軟件包括數(shù)據(jù)庫、應用程序都裝載同一臺機器上,應用跑起來了,也算是一個小系統(tǒng)了。此時系統(tǒng)結(jié)果如下:
階段二、應用服務器與數(shù)據(jù)庫分離
隨著網(wǎng)站的上線,訪問量逐步上升,服務器的負載慢慢提高,在服務器還沒有超載的時候,我們應該就要做好準備,提升網(wǎng)站的負載能力。假如我們代碼層面已難以優(yōu)化,在不提高單臺機器的性能的情況下,采用增加機器是一個不錯的方式,不僅可以有效地提高系統(tǒng)的負載能力,而且性價比高。
增加的機器用來做什么呢?此時我們可以把數(shù)據(jù)庫服務器和Web服務器拆分開來,這樣不僅提高了單臺機器的負載能力,也提高了容災能力。
應用服務器與數(shù)據(jù)庫分開后的架構(gòu)如下圖所示:
階段三、應用服務器集群
隨著訪問量繼續(xù)增加,單臺應用服務器已經(jīng)無法滿足需求了。在假設數(shù)據(jù)庫服務器沒有壓力的情況下,我們可以把應用服務器從一臺變成了兩臺甚至多臺,把用戶的請求分散到不同的服務器中,從而提高負載能力。而多臺應用服務器之間沒有直接的交互,他們都是依賴數(shù)據(jù)庫各自對外提供服務。著名的做故障切換的軟件有KeepAlived,KeepAlived是一個類似于Layer3、4、7交換機制的軟件,他不是某個具體軟件故障切換的專屬品,而是可以適用于各種軟件的一款產(chǎn)品。KeepAlived配合上ipvsadm又可以做負載均衡,可謂是神器。
我們以增加了一臺應用服務器為例,增加后的系統(tǒng)結(jié)構(gòu)圖如下:
系統(tǒng)演變到這里,將會出現(xiàn)下面四個問題:
針對以上問題,常用的解決方案如下:
1、負載均衡的問題
一般以下有5種解決方案:
1、HTTP重定向
HTTP重定向就是應用層的請求轉(zhuǎn)發(fā)。用戶的請求其實已經(jīng)到了HTTP重定向負載均衡服務器,服務器根據(jù)算法要求用戶重定向,用戶收到重定向請求后,再次請求真正的集群2、DNS域名解析負載均衡
DNS域名解析負載均衡就是在用戶請求DNS服務器,獲取域名對應的IP地址時,DNS服務器直接給出負載均衡后的服務器IP。3、反向代理服務器
在用戶的請求到達反向代理服務器時(已經(jīng)到達網(wǎng)站機房),由反向代理服務器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務器。常用的Apache,Nginx都可以充當反向代理服務器。4、IP層負載均衡
在請求到達負載均衡器后,負載均衡器通過修改請求的目的IP地址,從而實現(xiàn)請求的轉(zhuǎn)發(fā),做到負載均衡。5、數(shù)據(jù)鏈路層負載均衡
在請求到達負載均衡器后,負載均衡器通過修改請求的MAC地址,從而做到負載均衡,與IP負載均衡不一樣的是,當請求訪問完服務器之后,直接返回客戶。而無需再經(jīng)過負載均衡器。2、集群調(diào)度轉(zhuǎn)發(fā)算法
1、rr輪詢調(diào)度算法
顧名思義,輪詢分發(fā)請求。2、wrr加權(quán)調(diào)度算法
我們給每個服務器設置權(quán)值Weight,負載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務器,服務器被調(diào)用的次數(shù)跟權(quán)值成正比。3、sh原地址散列算法
提取用戶IP,根據(jù)散列函數(shù)得出一個key,再根據(jù)靜態(tài)映射表,查處對應的value,即目標服務器IP。過目標機器超負荷,則返回空。4、dh目標地址散列算法
原理同上,只是現(xiàn)在提取的是目標地址的IP來做哈希。5、lc最少連接算法
優(yōu)先把請求轉(zhuǎn)發(fā)給連接數(shù)少的服務器。6、wlc加權(quán)最少連接算法
在lc的基礎上,為每臺服務器加上權(quán)值。算法為:(活動連接數(shù) * 256 + 非活動連接數(shù)) ÷ 權(quán)重,計算出來的值小的服務器優(yōu)先被選擇。7、sed最短期望延遲算法
其實sed跟wlc類似,區(qū)別是不考慮非活動連接數(shù)。算法為:(活動連接數(shù) +1 ) * 256 ÷ 權(quán)重,同樣計算出來的值小的服務器優(yōu)先被選擇。8、nq永不排隊算法
改進的sed算法。我們想一下什么情況下才能“永不排隊”,那就是服務器的連接數(shù)為0的時候,那么假如有服務器連接數(shù)為0,均衡器直接把請求轉(zhuǎn)發(fā)給它,無需經(jīng)過sed的計算。9、LBLC基于局部性最少連接算法
負載均衡器根據(jù)請求的目的IP地址,找出該IP地址最近被使用的服務器,把請求轉(zhuǎn)發(fā)之。若該服務器超載,最采用最少連接數(shù)算法。10、LBLCR帶復制的基于局部性最少連接算法
負載均衡器根據(jù)請求的目的IP地址,找出該IP地址最近使用的“服務器組”,注意,并不是具體某個服務器,然后采用最少連接數(shù)從該組中挑出具體的某臺服務器出來,把請求轉(zhuǎn)發(fā)之。若該服務器超載,那么根據(jù)最少連接數(shù)算法,在集群的非本服務器組的服務器中,找出一臺服務器出來,加入本服務器組,然后把請求轉(zhuǎn)發(fā)。3、集群請求返回模式問題
1、NAT
負載均衡器接收用戶的請求,轉(zhuǎn)發(fā)給具體服務器,服務器處理完請求返回給均衡器,均衡器再重新返回給用戶。2、DR
負載均衡器接收用戶的請求,轉(zhuǎn)發(fā)給具體服務器,服務器出來玩請求后直接返回給用戶。需要系統(tǒng)支持IP Tunneling協(xié)議,難以跨平臺。3、TUN
同上,但無需IP Tunneling協(xié)議,跨平臺性好,大部分系統(tǒng)都可以支持。4、集群Session一致性問題
1、Session Sticky
Session sticky就是把同一個用戶在某一個會話中的請求,都分配到固定的某一臺服務器中,這樣我們就不需要解決跨服務器的session問題了,常見的算法有ip_hash算法,即上面提到的兩種散列算法。2、Session Replication
Session replication就是在集群中復制session,使得每個服務器都保存有全部用戶的session數(shù)據(jù)。3、Session數(shù)據(jù)集中存儲
Session數(shù)據(jù)集中存儲就是利用數(shù)據(jù)庫來存儲session數(shù)據(jù),實現(xiàn)了session和應用服務器的解耦。4、Cookie Base
Cookie base就是把Session存在Cookie中,由瀏覽器來告訴應用服務器我的session是什么,同樣實現(xiàn)了session和應用服務器的解耦。值得一提的是:
解決了以上的問題之后,系統(tǒng)的結(jié)構(gòu)如下:
階段四、數(shù)據(jù)庫讀寫分離化
上面我們總是假設數(shù)據(jù)庫負載正常,但隨著訪問量的的提高,數(shù)據(jù)庫的負載也在慢慢增大。那么可能有人馬上就想到跟應用服務器一樣,把數(shù)據(jù)庫一份為二再負載均衡即可。
但對于數(shù)據(jù)庫來說,并沒有那么簡單。假如我們簡單的把數(shù)據(jù)庫一分為二,然后對于數(shù)據(jù)庫的請求,分別負載到A機器和B機器,那么顯而易見會造成兩臺數(shù)據(jù)庫數(shù)據(jù)不統(tǒng)一的問題。那么對于這種情況,我們可以先考慮使用讀寫分離和主從復制的方式。
讀寫分離后的系統(tǒng)結(jié)構(gòu)如下:
這個結(jié)構(gòu)變化后也會帶來兩個問題:
解決方案:
階段五、用搜索引擎緩解讀庫的壓力
數(shù)據(jù)庫做讀庫的話,常常對模糊查找力不從心,即使做了讀寫分離,這個問題還未能解決。以我們所舉的交易網(wǎng)站為例,發(fā)布的商品存儲在數(shù)據(jù)庫中,用戶最常使用的功能就是查找商品,尤其是根據(jù)商品的標題來查找對應的商品。對于這種需求,一般我們都是通過like功能來實現(xiàn)的,但是這種方式的代價非常大,而且結(jié)果非常不準確。此時我們可以使用搜索引擎的倒排索引來完成。
搜索引擎具有的優(yōu)點:它能夠大大提高查詢速度和搜索準確性。引入搜索引擎的開銷
引入搜索引擎后的系統(tǒng)結(jié)構(gòu)如下:
階段六、用緩存緩解讀庫的壓力
常用的緩存機制包括頁面級緩存、應用數(shù)據(jù)緩存和數(shù)據(jù)庫緩存。
應用層和數(shù)據(jù)庫層的緩存
隨著訪問量的增加,逐漸出現(xiàn)了許多用戶訪問同一部分熱門內(nèi)容的情況,對于這些比較熱門的內(nèi)容,沒必要每次都從數(shù)據(jù)庫讀取。我們可以使用緩存技術(shù),例如可以使用Google的開源緩存技術(shù)Guava或者使用Memecahed作為應用層的緩存,也可以使用Redis作為數(shù)據(jù)庫層的緩存。
另外,在某些場景下,關(guān)系型數(shù)據(jù)庫并不是很適合,例如我想做一個“每日輸入密碼錯誤次數(shù)限制”的功能,思路大概是在用戶登錄時,如果登錄錯誤,則記錄下該用戶的IP和錯誤次數(shù),那么這個數(shù)據(jù)要放在哪里呢?假如放在內(nèi)存中,那么顯然會占用太大的內(nèi)容;假如放在關(guān)系型數(shù)據(jù)庫中,那么既要建立數(shù)據(jù)庫表,還要簡歷對應的Java bean,還要寫SQL等等。而分析一下我們要存儲的數(shù)據(jù),無非就是類似{ip:errorNumber}這樣的key:value數(shù)據(jù)。對于這種數(shù)據(jù),我們可以用NOSQL數(shù)據(jù)庫來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫。頁面緩存
除了數(shù)據(jù)緩存,還有頁面緩存。比如使用HTML5的localstroage或者Cookie。除了頁面緩存帶來的性能提升外,對于并發(fā)訪問且頁面置換頻率小的頁面,應盡量使用頁面靜態(tài)化技術(shù)。
值得一提的是:
緩存集群的調(diào)度算法不同與上面提到的應用服務器和數(shù)據(jù)庫。最好采用一致性哈希算,這樣才能提高命中率。加入緩存后的系統(tǒng)結(jié)構(gòu)如下:
階段七、數(shù)據(jù)庫水平拆分與垂直拆分
我們的網(wǎng)站演進到現(xiàn)在,交易、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中。盡管采取了增加緩存和讀寫分離的方式,但隨著數(shù)據(jù)庫的壓力繼續(xù)增加,數(shù)據(jù)庫數(shù)據(jù)量的瓶頸越來越突出,此時,我們可以有數(shù)據(jù)垂直拆分和水平拆分兩種選擇。
數(shù)據(jù)垂直拆分
垂直拆分的意思是把數(shù)據(jù)庫中不同的業(yè)務數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中,結(jié)合現(xiàn)在的例子,就是把交易、商品、用戶的數(shù)據(jù)分開。
優(yōu)點:
缺點:
問題:
解決問題方案:
數(shù)據(jù)垂直拆分后的結(jié)構(gòu)如下:
數(shù)據(jù)水平拆分
數(shù)據(jù)水平拆分就是把同一個表中的數(shù)據(jù)拆分到兩個甚至多個數(shù)據(jù)庫中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個業(yè)務的數(shù)據(jù)量或者更新量到達了單個數(shù)據(jù)庫的瓶頸,這時就可以把這個表拆分到兩個或更多個數(shù)據(jù)庫中。
優(yōu)點:
問題:
解決問題方案:
數(shù)據(jù)水平拆分后的結(jié)構(gòu)如下:
階段八、應用的拆分
按微服務拆分應用
隨著業(yè)務的發(fā)展,業(yè)務越來越多,應用越來越大。我們需要考慮如何避免讓應用越來越臃腫。這就需要把應用拆開,從一個應用變?yōu)閭z個甚至更多。還是以我們上面的例子,我們可以把用戶、商品、交易拆分開。變成“用戶、商品”和“用戶,交易”兩個子系統(tǒng)。
拆分后的結(jié)構(gòu):
問題:
這樣拆分后,可能會有一些相同的代碼,如用戶相關(guān)的代碼,商品和交易都需要用戶信息,所以在兩個系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復用是一個需要解決的問題。解決問題:
通過走服務化SOA的路線來解決頻繁公共的服務。走SOA服務化治理道路
為了解決上面拆分應用后所出現(xiàn)的問題,我們把公共的服務拆分出來,形成一種服務化的模式,簡稱SOA。
采用服務化之后的系統(tǒng)結(jié)構(gòu):
優(yōu)點:
問題:
如何進行遠程的服務調(diào)用?解決方法:
可以通過下面的引入消息中間件來解決。階段九、引入消息中間件
隨著網(wǎng)站的繼續(xù)發(fā)展,的系統(tǒng)中可能出現(xiàn)不同語言開發(fā)的子模塊和部署在不同平臺的子系統(tǒng)。此時我們需要一個平臺來傳遞可靠的,與平臺和語言無關(guān)的數(shù)據(jù),并且能夠把負載均衡透明化,能在調(diào)用過程中收集并分析調(diào)用數(shù)據(jù),推測出網(wǎng)站的訪問增長率等等一系列需求,對于網(wǎng)站應該如何成長做出預測。開源消息中間件有阿里的Dubbo,可以搭配Google開源的分布式程序協(xié)調(diào)服務Zookeeper實現(xiàn)服務器的注冊與發(fā)現(xiàn)。
引入消息中間件后的結(jié)構(gòu):
以上的演變過程只是一個例子,并不適合所有的網(wǎng)站,實際中網(wǎng)站演進過程與自身業(yè)務和不同遇到的問題有密切的關(guān)系,沒有固定的模式。只有認真的分析和不斷地探究,才能發(fā)現(xiàn)適合自己網(wǎng)站的架構(gòu)。
分享標題:大型Web網(wǎng)站架構(gòu)演變方案分享
網(wǎng)頁URL:http://m.rwnh.cn/news40/100590.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供定制開發(fā)、網(wǎng)站排名、外貿(mào)網(wǎng)站建設、域名注冊、標簽優(yōu)化、網(wǎng)站內(nèi)鏈
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容