網站的分布式架構

http://www.cnblogs.com/sharpxiajun/archive/2013/05/11/3072798.html 

　　互連網的網站和大部分企業管理軟體一樣都是使用B/S架構模型，但是大型的公用網站B/S架構會更加複雜，對架構人員的要求更高，今天我想在自己部落格裡聊聊我設計的網站的B/S技術架構。

　　不管是B/S架構的企業管理系統還是網站技術架構可以抽象為如下簡圖：

　　在傳統B/S架構的企業管理系統裡，技術架構往往就是一個工程項目，各個邏輯分層都是該工程的商務邏輯模組。但是作為提供公用服務的網站，由於使用者群比較龐大，網站並發量高，需求變化大，變更頻繁以及網站出於對安全的考慮，以上的邏輯分層在技術架構上的實現也就會複雜的多。本人前不久做一個網站，我設計的技術架構簡圖如下：

 

　　我把網站項目拆分為三個子項目：前端項目、服務端項目和memcache項目，前端項目包含頁面、靜態資源和控制層；服務端項目包含業務層和資料庫操作層；memcache項目緩衝前端項目和服務端項目公用的資料。

　　在系統部署上，前端項目和服務端項目都採用分布式方式（我們的網站前端是4台伺服器，服務端是4台伺服器），使用者請求進入前先通過負載平衡裝置進行請求分發，前端和服務端之間以及服務端和資料庫之間有防火牆保證系統的安全性，前端的叢集和服務端叢集分屬到不同網路環境裡，前端叢集可以訪問外網，服務端叢集和資料庫所在網路不能直接存取外網，但是前端網路環境和服務端網路環境之間可以進行通訊。

　　服務端和用戶端用我們自訂的報文進行通訊，傳輸協議時http，由於本人所在的網站安全性要求比較高，使用者傳輸的請求協議使用https。

　　為了保證服務端和用戶端通訊的效率，用戶端和服務端通訊我們使用長串連（我們網站服務端語言選擇的是java，通訊層使用netty架構開發的），為了保證長串連，我們寫了一個心跳檢測服務，該服務在後台線程裡運行，每個5分鐘檢測一次心跳，當然檢測的間隔時間是可以配置的。此外，我們事先估計過網站的最大並發量，在網站啟動時候，我們構建了一個線程池（我們使用的伺服器是8核處理器，每核最大線程數256，所以我們線程池裡總共的最大線程總數數是8*256*4=8196），每個線程處理一個使用者的請求。

　　由於用戶端項目採取分布式部署，因此存在session共用的問題，我們網站的session共用沒有使用web容器內建的session共用機制，而是我們自己研發了一套session機制，原理很簡單，具體是我們會對每個使用者會話產生一個唯一標示，我們的唯一標示是這麼設計：目前使用者的session的id值+隨機16位元字和字母組合+當前的納秒值，然後將該值雜湊算出一個key，原有儲存在session裡的值儲存在memcache叢集裡，這些資料的key就是我們算出的使用者唯一標示。最終我們網站前端不在使用session對象，而是我們自己設計的session機制，對此我們還封裝了一套自訂標籤，在頁面上操作我們自訂的session。

　　服務端也有類似的共用機制，但是有所不同，當用戶端請求服務端時候，請求會具體落到服務端的某一台伺服器，因為本網站有些請求處理時非同步，也就是說客戶某些請求不是立即返回給使用者，而是現將請求分發給服務端，此時用戶端會返回使用者一個相應標示，說明該請求已經被受理，正在處理中，而服務端的某個線程此時已經開始處理了該請求，用戶端按一定時間間隔發送請求給服務端，問詢請求是否處理完成，但是服務端也是分布式，請求時隨機發送，用戶端的問詢可能會分發到別的伺服器，因此這樣的請求，我會在用戶端記錄下處理的服務端ip地址和線程id，在問詢的時候就會訪問指定好的伺服器和線程，直到請求處理完畢，最後關閉詢問，將結果返回給使用者。

　　由於我們把一個網站項目拆分成了三個獨立項目，因此在專案管理和協調上增加了難度，所以我們引入maven架構對工程進行了管理和構建，同時構建一個common工程，專門負責服務端和前端公用程式的開發。

　　本架構將展示層和業務處理層徹底分開，因此用戶端工程師可以專心做用戶端，服務端工程師專心做服務端，大家只要學習如何封裝通訊協議就行，因此很利於項目組人員的橫向擴充。

　　以上就是本人為公司網站設計的技術架構，這裡和大夥分享下，不知道好不好，希望各位大牛能給點建設性的意見。

