大型門戶網站架構服務部署研究說明

筆者經常被朋友問起，該如何設計一個大型的門戶網站架構。目前中小型網站，由於資料量相對來說比較少，特別是普通的企業網站，幾乎沒有什麼人訪問，因此，大部分都是單機版的服務架構，即：前台頁面程式、後台服務程式、資料庫都放在同一台伺服器上。頂多也就是把資料庫放到同區域網路的另一台伺服器而已。這是目前絕大部分網站的部署方法。 
這樣的部署，給後期帶來的問題是很多的。當服務程式死掉，那麼整個網站就無法訪問了。前台web程式的壓力和後台服務程式的壓力同在一台伺服器上。很容易造成cpu、記憶體過於繁忙而導致運行效率低下。如果有上萬人訪問，這樣的架構跑起來真是有些力不從心了。 
雖然很多程式語言都已經提供了分布式業務處理的類，而且功能也非常的強大。但是操作起來過於複雜，很多個人化的需求都不能得到高效率的解決。很多功能使用起來也過於牽強。安全性問題由於其介面的透明性而變得比較脆弱（當然高手另當別論了）。 
現在把我參與攜購網（http://www.xiegoo.com）這個系統的開發來詳細講解下其部署。目前都流行把網站頁面、服務程式、資料完全獨立開來，這樣的好處就不再累贅的講述了。攜購網的結構層我們可以分為以下幾個部分： 
1.頁面展示層 
2.前台資料處理層 
3.前台協議處理層 
4.前台資料轉送層 

5．後台資料轉送層 
6. 後台協議處理層 
7. 後台資料處理層 
8. 後台資料緩衝層 
9. 資料庫 
上面從宏觀上可以看到，主要分成前台、後台。前台需要資料的時候，向後台發起操作協議。資料的傳輸是通過SOCKET 連結來完成的。關鍵的問題就是前台後台之間的協議。只有通過先前大家約定好的協議，後台才能知道前台需要的是什麼樣的操作。協議是前台與後台服務程式互動的基礎。 
協議可以有多種格式來定義：典型的有資料流格式、XML格式等。 
資料流格式：如中國聯通簡訊網關介面協議SGIP，就是約定好長度。比如前8個位元組表示的資料的長度，緊跟著的10個位元組表示企業的ID號等。 
資料流格式的好處是，傳輸的資料少。冗餘資料可以最小。缺點是：因為資料流的可讀性非常差，所有一旦運行中出現錯誤時要找到問題的所在比較麻煩些。另外，由於各種程式設計語言在變數定義上存在差別，所以，如果使用結構體或者實體類的資料流的傳送方法，可移植性也比較差。這種方法一般用於速度要求非常高的系統下，如果遊戲系統等。 

　　XML格式協議，這裡我們特彆強調這種協議格式，攜購網使用的就是XML格式協議的傳送。相對於資料流格式的傳送，這種方法有很多的優點。雖然在傳送的過程中增加了比較多的冗餘資料，但是XML的可讀性非常高，可擴張性也非常高。前景程式和背景程式可以使用完全不同的程式語言。只要該程式語言支援XML的讀寫，就可以與後台服務程式進行互動。因此，XML格式的協議通用性非常好。如果系統對速度要求不是非常苛刻的，建議使用該格式協議。具體的架構如下：

  

圖一 架構部署 

注意： 
黃底色的地區做為一個整體不可分割，必須放在同一台伺服器上，其他的就可以任意的放。建議放在同一段IP的區域網路內，這樣訪問的速度可以更快。 
當一個使用者訪問頁面的時候，整個流程是這樣走的：

1. 當使用者訪問某個頁面（我們假設這個頁面不是已經產生好的靜態頁面，即：該頁面需要訪問資料庫操作）。
2. 頁面展示層將調用本地“前台業務處理常式”，告知需要具體什麼樣的操作。
3. 前台業務處理常式將使用者的需求分解成對應的資料實體操作。同時將其交給協議解析層。
4. 這裡的協議解析層不僅僅是一個解析的過程，當該層得知需要從伺服器擷取資料時，它會將“業務處理層”的操作請求，轉換成後台可以認識的XML格式協議。如果XML資料需要加密處理，那麼在該層就將其加密處理。同時將其轉交給“資料傳送層”。
5. 資料轉送層接收到需要傳送資料的命令後，它會從SOCKET連結緩衝池裡找到當前閒置連結，進行與伺服器之間的對接。這個過程中，資料轉送層判斷如果有多個後台服務程式可以供選擇的時候，它會根據繁忙程度，找到最為空白閑的一個服務進行傳輸。也就是說，資料轉送層，先找到要傳輸的伺服器位址。然後再找到與之對應的SOCKET連結緩衝池裡找最空的連結。
6. 後台服務程式的“資料傳送層”接收到前台發來的資料後，將其轉交給協議解析層。
7. “後台協議解析層”判斷如果資料經過了加密處理，那麼先對其進行解密處理，同時，將接收到的資料解析、轉換後，提交給對應的後台業務處理常式，進行處理。比如說查詢使用者資料，那麼就直接會定位到業務處理常式的使用者查詢的操作入口。
8. 後台業務處理常式調用資料緩衝。如果要查詢的資料在緩衝裡已經存在，那麼直接從緩衝裡返回需要的資料。如果沒有則需要從資料庫裡尋找。

