前言

我們以javaweb為例，來搭建一個簡單的電商系統(tǒng)，看看這個系統(tǒng)可以如何一步步演變。

該系統(tǒng)具備的功能：

• 用戶模塊：用戶注冊和管理
• 商品模塊：商品展示和管理
• 交易模塊：創(chuàng)建交易和管理

---

階段一、單機構建網(wǎng)站

網(wǎng)站的初期，我們經(jīng)常會在單機上跑我們所有的程序和軟件。此時我們使用一個容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技術，或者使用一些開源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；

最后再選擇一個數(shù)據(jù)庫管理系統(tǒng)來存儲數(shù)據(jù)，如mysql、sqlserver、oracle，然后通過JDBC進行數(shù)據(jù)庫的連接和操作。

把以上的所有軟件都裝載同一臺機器上，應用跑起來了，也算是一個小系統(tǒng)了。此時系統(tǒng)結果如下：

---

階段二、應用服務器與數(shù)據(jù)庫分離

隨著網(wǎng)站的上線，訪問量逐步上升，服務器的負載慢慢提高，在服務器還沒有超載的時候，我們應該就要做好準備，提升網(wǎng)站的負載能力。假如我們代碼層面已難以優(yōu)化，在不提高單臺機器的性能的情況下，增加機器是一個不錯的方式，不僅可以有效地提高系統(tǒng)的負載能力，而且性價比高。

增加的機器用來做什么呢？此時我們可以把數(shù)據(jù)庫，web服務器拆分開來，這樣不僅提高了單臺機器的負載能力，也提高了容災能力。

應用服務器與數(shù)據(jù)庫分開后的架構如下圖所示：

---

階段三、應用服務器集群

隨著訪問量繼續(xù)增加，單臺應用服務器已經(jīng)無法滿足需求了。在假設數(shù)據(jù)庫服務器沒有壓力的情況下，我們可以把應用服務器從一臺變成了兩臺甚至多臺，把用戶的請求分散到不同的服務器中，從而提高負載能力。

多臺應用服務器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對外提供服務。著名的做故障切換的軟件有keepalived，keepalived是一個類似于layer3、4、7交換機制的軟件，他不是某個具體軟件故障切換的專屬品，而是可以適用于各種軟件的一款產(chǎn)品。keepalived配合上ipvsadm又可以做負載均衡，可謂是神器。

我們以增加了一臺應用服務器為例，增加后的系統(tǒng)結構圖如下：

系統(tǒng)演變到這里，將會出現(xiàn)下面四個問題：

• 用戶的請求由誰來轉發(fā)到到具體的應用服務器
• 有什么轉發(fā)的算法
• 應用服務器如何返回用戶的請求
• 用戶如果每次訪問到的服務器不一樣，那么如何維護session的一致性

我們來看看解決問題的方案：

1、第一個問題即是負載均衡的問題，一般有5種解決方案：

1、http重定向。HTTP重定向就是應用層的請求轉發(fā)。用戶的請求其實已經(jīng)到了HTTP重定向負載均衡服務器，服務器根據(jù)算法要求用戶重定向，用戶收到重定向請求后，再次請求真正的集群

• 優(yōu)點：簡單。
• 缺點：性能較差。

2、DNS域名解析負載均衡。DNS域名解析負載均衡就是在用戶請求DNS服務器，獲取域名對應的IP地址時，DNS服務器直接給出負載均衡后的服務器IP。

優(yōu)點：交給DNS，不用我們去維護負載均衡服務器。

缺點：當一個應用服務器掛了，不能及時通知DNS，而且DNS負載均衡的控制權在

域名服務商3、反向代理服務器。在用戶的請求到達反向代理服務器時（已經(jīng)到達網(wǎng)站機房），由反向代理服務器根據(jù)算法轉發(fā)到具體的服務器。常用的apache，nginx都可以充當反向代理服務器。

• 優(yōu)點：部署簡單。
• 缺點：代理服務器可能成為性能的瓶頸，特別是一次上傳大文件。

4、IP層負載均衡。在請求到達負載均衡器后，負載均衡器通過修改請求的目的IP地址，從而實現(xiàn)請求的轉發(fā)，做到負載均衡。

• 優(yōu)點：性能更好。
• 缺點：負載均衡器的寬帶成為瓶頸。

5、數(shù)據(jù)鏈路層負載均衡。在請求到達負載均衡器后，負載均衡器通過修改請求的mac地址，從而做到負載均衡，與IP負載均衡不一樣的是，當請求訪問完服務器之后，直接返回客戶。而無需再經(jīng)過負載均衡器。

2、第二個問題即是集群調度算法問題，常見的調度算法有10種。

1、rr 輪詢調度算法。顧名思義，輪詢分發(fā)請求。

• 優(yōu)點：實現(xiàn)簡單
• 缺點：不考慮每臺服務器的處理能力

