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