Web網站架構演變歷程

2020 年 3 月 3 日
筆記

點擊上方 好好學java ，選擇星標公眾號

重磅資訊、乾貨，第一時間送達今日推薦：用好Java中的枚舉，真的沒有那麼簡單！個人原創+1部落格：點擊前往，查看更多

作者：小M  cnblogs.com/xiaoMzjm/p/5223799.html

前言

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

該系統具備的功能：

用戶模組：用戶註冊和管理
商品模組：商品展示和管理
交易模組：創建交易和管理

階段一、單機構建網站

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

最後再選擇一個資料庫管理系統來存儲數據，如mysql、sqlserver、oracle，然後通過JDBC進行資料庫的連接和操作。

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

階段二、應用伺服器與資料庫分離

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

增加的機器用來做什麼呢？此時我們可以把資料庫，web伺服器拆分開來，這樣不僅提高了單台機器的負載能力，也提高了容災能力。

應用伺服器與資料庫分開後的架構如下圖所示：

階段三、應用伺服器集群

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

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

我們以增加了一台應用伺服器為例，增加後的系統結構圖如下：

系統演變到這裡，將會出現下面四個問題：

用戶的請求由誰來轉發到到具體的應用伺服器
有什麼轉發的演算法
應用伺服器如何返回用戶的請求
用戶如果每次訪問到的伺服器不一樣，那麼如何維護session的一致性

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

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

**1、http重定向。**HTTP重定向就是應用層的請求轉發。用戶的請求其實已經到了HTTP重定向負載均衡伺服器，伺服器根據演算法要求用戶重定向，用戶收到重定向請求後，再次請求真正的集群

優點：簡單。
缺點：性能較差。

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

優點：交給DNS，不用我們去維護負載均衡伺服器。
缺點：當一個應用伺服器掛了，不能及時通知DNS，而且DNS負載均衡的控制權在域名服務商那裡，網站無法做更多的改善和更強大的管理。

**3、反向代理伺服器。**在用戶的請求到達反向代理伺服器時（已經到達網站機房），由反向代理伺服器根據演算法轉發到具體的伺服器。常用的apache，nginx都可以充當反向代理伺服器。

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

**4、IP層負載均衡。**在請求到達負載均衡器後，負載均衡器通過修改請求的目的IP地址，從而實現請求的轉發，做到負載均衡。

優點：性能更好。
缺點：負載均衡器的寬頻成為瓶頸。

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

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

**1、rr 輪詢調度演算法。**顧名思義，輪詢分發請求。

優點：實現簡單
缺點：不考慮每台伺服器的處理能力

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

優點：考慮了伺服器處理能力的不同

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

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

優點：以上兩種演算法的都能實現同一個用戶訪問同一個伺服器。

**5、lc 最少連接。**優先把請求轉發給連接數少的伺服器。

優點：使得集群中各個伺服器的負載更加均勻。

6、wlc 加權最少連接。在lc的基礎上，為每台伺服器加上權值。演算法為：（活動連接數*256+非活動連接數）÷權重，計算出來的值小的伺服器優先被選擇。

優點：可以根據伺服器的能力分配請求。

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

**8、nq 永不排隊。**改進的sed演算法。我們想一下什麼情況下才能「永不排隊」，那就是伺服器的連接數為0的時候，那麼假如有伺服器連接數為0，均衡器直接把請求轉發給它，無需經過sed的計算。

**9、LBLC 基於局部性的最少連接。**均衡器根據請求的目的IP地址，找出該IP地址最近被使用的伺服器，把請求轉發之，若該伺服器超載，最採用最少連接數演算法。

**10、LBLCR 帶複製的基於局部性的最少連接。**均衡器根據請求的目的IP地址，找出該IP地址最近使用的「伺服器組」，注意，並不是具體某個伺服器，然後採用最少連接數從該組中挑出具體的某台伺服器出來，把請求轉發之。若該伺服器超載，那麼根據最少連接數演算法，在集群的非本伺服器組的伺服器中，找出一台伺服器出來，加入本伺服器組，然後把請求轉發之。

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