2、wrr 加權調度算法。我們給每個服務器設置權值weight，負載均衡調度器根據(jù)權值調度服務器，服務器被調用的次數(shù)跟權值成正比。

• 優(yōu)點：考慮了服務器處理能力的不同

3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個key，再根據(jù)靜態(tài)映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。

4、dh 目標地址散列：同上，只是現(xiàn)在提取的是目標地址的IP來做哈希。

• 優(yōu)點：以上兩種算法的都能實現(xiàn)同一個用戶訪問同一個服務器。

5、lc 最少連接。優(yōu)先把請求轉發(fā)給連接數(shù)少的服務器。

• 優(yōu)點：使得集群中各個服務器的負載更加均勻。

6、wlc 加權最少連接。在lc的基礎上，為每臺服務器加上權值。算法為：（活動連接數(shù)*256+非活動連接數(shù)）÷權重 ，計算出來的值小的服務器優(yōu)先被選擇。

• 優(yōu)點：可以根據(jù)服務器的能力分配請求。

7、sed 最短期望延遲。其實sed跟wlc類似，區(qū)別是不考慮非活動連接數(shù)。算法為：（活動連接數(shù)+1)*256÷權重，同樣計算出來的值小的服務器優(yōu)先被選擇。

8、nq 永不排隊。改進的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務器的連接數(shù)為0的時候，那么假如有服務器連接數(shù)為0，均衡器直接把請求轉發(fā)給它，無需經(jīng)過sed的計算。

9、LBLC 基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉發(fā)之，若該服務器超載，最采用最少連接數(shù)算法。

10、LBLCR 帶復制的基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近使用的“服務器組”，注意，并不是具體某個服務器，然后采用最少連接數(shù)從該組中挑出具體的某臺服務器出來，把請求轉發(fā)之。若該服務器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，然后把請求轉發(fā)之。

3、第三個問題是集群模式問題，一般3種解決方案：

• NAT：負載均衡器接收用戶的請求，轉發(fā)給具體服務器，服務器處理完請求返回給均衡器，均衡器再重新返回給用戶。
• DR：負載均衡器接收用戶的請求，轉發(fā)給具體服務器，服務器出來玩請求后直接返回給用戶。需要系統(tǒng)支持IP Tunneling協(xié)議，難以跨平臺。
• TUN：同上，但無需IP Tunneling協(xié)議，跨平臺性好，大部分系統(tǒng)都可以支持。

4、第四個問題是session問題，一般有4種解決方案：

1、Session Sticky。session sticky就是把同一個用戶在某一個會話中的請求，都分配到固定的某一臺服務器中，這樣我們就不需要解決跨服務器的session問題了，常見的算法有ip_hash法，即上面提到的兩種散列算法。

• 優(yōu)點：實現(xiàn)簡單。
• 缺點：應用服務器重啟則session消失。

2、Session Replication。session replication就是在集群中復制session，使得每個服務器都保存有全部用戶的session數(shù)據(jù)。

• 優(yōu)點：減輕負載均衡服務器的壓力，不需要要實現(xiàn)ip_hasp算法來轉發(fā)請求。
• 缺點：復制時寬帶開銷大，訪問量大的話session占用內存大且浪費。

3、Session數(shù)據(jù)集中存儲：session數(shù)據(jù)集中存儲就是利用數(shù)據(jù)庫來存儲session數(shù)據(jù)，實現(xiàn)了session和應用服務器的解耦。

• 優(yōu)點：相比session replication的方案，集群間對于寬帶和內存的壓力減少了很多。
• 缺點：需要維護存儲session的數(shù)據(jù)庫。

4、Cookie Base：cookie base就是把session存在cookie中，有瀏覽器來告訴應用服務器我的session是什么，同樣實現(xiàn)了session和應用服務器的解耦。

• 優(yōu)點：實現(xiàn)簡單，基本免維護。
• 缺點：cookie長度限制，安全性低，寬帶消耗。

值得一提的是：

nginx目前支持的負載均衡算法有wrr、sh（支持一致性哈希）、fair（本人覺得可以歸結為lc）。但nginx作為均衡器的話，還可以一同作為靜態(tài)資源服務器。

keepalived+ipvsadm比較強大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh

keepalived支持集群模式有：NAT、DR、TUN

nginx本身并沒有提供session同步的解決方案，而apache則提供了session共享的支持。

好了，解決了以上的問題之后，系統(tǒng)的結構如下：

---

階段四、數(shù)據(jù)庫讀寫分離化

上面我們總是假設數(shù)據(jù)庫負載正常，但隨著訪問量的的提高，數(shù)據(jù)庫的負載也在慢慢增大。那么可能有人馬上就想到跟應用服務器一樣，把數(shù)據(jù)庫一份為二再負載均衡即可。

