【經典必讀】web網站架構演變過程，電商網站升級打怪__web

               【經典必讀】web網站架構演變過程，電商網站升級打怪 前言

我們以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種解決方案：

http重新導向。HTTP重新導向就是應用程式層的請求轉寄。使用者的請求其實已經到了HTTP重新導向負載平衡伺服器，伺服器根據演算法要求使用者重新導向，使用者收到重新導向請求後，再次請求真正的叢集

優點：簡單。

缺點：效能較差。

DNS網域名稱解析負載平衡。DNS網域名稱解析負載平衡就是在使用者請求DNS伺服器，擷取網域名稱對應的IP地址時，DNS伺服器直接給出負載平衡後的伺服器IP。

優點：交給DNS，不用我們去維護負載平衡伺服器。

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

反向 Proxy伺服器。在使用者的請求到達反向 Proxy伺服器時（已經到達網站機房），由反向 Proxy伺服器根據演算法轉寄到具體的伺服器。常用的apache，nginx都可以充當反向 Proxy伺服器。

優點：部署簡單。

缺點：Proxy 伺服器可能成為效能的瓶頸，特別是一次上傳大檔案。

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

優點：效能更好。

缺點：負載平衡器的寬頻成為瓶頸。

資料連結層負載平衡。在請求到達負載平衡器後，負載平衡器通過修改請求的mac地址，從而做到負載平衡，與IP負載平衡不一樣的是，當請求訪問完伺服器之後，直接返回客戶。而無需再經過負載平衡器。

 

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

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

優點：實現簡單

缺點：不考慮每台伺服器的處理能力

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

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

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

dh 目標地址散列：同上，只是現在提取的是目標地址的IP來做雜湊。

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

lc 最少串連。優先把請求轉寄給串連數少的伺服器。

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

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

優點：可以根據伺服器的能力分配請求。sed 最短期望延遲。其實sed跟wlc類似，區別是不考慮非活動串連數。演算法為：（活動串連數+1)*256÷權重，同樣計算出來的值小的伺服器優先被選擇。

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

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

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

 

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

NAT：負載平衡器接收使用者的請求，轉寄給具體伺服器，伺服器處理完請求返回給均衡器，均衡器再重新返回給使用者。

DR：負載平衡器接收使用者的請求，轉寄給具體伺服器，伺服器出來玩請求後直接返回給使用者。需要系統支援IP Tunneling協議，難以跨平台。

TUN：同上，但無需IP Tunneling協議，跨平台性好，大部分系統都可以支援。

 

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

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

優點：實現簡單。

缺點：應用伺服器重啟則session消失。

Session Replication。session replication就是在叢集中複製session，使得每個伺服器都儲存有全部使用者的session資料。

優點：減輕負載平衡伺服器的壓力，不需要要實現ip_hasp演算法來轉寄請求。

缺點：複製時寬頻開銷大，訪問量大的話session佔用記憶體大且浪費。

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

優點：相比session replication的方案，叢集間對於寬頻和記憶體的壓力減少了很多。

缺點：需要維護儲存session的資料庫。

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共用的支援。

 

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

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

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