自從2003年開發(fā)VOIP Radius Server以及修改Gnugk依賴，從事服務(wù)器開發(fā)已經(jīng)近五年了，對服務(wù)器開發(fā)也有一些自己獨到的看法以及見解。當(dāng)擺脫了技術(shù)本身的束縛之后，才理解重要的并不是某種技術(shù)的運用，而是整體設(shè)計的考慮，也慢慢明白了設(shè)計是開發(fā)的靈魂的道理。

從技術(shù)層面來看，各個平臺都有一些自己特有的東西，比如Windows 平臺下面的IOCP技術(shù)，可以說為了支持大的并發(fā)，IOCP是一個Windows平臺的必選方案。而在Linux下面Epoll又是所有開發(fā)人員需要掌握的技術(shù)。當(dāng)然還有FreeBSD下面Kqueue的應(yīng)用了。一些其他平臺也有自己獨有的AIO庫。

隨著網(wǎng)絡(luò)開發(fā)的進(jìn)一步理念加深，跨平臺庫也吸引了越來越多的使用者的眼光。比如行業(yè)里面最出名的莫過于ACE、ASIO(Boost公司)兩大支持庫。新的版本中都對IOCP支持，使用的是Proactor設(shè)計模式實現(xiàn)的。

當(dāng)我們擁有了以上的知識背景后，我們就可以開始著手設(shè)計了。而這僅僅是一個必要條件，而不是重復(fù)條件。為什么呢？

我們先來提一下集群式服務(wù)器開發(fā)的常用幾個技術(shù)知識。

1：線程                    

2：線程池

3：內(nèi)存池

4：數(shù)據(jù)庫連接池

5：為了達(dá)到1:10000的連接，可以采用Server-Client的連接方式，而為了達(dá)到1:10000*100的連接，我們怎么辦呢？一般會采用Client-> ConnServer -> LogicServer。這是技術(shù)背景。ConnServer在接受完Client 的連接后，將Logic Server 暴露給Client,并立刻斷開連接。以后的數(shù)據(jù)交互就和Conn Server沒有關(guān)系了，這種架構(gòu)有很多的優(yōu)勢。

[圖一：標(biāo)準(zhǔn)集群GameServer架構(gòu)方案]