NAT：負載均衡器接收用戶的請求，轉發給具體伺服器，伺服器處理完請求返回給均衡器，均衡器再重新返回給用戶。
DR：負載均衡器接收用戶的請求，轉發給具體伺服器，伺服器出來玩請求後直接返回給用戶。需要系統支援IP Tunneling協議，難以跨平台。
TUN：同上，但無需IP Tunneling協議，跨平台性好，大部分系統都可以支援。

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

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

優點：實現簡單。
缺點：應用伺服器重啟則session消失。

**2、Session Replication。**session replication就是在集群中複製session，使得每個伺服器都保存有全部用戶的session數據。

優點：減輕負載均衡伺服器的壓力，不需要要實現ip_hasp演算法來轉發請求。
缺點：複製時寬頻開銷大，訪問量大的話session佔用記憶體大且浪費。

3、Session數據集中存儲：session數據集中存儲就是利用資料庫來存儲session數據，實現了session和應用伺服器的解耦。

優點：相比session replication的方案，集群間對於寬頻和記憶體的壓力減少了很多。
缺點：需要維護存儲session的資料庫。

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

優點：實現簡單，基本免維護。
缺點：cookie長度限制，安全性低，寬頻消耗。

值得一提的是：

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

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

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

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

好了，解決了以上的問題之後，系統的結構如下：

階段四、資料庫讀寫分離化

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

但對於資料庫來說，並沒有那麼簡單。假如我們簡單的把資料庫一分為二，然後對於資料庫的請求，分別負載到A機器和B機器，那麼顯而易見會造成兩台資料庫數據不統一的問題。那麼對於這種情況，我們可以先考慮使用讀寫分離的方式。

讀寫分離後的資料庫系統結構如下：

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

主從資料庫之間數據同步問題
應用對於數據源的選擇問題

解決問題方案：

我們可以使用MYSQL自帶的master+slave的方式實現主從複製。

採用第三方資料庫中間件，例如mycat。mycat是從cobar發展而來的，而cobar是阿里開源的資料庫中間件，後來停止開發。mycat是中國比較好的mysql開源資料庫分庫分表中間件。

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

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

搜索引擎具有以下優點：

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

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

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

搜索引擎並不能替代資料庫，他解決了某些場景下的「讀」的問題，是否引入搜索引擎，需要綜合考慮整個系統的需求。引入搜索引擎後的系統結構如下：

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

1、後台應用層和資料庫層的快取

隨著訪問量的增加，逐漸出現了許多用戶訪問同一部分內容的情況，對於這些比較熱門的內容，沒必要每次都從資料庫讀取。我們可以使用快取技術，例如可以使用google的開源快取技術guava或者使用memcacahe作為應用層的快取，也可以使用redis作為資料庫層的快取。

另外，在某些場景下，關係型資料庫並不是很適合，例如我想做一個「每日輸入密碼錯誤次數限制」的功能，思路大概是在用戶登錄時，如果登錄錯誤，則記錄下該用戶的IP和錯誤次數，那麼這個數據要放在哪裡呢？

假如放在記憶體中，那麼顯然會佔用太大的內容；假如放在關係型資料庫中，那麼既要建立資料庫表，還要簡歷對應的java bean，還要寫SQL等等。而分析一下我們要存儲的數據，無非就是類似{ip:errorNumber}這樣的key:value數據。對於這種數據，我們可以用NOSQL資料庫來代替傳統的關係型資料庫。

2、頁面快取

除了數據快取，還有頁面快取。比如使用HTML5的localstroage或者cookie。

優點：

減輕資料庫的壓力
大幅度提高訪問速度

缺點：

需要維護快取伺服器
提高了編碼的複雜性

值得一提的是：

