<P>作者：吳康彬</P>
<P>&nbsp;&nbsp;&nbsp; 筆者經常被朋友問起，該如何設計一個大型的門戶網站架構。目前中小型網站，由于數據量相對來說比較少，特別是普通的企業網站，幾乎沒有什么人訪問，因此，大部分都是單機版的服務架構，即：前臺頁面程序、后臺服務程序、數據庫都放在同一臺服務器上。頂多也就是把數據庫放到同局域網的另一臺服務器而已。這是目前絕大部分網站的部署方法。 <BR>&nbsp;&nbsp;&nbsp; 這樣的部署，給后期帶來的問題是很多的。當服務程序死掉，那么整個網站就無法訪問了。前臺web程序的壓力和后臺服務程序的壓力同在一臺服務器上。很容易造成cpu、內存過于繁忙而導致運行效率低下。如果有上萬人訪問，這樣的架構跑起來真是有些力不從心了。 <BR>&nbsp;&nbsp;&nbsp; 雖然很多程序語言都已經提供了分布式業務處理的類，而且功能也非常的強大。但是操作起來過于復雜，很多個性化的需求都不能得到高效率的解決。很多功能使用起來也過于牽強。安全性問題由于其接口的透明性而變得比較脆弱（當然高手另當別論了）。 <BR>&nbsp;&nbsp;&nbsp; 現在把我參與攜購網（<A href=">）這個系統的開發來詳細講解下其部署。目前都流行把網站頁面、服務程序、數據完全獨立開來，這樣的好處就不再累贅的講述了。攜購網的結構層我們可以分為以下幾個部分： <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. 頁面展示層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. 前臺數據處理層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. 前臺協議處理層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. 前臺數據傳輸層 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5．后臺數據傳輸層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6. 后臺協議處理層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7. 后臺數據處理層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8. 后臺數據緩存層 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9. 數據庫 <BR>&nbsp;&nbsp;&nbsp; 上面從宏觀上可以看到，主要分成前臺、后臺。前臺需要數據的時候，向后臺發起操作協議。數據的傳輸是通過SOCKET 鏈接來完成的。關鍵的問題就是前臺后臺之間的協議。只有通過先前大家約定好的協議，后臺才能知道前臺需要的是什么樣的操作。協議是前臺與后臺服務程序交互的基礎。 <BR>&nbsp;&nbsp;&nbsp; 協議可以有多種格式來定義：典型的有數據流格式、xml格式等。 <BR>&nbsp;&nbsp;&nbsp; 數據流格式：如中國聯通短信網關接口協議SGip，就是約定好長度。比如前8個字節表示的數據的長度，緊跟著的10個字節表示企業的ID號等。 <BR>&nbsp;&nbsp;&nbsp; 數據流格式的好處是，傳輸的數據少。冗余數據可以最小。缺點是：因為數據流的可讀性非常差，所有一旦運行中出現錯誤時要找到問題的所在比較麻煩些。另外，由于各種編程語言在變量定義上存在差別，所以，如果使用結構體或者實體類的數據流的傳送方法，可移植性也比較差。這種方法一般用于速度要求非常高的系統下，如果游戲系統等。 <BR>&nbsp;&nbsp;&nbsp; XML格式協議，這里我們特別強調這種協議格式，攜購網使用的就是XML格式協議的傳送。相對于數據流格式的傳送，這種方法有很多的優點。雖然在傳送的過程中增加了比較多的冗余數據，但是XML的可讀性非常高，可擴張性也非常高。前臺程序和后臺程序可以使用完全不同的程序語言。只要該程序語言支持XML的讀寫，就可以與后臺服務程序進行交互。因此，XML格式的協議通用性非常好。如果系統對速度要求不是非?？量痰?，建議使用該格式協議。 <BR>&nbsp;&nbsp;&nbsp; 具體的架構示意圖如下：</P>
<P><IMG height=780 src="http://http"http://s1.VeVb.com/20081221/liucheng.gif">&nbsp;<BR>圖一 架構部署示意圖 <BR>&nbsp;&nbsp;&nbsp; 注意： <BR>&nbsp;&nbsp;&nbsp; 黃底色的區域做為一個整體不可分割，必須放在同一臺服務器上，其他的就可以任意的放。建議放在同一段IP的局域網內，這樣訪問的速度可以更快。 <BR>&nbsp;&nbsp;&nbsp; 當一個用戶訪問頁面的時候，整個流程是這樣走的： <BR>&nbsp;&nbsp;&nbsp; 1. 當用戶訪問某個頁面（我們假設這個頁面不是已經生成好的靜態頁面，即：該頁面需要訪問數據庫操作）。 <BR>&nbsp;&nbsp;&nbsp; 2. 頁面展示層將調用本地“前臺業務處理程序”，告知需要具體什么樣的操作。 <BR>&nbsp;&nbsp;&nbsp; 3. 前臺業務處理程序將用戶的需求分解成對應的數據實體操作。同時將其交給協議解析層。 <BR>&nbsp;&nbsp;&nbsp; 4. 這里的協議解析層不僅僅是一個解析的過程，當該層得知需要從服務器獲取數據時，它會將“業務處理層”的操作請求，轉換成后臺可以認識的XML格式協議。如果XML數據需要加密處理，那么在該層就將其加密處理。同時將其轉交給“數據傳送層”。 <BR>&nbsp;&nbsp;&nbsp; 5. 數據傳輸層接收到需要傳送數據的命令后，它會從SOCKET鏈接緩存池里找到當前空閑的鏈接，進行與服務器之間的對接。這個過程中，數據傳輸層判斷如果有多個后臺服務程序可以供選擇的時候，它會根據繁忙程度，找到最為空閑的一個服務進行傳輸。也就是說，數據傳輸層，先找到要傳輸的服務器地址。然后再找到與之對應的SOCKET鏈接緩存池里找最空的鏈接。 <BR>&nbsp;&nbsp;&nbsp; 6. 后臺服務程序的“數據傳送層”接收到前臺發來的數據后，將其轉交給協議解析層。 <BR>&nbsp;&nbsp;&nbsp; 7. “后臺協議解析層”判斷如果數據經過了加密處理，那么先對其進行解密處理，同時，將接收到的數據解析、轉換后，提交給對應的后臺業務處理程序，進行處理。比如說查詢用戶數據，那么就直接會定位到業務處理程序的用戶查詢的操作入口。 <BR>&nbsp;&nbsp;&nbsp; 8. 后臺業務處理程序調用數據緩存。如果要查詢的數據在緩存里已經存在，那么直接從緩存里返回需要的數據。如果沒有則需要從數據庫里查找。 <BR>&nbsp;&nbsp;&nbsp; 以上是從前臺調用到后臺的整個單向流程。當需要的數據，或者需要的操作已經完成時，程序到這里并不是停止了。后臺需要將查詢到或者操作后的結構返回給前臺。那么需要返回操作。直到前臺展示頁面把最終的數據展示給客戶為止。 <BR>&nbsp;&nbsp;&nbsp; 看上去整個流程非常復雜，有很多朋友會問如果這樣的架構速度上怎么樣？那么你可以去訪問下攜購網（<A href=">）試試看，總整理來說，攜購網的速度已經是比較理想的了。 <BR>&nbsp;&nbsp;&nbsp; 這樣的架構如果單從小訪問量來看，是看不出該構架的優點，因為目前傳統的做法是直接訪問數據庫，在訪問速度上看，還是相當可以的，但是如果有幾萬，幾十萬用戶訪問的時候，那怎么辦呢？直接訪問數據庫，或者是單機版的架構我看只能是老牛推破車了呵呵。 <BR>&nbsp;&nbsp;&nbsp; 接下來，我們來分析下當訪問量非常大的時候，該架構如果應對？大家可以看到頁面展示層，只接受用戶的訪問請求，所以無論從SOCKET連接壓力，還是業務處理壓力都是非常小的。因此，我們在這里暫時不考慮該層的減壓方案。 <BR>&nbsp;&nbsp;&nbsp; 壓力最大的部分就是業務處理部分和數據庫部分。因為我們的架構是分布式處理的，所以當你的程序寫的不是非常好的情況下（當然不能直接影響到數據庫的死鎖等等），只要不斷的增加服務器，就可以解決不斷增加的用戶訪問量。數據庫部分的優化，我相信很多朋友比我更加熟悉，有太多的數據庫優化方案，大家可以去網上找找。 <BR>&nbsp;&nbsp;&nbsp; 如果你的用戶訪問量真的非常大，那么軟、硬件一起來吧，加上均衡處理機，再加上我們這套架構，相信已經能滿足你的需求了。 <BR>&nbsp;&nbsp;&nbsp; 很多朋友會說，前面講的那么理論化，聽的云里霧里，能不能講點具體的，那下面我主要講解下最關鍵的XML協議部分吧： <BR>&nbsp;&nbsp;&nbsp; 前臺客戶端： </P>
<P>&nbsp;<? XML version=”1.0” encoding=”UTF-8”?><BR>&nbsp;&nbsp;<PARAMS><BR>&nbsp;&nbsp;&nbsp;<BUSI> user.center</BUSI><BR>&nbsp;&nbsp;&nbsp;<OPER> user.query</OPER><BR>&nbsp;&nbsp;&nbsp;<QUERYTYPE>id </QUERYTYPE><BR>&nbsp;&nbsp;&nbsp;<QUERYCONDITION>106</QUERYCONDITION><BR>&nbsp;&nbsp;&nbsp;<SORT><BR>&nbsp;&nbsp;&nbsp;&nbsp;<KEY />根據某個關鍵字排序<BR>&nbsp;&nbsp;&nbsp;&nbsp;<DIRECTION /> 升序還是降序desc or asc<BR>&nbsp;&nbsp;&nbsp;</SORT> <BR>&nbsp;&nbsp;&nbsp;<QUERYSTATE>&nbsp;&nbsp; //分頁參數<BR>&nbsp;&nbsp;&nbsp;&nbsp;<PAGECNT></PAGECNT> //每頁顯示的記錄條數<BR>&nbsp;&nbsp;&nbsp;&nbsp;<PAGENUM></PAGENUM>&nbsp; //當前的頁碼<BR>&nbsp;&nbsp;&nbsp;</QUERYSTATE><BR>&nbsp;&nbsp;</PARAMS></P>
<P><BR>后臺處理完畢后，返回結構協議： <BR>&nbsp;<? XML version=”1.0”  encoding=”UTF-8”?><BR>&nbsp;&nbsp;<RESULT><BR>&nbsp;&nbsp;&nbsp;<SUCCESS /><BR>&nbsp;&nbsp;&nbsp;<MSG /><BR>&nbsp;&nbsp;&nbsp;<QUERYSTATE>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;<PAGECNT />&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp;<PAGENUM /><BR>&nbsp;&nbsp;&nbsp;&nbsp;<TOTALREC />&nbsp;&nbsp; //總共查詢到的記錄數<BR>&nbsp;&nbsp;&nbsp;&nbsp;<CURPAGECNT /> //當前頁碼上的記錄數<BR>&nbsp;&nbsp;&nbsp;&nbsp;<TOTALPAGE />&nbsp; //總共分幾頁<BR>&nbsp;&nbsp;&nbsp;</QUERYSTATE><BR>&nbsp;&nbsp;&nbsp;<ITEMLIST><BR>&nbsp;&nbsp;&nbsp;&nbsp;<ITEM><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<ID><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<NAME /><BR>&nbsp;&nbsp;&nbsp;&nbsp;</ITEM><BR>&nbsp;&nbsp;&nbsp;&nbsp;……<BR>&nbsp;&nbsp;&nbsp;</ITEMLIST><BR>&nbsp;&nbsp;</RESULT></P>
<P><BR>&nbsp;&nbsp;&nbsp; 上面兩個協議的操作是：查詢ID=106的用戶的信息。 <BR>&nbsp;&nbsp;&nbsp; 當然，我們的協議不希望明文給人家SOCKET獲取后破解，那么你可以對你的XML數據加密吧。具體的加密方法到網上找找，太多了。但是不要用不可逆的加密方法，否則請求發過去，后臺服務程序要發火了。 <BR>&nbsp;&nbsp;&nbsp; XML協議可以做很多事情，并不僅局限于發送文本命令，類似于文件上傳，下載，等等你都可以通過XML協議的命令來完成。攜購獨立網店系統（<A href=">）上的所有上傳，下載就是這樣，全部是通過自己的協議格式完成的。 <BR>&nbsp;&nbsp;&nbsp; 好了，講了這么多不知道大家有沒有理解，再認認真真，仔仔細細的看幾遍架構圖，相信你會明白起來的，另外大家也可以思考下，這樣的部署，如何解決南北互通的問題？</P>