　　互連網的網站和大部分企業管理軟體一樣都是使用B/S架構模型，但是大型的公用網站B/S架構會更加複雜，對架構人員的要求更高，今天我想在自己部落格裡聊聊我設計的網站的B/S技術架構。

　　不管是B/S架構的企業管理系統還是網站技術架構可以抽象為如下簡圖：

　　在傳統B/S架構的企業管理系統裡，技術架構往往就是一個工程項目，各個邏輯分層都是該工程的商務邏輯模組。但是作為提供公用服務的網站，由於使用者群比較龐大，網站並發量高，需求變化大，變更頻繁以及網站出於對安全的考慮，以上的邏輯分層在技術架構上的實現也就會複雜的多。本人前不久做一個網站，我設計的技術架構簡圖如下：

 

　　我把網站項目拆分為三個子項目：前端項目、服務端項目和memcache項目，前端項目包含頁面、靜態資源和控制層；服務端項目包含業務層和資料庫操作層；memcache項目緩衝前端項目和服務端項目公用的資料。

　　在系統部署上，前端項目和服務端項目都採用分布式方式（我們的網站前端是4台伺服器，服務端是4台伺服器），使用者請求進入前先通過負載平衡裝置進行請求分發，前端和服務端之間以及服務端和資料庫之間有防火牆保證系統的安全性，前端的叢集和服務端叢集分屬到不同網路環境裡，前端叢集可以訪問外網，服務端叢集和資料庫所在網路不能直接存取外網，但是前端網路環境和服務端網路環境之間可以進行通訊。

　　服務端和用戶端用我們自訂的報文進行通訊，傳輸協議時http，由於本人所在的網站安全性要求比較高，使用者傳輸的請求協議使用https。

　　為了保證服務端和用戶端通訊的效率，用戶端和服務端通訊我們使用長串連（我們網站服務端語言選擇的是java，通訊層使用netty架構開發的），為了保證長串連，我們寫了一個心跳檢測服務，該服務在後台線程裡運行，每個5分鐘檢測一次心跳，當然檢測的間隔時間是可以配置的。此外，我們事先估計過網站的最大並發量，在網站啟動時候，我們構建了一個線程池（我們使用的伺服器是8核處理器，每核最大線程數256，所以我們線程池裡總共的最大線程總數數是8*256*4=8196），每個線程處理一個使用者的請求。

　　由於用戶端項目採取分布式部署，因此存在session共用的問題，我們網站的session共用沒有使用web容器內建的session共用機制，而是我們自己研發了一套session機制，原理很簡單，具體是我們會對每個使用者會話產生一個唯一標示，我們的唯一標示是這麼設計：目前使用者的session的id值+隨機16位元字和字母組合+當前的納秒值，然後將該值雜湊算出一個key，原有儲存在session裡的值儲存在memcache叢集裡，這些資料的key就是我們算出的使用者唯一標示。最終我們網站前端不在使用session對象，而是我們自己設計的session機制，對此我們還封裝了一套自訂標籤，在頁面上操作我們自訂的session。

　　服務端也有類似的共用機制，但是有所不同，當用戶端請求服務端時候，請求會具體落到服務端的某一台伺服器，因為本網站有些請求處理時非同步，也就是說客戶某些請求不是立即返回給使用者，而是現將請求分發給服務端，此時用戶端會返回使用者一個相應標示，說明該請求已經被受理，正在處理中，而服務端的某個線程此時已經開始處理了該請求，用戶端按一定時間間隔發送請求給服務端，問詢請求是否處理完成，但是服務端也是分布式，請求時隨機發送，用戶端的問詢可能會分發到別的伺服器，因此這樣的請求，我會在用戶端記錄下處理的服務端ip地址和線程id，在問詢的時候就會訪問指定好的伺服器和線程，直到請求處理完畢，最後關閉詢問，將結果返回給使用者。

　　由於我們把一個網站項目拆分成了三個獨立項目，因此在專案管理和協調上增加了難度，所以我們引入maven架構對工程進行了管理和構建，同時構建一個common工程，專門負責服務端和前端公用程式的開發。

　　本架構將展示層和業務處理層徹底分開，因此用戶端工程師可以專心做用戶端，服務端工程師專心做服務端，大家只要學習如何封裝通訊協議就行，因此很利於項目組人員的橫向擴充。

　　以上就是本人為公司網站設計的技術架構，這裡和大夥分享下，不知道好不好，希望各位大牛能給點建設性的意見。