　　以上是從前台調用到背景整個單向流程。當需要的資料，或者需要的操作已經完成時，程式到這裡並不是停止了。後台需要將查詢到或者操作後的結構返回給前台。那麼需要返回操作。直到前台展示頁面把最終的資料展示給客戶為止。 
看上去整個流程非常複雜，有很多朋友會問如果這樣的架構速度上怎麼樣？那麼你可以去訪問下攜購網（http://www.xiegoo.com）試試看，總整理來說，攜購網的速度已經是比較理想的了。 
這樣的架構如果單從小訪問量來看，是看不出該構架的優點，因為目前傳統的做法是直接存取資料庫，在訪問速度上看，還是相當可以的，但是如果有幾萬，幾十萬使用者訪問的時候，那怎麼辦呢？直接存取資料庫，或者是單機版的架構我看只能是老牛推破車了呵呵。 
接下來，我們來分析下當訪問量非常大的時候，該架構如果應對？大家可以看到頁面展示層，只接受使用者的訪問請求，所以無論從SOCKET串連壓力，還是業務處理壓力都是非常小的。因此，我們在這裡暫時不考慮該層的減壓方案。 
壓力最大的部分就是業務處理部分和資料庫部分。因為我們的架構是分散式處理的，所以當你的程式寫的不是非常好的情況下（當然不能直接影響到資料庫的死結等等），只要不斷的增加伺服器，就可以解決不斷增加的使用者訪問量。資料庫部分的最佳化，我相信很多朋友比我更加熟悉，有太多的資料庫最佳化方案，大家可以去網上找找。 
如果你的使用者訪問量真的非常大，那麼軟、硬體一起來吧，加上均衡處理機，再加上我們這套架構，相信已經能滿足你的需求了。 
很多朋友會說，前面講的那麼理論化，聽的雲裡霧裡，能不能講點具體的，那下面我主要講解下最關鍵的XML協議部分吧： 
前台用戶端：

<? XML version=”1.0” encoding=”UTF-8”?><params><busi> user.center</busi><oper> user.query</oper><queryType>id </queryType><queryCondition>106</queryCondition><sort><key/>根據某個關鍵字排序<direction/> 升序還是降序desc or asc</sort><queryState>   //分頁參數<pageCnt></pageCnt> //每頁顯示的記錄條數<pageNum></pageNum>  //當前的頁碼</queryState></params>

幕後處理完畢後，返回結構協議：

<? XML version=”1.0”  encoding=”UTF-8”?><result><success/><msg/><queryState><pageCnt/><pageNum/><totalRec/>   //總共查詢到的記錄數<curPageCnt/> //當前頁碼上的記錄數<totalPage/>  //總共分幾頁</queryState><itemList><item><id><name/></item>……</itemList></result>

上面兩個協議的操作是：查詢ID=106的使用者的資訊。 
當然，我們的協議不希望明文給人家SOCKET擷取後破解，那麼你可以對你的XML資料加密吧。具體的加密方法到網上找找，太多了。但是不要用無法復原的加密方法，否則請求發過去，後台服務程式要發火了。 
XML協議可以做很多事情，並不僅局限於發送文本命令，類似於檔案上傳，下載，等等你都可以通過XML協議的命令來完成。攜購獨立網店系統（http://www.shopxg.com）上的所有上傳，下載就是這樣，全部是通過自己的協議格式完成的。 

好了，講了這麼多不知道大家有沒有理解，再認認真真，仔仔細細的看幾遍架構圖，相信你會明白起來的，另外大家也可以思考下，這樣的部署，如何解決南北互連的問題？

轉載至： http://www.qqgb.com/Program/VC/VCZH/Program_254800.html