分析：網(wǎng)站的分布式架構

分析：網(wǎng)站的分布式架構

不管是B/S架構的企業(yè)管理系統(tǒng)還是網(wǎng)站技術架構可以抽象為如下簡圖：在傳統(tǒng)B/S架構的企業(yè)管理系統(tǒng)里，技術架構往往就是一個工程項目，各個邏輯分層都是該工程的業(yè)務邏輯模塊。但是作為提供公共服務的網(wǎng)站，由于用戶群比較龐大，網(wǎng)站并發(fā)量高，需求變化大，變更頻繁以及網(wǎng)站出于對安全的考慮，以上的邏輯分層在技術架構上的實現(xiàn)也就會復雜的多。本人前不久做一個網(wǎng)站，我設計的技術架構簡圖如下：我把網(wǎng)站項目拆分為三個子項目：前端項目、服務端項目和memcache項目，前端項目包含頁面、靜態(tài)資源和控制層；服務端項目包含業(yè)務層和數(shù)據(jù)庫操作層；memcache項目緩存前端項目和服務端項目公用的數(shù)據(jù)。在系統(tǒng)部署上，前端項目和服務端項目都采用分布式方式(我們的網(wǎng)站前端是4臺服務器，服務端是4臺服務器)，用戶請求進入前先通過負載均衡設備進行請求分發(fā)，前端和服務端之間以及服務端和數(shù)據(jù)庫之間有防火墻保證系統(tǒng)的安全性，前端的集群和服務端集群分屬到不同網(wǎng)絡環(huán)境里，前端集群可以訪問外網(wǎng)，服務端集群和數(shù)據(jù)庫所在網(wǎng)絡不能直接訪問外網(wǎng)，但是前端網(wǎng)絡環(huán)境和服務端網(wǎng)絡環(huán)境之間可以進行通信。服務端和客戶端用我們自定義的報文進行通訊，傳輸協(xié)議時http，由于本人所在的網(wǎng)站安全性要求比較高，用戶傳輸?shù)恼埱髤f(xié)議使用https。為了保證服務端和客戶端通訊的效率，客戶端和服務端通訊我們使用長連接(我們網(wǎng)站服務端語言選擇的是java，通訊層使用netty框架開發(fā)的)，為了保證長連接，我們寫了一個心跳檢測服務，該服務在后臺線程里運行，每個5分鐘檢測一次心跳，當然檢測的間隔時間是可以配置的。此外，我們事先估計過網(wǎng)站的最大并發(fā)量，在網(wǎng)站啟動時候，我們構建了一個線程池(我們使用的服務器是8核處理器，每核最大線程數(shù)256，所以我們線程池里總共的最大線程總數(shù)數(shù)是8*256*4=8196)，每個線程處理一個用戶的請求。由于客戶端項目采取分布式部署，因此存在session共享的問題，我們網(wǎng)站的session共享沒有使用web容器自帶的session共享機制，而是我們自己研發(fā)了一套session機制，原理很簡單，具體是我們會對每個用戶會話生成一個唯一標示，我們的唯一標示是這么設計：當前用戶的session的id值+隨機16位數(shù)字和字母組合+當前的納秒值，然后將該值哈希算出一個key，原有保存在session里的值保存在memcache集群里，這些數(shù)據(jù)的key就是我們算出的用戶唯一標示。最終我們網(wǎng)站前端不在使用session對象，而是我們自己設計的session機制，對此我們還封裝了一套自定義標簽，在頁面上操作我們自定義的session。服務端也有類似的共享機制，但是有所不同，當客戶端請求服務端時候，請求會具體落到服務端的某一臺服務器，因為本網(wǎng)站有些請求處理時異步的，也就是說客戶某些請求不是立即返回給用戶，而是現(xiàn)將請求分發(fā)給服務端，此時客戶端會返回用戶一個相應標示，說明該請求已經(jīng)被受理，正在處理中，而服務端的某個線程此時已經(jīng)開始處理了該請求，客戶端按一定時間間隔發(fā)送請求給服務端，問詢請求是否處理完成，但是服務端也是分布式，請求時隨機發(fā)送，客戶端的問詢可能會分發(fā)到別的服務器，因此這樣的請求，我會在客戶端記錄下處理的服務端ip地址和線程id，在問詢的時候就會訪問指定好的服務器和線程，直到請求處理完畢，最后關閉詢問，將結果返回給用戶。由于我們把一個網(wǎng)站項目拆分成了三個獨立項目，因此在項目管理和協(xié)調上增加了難度，所以我們引入maven框架對工程進行了管理和構建，同時構建一個common工程，專門負責服務端和前端公共程序的開發(fā)。本