但對于數(shù)據(jù)庫來說，并沒有那么簡單。假如我們簡單的把數(shù)據(jù)庫一分為二，然后對于數(shù)據(jù)庫的請求，分別負載到A機器和B機器，那么顯而易見會造成兩臺數(shù)據(jù)庫數(shù)據(jù)不統(tǒng)一的問題。那么對于這種情況，我們可以先考慮使用讀寫分離的方式。

讀寫分離后的數(shù)據(jù)庫系統(tǒng)結構如下：

這個結構變化后也會帶來兩個問題：

• 主從數(shù)據(jù)庫之間數(shù)據(jù)同步問題
• 應用對于數(shù)據(jù)源的選擇問題

解決問題方案：

我們可以使用MYSQL自帶的master+slave的方式實現(xiàn)主從復制。

采用第三方數(shù)據(jù)庫中間件，例如mycat。mycat是從cobar發(fā)展而來的，而cobar是阿里開源的數(shù)據(jù)庫中間件，后來停止開發(fā)。mycat是國內比較好的mysql開源數(shù)據(jù)庫分庫分表中間件。

---

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

數(shù)據(jù)庫做讀庫的話，常常對模糊查找力不從心，即使做了讀寫分離，這個問題還未能解決。以我們所舉的交易網(wǎng)站為例，發(fā)布的商品存儲在數(shù)據(jù)庫中，用戶最常使用的功能就是查找商品，尤其是根據(jù)商品的標題來查找對應的商品。對于這種需求，一般我們都是通過like功能來實現(xiàn)的，但是這種方式的代價非常大。此時我們可以使用搜索引擎的倒排索引來完成。

搜索引擎具有以下優(yōu)點：

• 它能夠大大提高查詢速度。

引入搜索引擎后也會帶來以下的開銷：

• 帶來大量的維護工作，我們需要自己實現(xiàn)索引的構建過程，設計全量/增加的構建方式來應對非實時與實時的查詢需求。
• 需要維護搜索引擎集群

搜索引擎并不能替代數(shù)據(jù)庫，他解決了某些場景下的“讀”的問題，是否引入搜索引擎，需要綜合考慮整個系統(tǒng)的需求。引入搜索引擎后的系統(tǒng)結構如下：

---

階段六、用緩存緩解讀庫的壓力

1、后臺應用層和數(shù)據(jù)庫層的緩存

隨著訪問量的增加，逐漸出現(xiàn)了許多用戶訪問同一部分內容的情況，對于這些比較熱門的內容，沒必要每次都從數(shù)據(jù)庫讀取。我們可以使用緩存技術，例如可以使用google的開源緩存技術guava或者使用memcacahe作為應用層的緩存，也可以使用redis作為數(shù)據(jù)庫層的緩存。

另外，在某些場景下，關系型數(shù)據(jù)庫并不是很適合，例如我想做一個“每日輸入密碼錯誤次數(shù)限制”的功能，思路大概是在用戶登錄時，如果登錄錯誤，則記錄下該用戶的IP和錯誤次數(shù)，那么這個數(shù)據(jù)要放在哪里呢？

假如放在內存中，那么顯然會占用太大的內容；假如放在關系型數(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)的關系型數(shù)據(jù)庫。

2、頁面緩存

除了數(shù)據(jù)緩存，還有頁面緩存。比如使用HTML5的localstroage或者cookie。

優(yōu)點：

• 減輕數(shù)據(jù)庫的壓力
• 大幅度提高訪問速度

缺點：

• 需要維護緩存服務器
• 提高了編碼的復雜性

值得一提的是：

• 緩存集群的調度算法不同與上面提到的應用服務器和數(shù)據(jù)庫。最好采用“一致性哈希算法”，這樣才能提高命中率。這個就不展開講了，有興趣的可以查閱相關資料。

加入緩存后的結構：

---

階段七、數(shù)據(jù)庫水平拆分與垂直拆分

我們的網(wǎng)站演進到現(xiàn)在，交易、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中。盡管采取了增加緩存，讀寫分離的方式，但隨著數(shù)據(jù)庫的壓力繼續(xù)增加，數(shù)據(jù)庫的瓶頸越來越突出，此時，我們可以有數(shù)據(jù)垂直拆分和水平拆分兩種選擇。

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

垂直拆分的意思是把數(shù)據(jù)庫中不同的業(yè)務數(shù)據(jù)拆分道不同的數(shù)據(jù)庫中，結合現(xiàn)在的例子，就是把交易、商品、用戶的數(shù)據(jù)分開。

優(yōu)點：

• 解決了原來把所有業(yè)務放在一個數(shù)據(jù)庫中的壓力問題。
• 可以根據(jù)業(yè)務的特點進行更多的優(yōu)化

缺點：

• 需要維護多個數(shù)據(jù)庫