首先要說的是線程，在服務(wù)器開發(fā)中，線程是一個非常重要的概念，尤其是現(xiàn)在多核服務(wù)器的發(fā)展。當(dāng)然，提到了線程自然應(yīng)該說到線程之間的互斥。這也是服務(wù)器開發(fā)者們在開發(fā)最初最容易出現(xiàn)的問題。體現(xiàn)在一個資源或者多個資源在多個線程中共享使用如何避免出現(xiàn)臟數(shù)據(jù)的問題。

       線程池，池，顧名思義，是一個存儲容器，一個淺顯的比方，我們把水事先存放在水池里面，當(dāng)我們需要的時候，就去里面取，用完了就還給池（其實這里并不是非常合適的例子，畢竟我們用完了水是丟掉）。這是一個由多個線程組成的一個隊列，當(dāng)有事情發(fā)生時候，我們把當(dāng)前的空閑的線程丟給他，為他服務(wù)。當(dāng)下一個事件發(fā)生的時候，我們又從池里面取一個空閑的線程丟給他，為他服務(wù)。當(dāng)服務(wù)完畢，把線程丟回池中。起到反復(fù)利用的目的。

       內(nèi)存池，同樣也是一個池。這個概念的產(chǎn)生是為了避免服務(wù)器頻繁的分配內(nèi)存，而采取預(yù)先分配一定數(shù)目的對象，并將對象們放到隊列中，當(dāng)需要的時候，從該隊列中取出，當(dāng)用完，就返回池中。比如我們的Server可能會存在10000個連接，我們預(yù)先開辟10000個Client對象，存儲在list<Client *> pFreeClientsList中，當(dāng)需要的時候，從隊列中pop一個出來，當(dāng)使用完畢就丟回pFreeClientsList。這種機制很好的起到了避免頻繁開辟內(nèi)存對象的目的，可以很好的提高系統(tǒng)的性能。

       數(shù)據(jù)庫連接池，同上面一致的道理，在服務(wù)器中，數(shù)據(jù)庫訪問也是一個很大的瓶頸，所以同樣采取上面的道理，使用連接池的概念。當(dāng)然在數(shù)據(jù)庫連接方面也有一個特殊的問題存在。就是數(shù)據(jù)庫的連接不宜過多，所以傳統(tǒng)的來一個處理，就開一個連接是不合理的，必須采用控制適當(dāng)?shù)倪B接次數(shù)。

       當(dāng)然另外一些需要提到的是內(nèi)存數(shù)據(jù)庫。硬盤的訪問速度和內(nèi)存的訪問速度不是一個數(shù)量級的，而且隨著內(nèi)存的硬件價格越來越低，內(nèi)存數(shù)據(jù)庫的可行性也越來越高，尤其是實時性要求高的系統(tǒng)，完全可以采用內(nèi)存數(shù)據(jù)庫和物理數(shù)據(jù)庫想結(jié)合的方法來處理。

       當(dāng)系統(tǒng)的連接數(shù)量從萬上百萬級別的時候，服務(wù)器程序就超越了服務(wù)器本身，我們需要考慮的問題將從一下幾個方面開展：

       1：如何劃分系統(tǒng)中功能？

       2：如何保證整個系統(tǒng)的性能可控，直觀的說就是系統(tǒng)每一步時候瓶頸在哪里？

       3：如何保證當(dāng)系統(tǒng)的瓶頸凸顯時候，簡單的添加一組服務(wù)器，就可以達(dá)到分壓目的？

       4：系統(tǒng)的災(zāi)難部分出現(xiàn)的時候，如何保證系統(tǒng)依然可以完整運行？

第一個問題是如何劃分系統(tǒng)中的功能。在軟件開發(fā)中，我們追求的是每個函數(shù)功能盡量簡單，易學(xué)里面的道理叫做大道至簡。軟件開發(fā)中同樣適用，在服務(wù)器開發(fā)中，同樣適用。如何將整個系統(tǒng)中的需求抽象為功能，并如何更好的劃分功能，將極大減少系統(tǒng)開發(fā)的難度，并能夠使得系統(tǒng)的可擴展性非常強。

第二個問題是瓶頸問題。從物理上面來分析，性能在硬盤，內(nèi)存，CPU是三個決定因素的地方。而從軟件的角度就包含了數(shù)據(jù)庫系統(tǒng)，操作系統(tǒng)，服務(wù)器軟件系統(tǒng)三個方面，更細(xì)節(jié)方面拿游戲服務(wù)器來說，Conn Server 的壓力，Logic Server的壓力，還是DB Server的壓力了。

第三個問題還體現(xiàn)在分組方面。比如當(dāng)Conn Server出現(xiàn)壓力的時候，如何簡單的添加一個Conn Server就達(dá)到分壓目的。當(dāng)Logic Server出現(xiàn)壓力，或者DB Server出現(xiàn)壓力。另外就是如果服務(wù)器設(shè)計以組的方式出現(xiàn)，應(yīng)該如何管理組以達(dá)到分壓目的。

第四個問題是災(zāi)難恢復(fù)。在重要的系統(tǒng)中，由于涉及到的系統(tǒng)、硬件、軟件非常多，很容易某個系統(tǒng)出現(xiàn)故障，這個時候，系統(tǒng)應(yīng)該具有很好的伸縮性，故障出現(xiàn)后，系統(tǒng)必須依然運行順利。

       所以在設(shè)計服務(wù)器時候，應(yīng)該考慮上面的因素。下面我提出在集群服務(wù)器開發(fā)中的兩種可行的方案。

[圖二：基于功能劃分的集群GameServer架構(gòu)]

