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

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

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

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

我們先來提一下集群式服務器開發的常用幾個技術知識。

1：線程                    

2：線程池

3：內存池

4：數據庫連接池

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

[圖一：標準集群GameServer架構方案]

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

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

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

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

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

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

       1：如何劃分系統中功能？

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

       3：如何保證當系統的瓶頸凸顯時候，簡單的添加一組服務器，就可以達到分壓目的？

       4：系統的災難部分出現的時候，如何保證系統依然可以完整運行？

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

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

第三個問題還體現在分組方面。比如當Conn Server出現壓力的時候，如何簡單的添加一個Conn Server就達到分壓目的。當Logic Server出現壓力，或者DB Server出現壓力。另外就是如果服務器設計以組的方式出現，應該如何管理組以達到分壓目的。

第四個問題是災難恢復。在重要的系統中，由于涉及到的系統、硬件、軟件非常多，很容易某個系統出現故障，這個時候，系統應該具有很好的伸縮性，故障出現后，系統必須依然運行順利。

       所以在設計服務器時候，應該考慮上面的因素。下面我提出在集群服務器開發中的兩種可行的方案。

[圖二：基于功能劃分的集群GameServer架構]

[圖三：組劃分的集群服務器架構]

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

class THallServer 

{

public:

       THallServer();

       virtual ~THallServer();

       THallServer(int port);

public:

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

       int _maxConn; //該HallServer的最大連接數量

       int _currentConn; //當前連接數量

       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);

};

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

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

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

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

[圖四：改進的功能劃分集群GameServer架構二]

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

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

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

                                                                                           胡章優 2008-12-3 于北京

作者：胡章優，吉林大學機械學院教師。長春優狐科技開發有限公司董事長兼總經理。

Tel: 13596199043

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

Site: http://doserver.net

MSN:huzhangyou2002@gmail.com

QQ: 3803308