網站架構

大型Java項目架構演進解析：

 

初期：應用，文件服務器，數據庫都部署在一臺服務器上（all in one）

接着，分別部署在不一樣的服務器上：

引入緩存：

引入負載均衡（調度策略）:

引入讀寫分離：

引入CDN和反向代理及分佈式文件服務器：

而後分庫、分表、搜索引擎、非關係型數據庫等等。

 

應用服務器集羣的 Session 管理：

應用服務器的高可用架構設計主要基於服務無狀態這一特性，可是事實上，業務老是有狀態的。

• 在交易類的電子商務網站，須要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增長商品；

• 在社交類的網站中，須要記錄用戶的當前登陸狀態，最新發布的消息及好友狀態等，用戶每次算新頁面都須要更新這些信息。

Web 應用中將這些屢次請求修改使用的上下文對象稱做會話（Session），單機狀況下，Session 可由部署在服務器上的 Web 容器（如 JBoss）管理。在使用負載均衡的集羣環境中，因爲負載均衡服務器可能會將請求分發到集羣任何一臺應用服務器上，因此保證每次請求依然可以得到正確的 Session 比單機時要複雜不少。

集羣環境下，Session 管理主要有如下幾種手段。

1.2.1 Session 複製

Session 複製是早期企業應用系統使用較多的一種服務器集羣 Session 管理機制。應用服務器開啓 Web 容器的 Session 複製功能，在集羣中的幾臺服務器之間同步 Session 對象，使得每臺服務器上都保存全部用戶的 Session 信息，這樣任何一臺機器宕機都不會致使 Session 數據的丟失，而服務器使用 Session 時，也只須要在本機獲取便可。以下圖所示：

這種方案雖然簡單，從本機讀取 Session 信息也很快速，但只能使用在集羣規模比較小的狀況下。當集羣規模較大時，集羣服務器間須要大量的通訊進行 Session 複製，佔用服務器和網絡的大量資源，系統不堪重負。並且因爲全部用戶的 Session 信息在每臺服務器上都有備份，在大量用戶訪問的狀況下，甚至會出現服務器內存不夠 Session 使用的狀況。

而大型網站的核心應用集羣就是數千臺服務器，同時在線用戶可達千萬，所以並不適用這種方案。

1.2.2 Session 綁定

Session 綁定能夠利用負載均衡的源地址 Hash 算法實現，負載均衡服務器老是未來源於同一 IP 的請求分發到同一臺服務器上（也能夠根據 Cookie 信息將同一個用戶的請求老是分發到同一臺服務器上，固然這時負載均衡服務器必須工做在 HTTP 協議層上。）這樣在整個會話期間，用戶全部的請求都在同一臺服務器上處理，即 Session 綁定在某臺特定服務器上，保證 Session 總能在這臺服務器上獲取。這種方法也被稱做會話粘滯。以下圖所示：

可是 Session 綁定的方案顯然不符合咱們對於系統高可用的需求，由於一旦某臺服務器宕機，那麼該機器上的 Session 也就不復存在了，用戶請求切換到其餘機器後由於沒有 Session 而沒法完成業務處理。所以雖然大部分負載均衡服務器都提供源地址負載均衡算法，但不多有網站利用這個算法進行 Session 管理。

1.2.3 利用 Cookie 記錄 Session

早期的企業應用系統使用 C/S（客戶端/服務器）架構，一種管理 Session 的方式是將 Session 記錄在客戶端，每次請求服務器的時候，將 Session 放在請求中發送給服務器，服務器處理完請求後再將修改過的 Session 響應給客戶端。

網站沒有客戶端，可是能夠利用瀏覽器支持的 Cookie 記錄 Session，以下圖所示：

利用 Cookie 記錄 Session 也有一些缺點，好比：

• 受 Cookie 大小限制，能記錄的信息有限；

• 每次請求響應都須要傳輸 Cookie ，影響性能；

• 若是用戶關閉 Cookie ，訪問就會不正常。

可是因爲 Cookie  的簡單易用，可用性高，支持應用服務器的線性伸縮，而大部分應用須要記錄的 Session 信息又比較小。所以事實上，許多網站都或多或少地使用 Cookie 記錄 Session。

1.2.4 Session 服務器

那麼有沒有可用性高、伸縮性好、性能也不錯，對信息大小又沒有限制的服務器集羣 Session 管理方案呢？

答案就是 Session 服務器。利用獨立部署的 Session 服務器（集羣）統一管理 Session ，應用服務器每次讀寫 Session 時，都訪問 Session 服務器。以下圖所示：

這種解決方案事實上是將應用服務器的狀態分離，分爲無狀態的應用服務器和有狀態的 Session 服務器，而後針對這兩種服務器的不一樣特性分別設計其架構。

對於有狀態的 Session 服務器，一種比較簡單的方法是利用分佈式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合 Session 的存儲和訪問要求。若是業務場景對 Session 管理有比較高的要求，好比利用 Session 服務集成單點登陸（SSO）、用戶服務等功能，則須要開發專門的 Session 服務管理平臺。

 

CDN和反向代理：

網站須要加速網站的訪問速度，主要手段有使用CDN和反向代理。

SDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，能夠從距離本身最近的網絡提供商機房獲取數據；

而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器反向代理服務器，若是反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。

使用這兩個技術，都是爲了：一方面加快用戶訪問速度，另外一方面也減輕了後端服務器的負載壓力。