問題：

• 需要考慮原來跨業(yè)務的事務
• 跨數(shù)據(jù)庫的join

解決問題方案：

• 我們應該在應用層盡量避免跨數(shù)據(jù)庫的事物，如果非要跨數(shù)據(jù)庫，盡量在代碼中控制。
• 我們可以通過第三方應用來解決，如上面提到的mycat，mycat提供了豐富的跨庫join方案，詳情可參考mycat官方文檔。

垂直拆分后的結構如下：

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

數(shù)據(jù)水平拆分就是把同一個表中的數(shù)據(jù)拆分到兩個甚至多個數(shù)據(jù)庫中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個業(yè)務的數(shù)據(jù)量或者更新量到達了單個數(shù)據(jù)庫的瓶頸，這時就可以把這個表拆分到兩個或更多個數(shù)據(jù)庫中。

優(yōu)點：

• 如果我們能客服以上問題，那么我們將能夠很好地對數(shù)據(jù)量及寫入量增長的情況。

問題：

• 訪問用戶信息的應用系統(tǒng)需要解決SQL路由的問題，因為現(xiàn)在用戶信息分在了兩個數(shù)據(jù)庫中，需要在進行數(shù)據(jù)操作時了解需要操作的數(shù)據(jù)在哪里。
• 主鍵的處理也變得不同，例如原來自增字段，現(xiàn)在不能簡單地繼續(xù)使用了。
• 如果需要分頁，就麻煩了。

解決問題方案：

• 我們還是可以通過可以解決第三方中間件，如mycat。mycat可以通過SQL解析模塊對我們的SQL進行解析，再根據(jù)我們的配置，把請求轉發(fā)到具體的某個數(shù)據(jù)庫。
• 我們可以通過UUID保證唯一或自定義ID方案來解決。
• mycat也提供了豐富的分頁查詢方案，比如先從每個數(shù)據(jù)庫做分頁查詢，再合并數(shù)據(jù)做一次分頁查詢等等。

數(shù)據(jù)水平拆分后的結構：

---

階段八、應用的拆分

8.1、拆分應用

隨著業(yè)務的發(fā)展，業(yè)務越來越多，應用越來越大。我們需要考慮如何避免讓應用越來越臃腫。這就需要把應用拆開，從一個應用變?yōu)閭z個甚至更多。還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變成“用戶、商品”和“用戶，交易”兩個子系統(tǒng)。

拆分后的結構：

問題：

• 這樣拆分后，可能會有一些相同的代碼，如用戶相關的代碼，商品和交易都需要用戶信息，所以在兩個系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復用是一個需要解決的問題。

解決問題：

• 通過走服務化的路線來解決

8.2、走服務化的道路

為了解決上面拆分應用后所出現(xiàn)的問題，我們把公共的服務拆分出來，形成一種服務化的模式，簡稱SOA。

采用服務化之后的系統(tǒng)結構：

優(yōu)點：

• 相同的代碼不會散落在不同的應用中了，這些實現(xiàn)放在了各個服務中心，使代碼得到更好的維護。
• 我們把對數(shù)據(jù)庫的交互放在了各個服務中心，讓”前端“的web應用更注重與瀏覽器交互的工作。

問題：

• 如何進行遠程的服務調用

解決方法：

• 我們可以通過下面的引入消息中間件來解決

---

階段九、引入消息中間件

隨著網(wǎng)站的繼續(xù)發(fā)展，我們的系統(tǒng)中可能出現(xiàn)不同語言開發(fā)的子模塊和部署在不同平臺的子系統(tǒng)。此時我們需要一個平臺來傳遞可靠的，與平臺和語言無關的數(shù)據(jù)，并且能夠把負載均衡透明化，能在調用過程中收集調用數(shù)據(jù)并分析之，推測出網(wǎng)站的訪問增長率等等一系列需求，對于網(wǎng)站應該如何成長做出預測。

開源消息中間件有阿里的dubbo，可以搭配Google開源的分布式程序協(xié)調服務zookeeper實現(xiàn)服務器的注冊與發(fā)現(xiàn)。

引入消息中間件后的結構：

---

十、總結

以上的演變過程只是一個例子，并不適合所有的網(wǎng)站，實際中網(wǎng)站演進過程與自身業(yè)務和不同遇到的問題有密切的關系，沒有固定的模式。只有認真的分析和不斷地探究，才能發(fā)現(xiàn)適合自己網(wǎng)站的架構。

本文有什么說錯的地方，希望大家指出，讓我好改正過來，多謝。

當前文章：Web網(wǎng)站架構是如何一步步演變的？
網(wǎng)站地址：http://jinyejixie.com/news/99096.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、企業(yè)網(wǎng)站制作、動態(tài)網(wǎng)站、微信小程序、網(wǎng)站設計公司、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)