[圖三：組劃分的集群服務(wù)器架構(gòu)]

在圖二中，系統(tǒng)按照功能方式劃分系統(tǒng)，當(dāng)壓力增加的時候，按照功能方式添加某服務(wù)器，可以簡單的達(dá)到分壓的目的。在Conn Server中保存所有有效Hall Server的連接，以及當(dāng)前該Hall Server的當(dāng)前連接數(shù)。代碼示意如下：

class THallServer 

{

public:

       THallServer();

       virtual ~THallServer();

       THallServer(int port);

public:

       SOCKET _hallServer; //保持同HallServer連接的Socket對象

       int _maxConn; //該HallServer的最大連接數(shù)量

       int _currentConn; //當(dāng)前連接數(shù)量

       int GetCurrentConn();

       char _hallServerAddr[32];

       int _hallServerPort;

};

class THallServerList 

{

public:

       THallServerList();

       virtual ~THallServerList();

public:

       list<THallServer *> pHallServerList;

       SOCKET _listenHallServer;

       HANDLE ListenThread;

public:

       void Start();

       THallServerList(int port);

       //Accept線程

       static unsigned __stdcall ListenThreadFunc(LPVOID lpVoid);

};

上面的代碼是該設(shè)計方案的類代碼。從代碼中我們可以理解出思想如下：

       Conn Server里面存在一個THallServerList對象，該對象監(jiān)聽端口，當(dāng)有HallServer連接過來，將該HallServer存入隊列，并實時獲取該Server當(dāng)前的壓力情況，可以起到一個負(fù)載均衡的作用。而保持的HallServer隊列，當(dāng)客戶端連接過來，Conn Server則從pHallServerList中將當(dāng)前currentConn最小的服務(wù)器發(fā)送給客戶端，以后客戶端將同該Hall Server發(fā)起連接。

       在該系統(tǒng)中，當(dāng)我們的Conn Server不夠的時候，可以考慮架設(shè)多臺Conn Server，當(dāng)客戶端無法連接時候，程序自動連接下一臺Conn Server.比如conn1.doserver.net、conn2.doserver.net、conn3.doserver.net、connn.doserver.net。

       圖三中是按照組劃分的系統(tǒng)組成。該方案目前來說，我還并沒有實施過，只是在方案上面進(jìn)行過探討。希望有時間我可以設(shè)計一個案例出來再做展示。

[圖四：改進(jìn)的功能劃分集群GameServer架構(gòu)二]

在項目的實施過程中，我發(fā)現(xiàn)了Hall Server其實并不需要同Logic Server進(jìn)行交互，如果Hall Server在保留同Client的1W多連接的情況下依然保持過多的同Logic Server的連接，勢必壓力非常大，這時候如果在之間使用ISServer來交互，就可以減少很多的連接數(shù)量，也使得系統(tǒng)更加清晰。

       Hall Server只需要獲取所有的Logic Server的名稱，Logic Server的地址，Logic Server的端口，以及當(dāng)前的連接數(shù)量。所以通過之間的一個信息服務(wù)器作為橋梁，就可以很好的解決這個問題。這種架構(gòu)就可以達(dá)到非常完美的解決上面提到的4個難點的問題了。

后記：封閉開發(fā)之余，很想把自己的在服務(wù)器開發(fā)的經(jīng)驗分享一下，所以就借用了2個小時整理此小文，希望大家喜歡。同時歡迎大家指點，建議。也歡迎轉(zhuǎn)載，但是無比保留版權(quán)以及原作者信息。非常感謝。

                                                                                           胡章優(yōu) 2008-12-3 于北京

作者：胡章優(yōu)，吉林大學(xué)機械學(xué)院教師。長春優(yōu)狐科技開發(fā)有限公司董事長兼總經(jīng)理。

Tel: 13596199043

Mail: huzhangyou2002@gmail.com (huzhangyou@jlu.edu.cn)

Site: http://doserver.net

MSN:huzhangyou2002@gmail.com

QQ: 3803308