快取集群的調度演算法不同與上面提到的應用伺服器和資料庫。最好採用「一致性哈希演算法」，這樣才能提高命中率。這個就不展開講了，有興趣的可以查閱相關資料。

加入快取後的結構：

階段七、資料庫水平拆分與垂直拆分

我們的網站演進到現在，交易、商品、用戶的數據都還在同一個資料庫中。儘管採取了增加快取，讀寫分離的方式，但隨著資料庫的壓力繼續增加，資料庫的瓶頸越來越突出，此時，我們可以有數據垂直拆分和水平拆分兩種選擇。

7.1、數據垂直拆分

垂直拆分的意思是把資料庫中不同的業務數據拆分道不同的資料庫中，結合現在的例子，就是把交易、商品、用戶的數據分開。

優點：

解決了原來把所有業務放在一個資料庫中的壓力問題。
可以根據業務的特點進行更多的優化

缺點：

需要維護多個資料庫

問題：

需要考慮原來跨業務的事務
跨資料庫的join

解決問題方案：

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

垂直拆分後的結構如下：

7.2、數據水平拆分

數據水平拆分就是把同一個表中的數據拆分到兩個甚至多個資料庫中。產生數據水平拆分的原因是某個業務的數據量或者更新量到達了單個資料庫的瓶頸，這時就可以把這個表拆分到兩個或更多個資料庫中。

優點：

如果我們能客服以上問題，那麼我們將能夠很好地對數據量及寫入量增長的情況。

問題：

訪問用戶資訊的應用系統需要解決SQL路由的問題，因為現在用戶資訊分在了兩個資料庫中，需要在進行數據操作時了解需要操作的數據在哪裡。
主鍵的處理也變得不同，例如原來自增欄位，現在不能簡單地繼續使用了。
如果需要分頁，就麻煩了。

解決問題方案：

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

數據水平拆分後的結構：

階段八、應用的拆分

8.1、拆分應用

隨著業務的發展，業務越來越多，應用越來越大。我們需要考慮如何避免讓應用越來越臃腫。這就需要把應用拆開，從一個應用變為倆個甚至更多。還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變成「用戶、商品」和「用戶，交易」兩個子系統。

拆分後的結構：

問題：

這樣拆分後，可能會有一些相同的程式碼，如用戶相關的程式碼，商品和交易都需要用戶資訊，所以在兩個系統中都保留差不多的操作用戶資訊的程式碼。如何保證這些程式碼可以復用是一個需要解決的問題。

解決問題：

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

8.2、走服務化的道路

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

採用服務化之後的系統結構：

優點：

相同的程式碼不會散落在不同的應用中了，這些實現放在了各個服務中心，使程式碼得到更好的維護。
我們把對資料庫的交互放在了各個服務中心，讓」前端「的web應用更注重與瀏覽器交互的工作。

問題：

如何進行遠程的服務調用

解決方法：

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

階段九、引入消息中間件

隨著網站的繼續發展，我們的系統中可能出現不同語言開發的子模組和部署在不同平台的子系統。此時我們需要一個平台來傳遞可靠的，與平台和語言無關的數據，並且能夠把負載均衡透明化，能在調用過程中收集調用數據並分析之，推測出網站的訪問增長率等等一系列需求，對於網站應該如何成長做出預測。

開源消息中間件有阿里的dubbo，可以搭配Google開源的分散式程式協調服務zookeeper實現伺服器的註冊與發現。

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

十、總結

以上的演變過程只是一個例子，並不適合所有的網站，實際中網站演進過程與自身業務和不同遇到的問題有密切的關係，沒有固定的模式。只有認真的分析和不斷地探究，才能發現適合自己網站的架構。

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

參考：

★《大型網站技術架構：核心原理與案例分析》——李智慧著《大型網站系統與Java中間件實踐》——曾憲傑著《MySQL性能調優與架構設計》——簡朝陽著《keepalived權威指南》《mycat權威指南》《dubbo用戶指南》《電腦網路》《作業系統》」