設計的一個網站的分佈式架構

互聯網的網站和大部分企業管理軟件同樣都是使用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工程，專門負責服務端和前端公共程序的開發。

　　本框架將展現層和業務處理層完全分開，所以客戶端工程師能夠專心作客戶端，服務端工程師專心作服務端，你們只要學習如何封裝通信協議就行，所以很利於項目組人員的橫向擴展。