當我們將基于ESPlus/ESFramework開發的應用程序的服務端部署在一臺服務器上時，就可以稱這臺服務器為應用服務器（AS）。當在線用戶數量不斷增加時，我們可能需要部署數臺或更多的AS來分擔負載。但是，如果沒有ESPlatform統一管理，這些AS中的任何一個都是獨立的孤島，不能與其它的AS進行協作。對于某些特殊的應用來說，也許是可以的。但是，對于大多數需要群集的應用來說，必須要將眾多的AS管理起來，并能協調它們的工作。

特別是那些任意兩個客戶端（這兩個客戶端可能連接上了不同的AS）之間需要相互通信的應用，使用ESFramework的 P2P技術 可以解決一些問題，但是并不是所有的P2P通道都可以創建成功。 使用ESPlatform后，所有的在線用戶就像連接在同一個AS上一樣，服務端實例對于客戶端而言，是透明的。

一.群集基礎模型

在單個AS應用中，我們的關注焦點在于服務端和客戶端。而在多AS的群集應用中，我們需要增加一個核心關注點，那就是平臺層。ESPlatform群集模型可以劃分為三層：平臺層、應用層（即AS位于的層）、客戶端。如下圖所示的是ESPlatform所支持的最簡單的群集模型：

平臺層的核心是ACMS（應用群集管理服務器），用于管理ESPlatform群集中的所有應用服務器。ACMS的主要職責可概括為：

（1）管理所有的在線AS。

（2）負責AS群集分配策略。

（3）管理所有的在線用戶及其P2P地址。

（4）踢人功能。通過ACMS可以將任何一個在線用戶踢出系統。

（5）在AS之間轉發消息。

ESPlatform提供了可直接部署運行的ACMS服務器，我們將在后面的文章中詳細介紹它。

現在，我們以上圖為例，兩個客戶端Client01與Client02分別連上不同的應用服務器AS01和AS02，我們假設由于路由器的原因（比如兩個路由器的NAT類型都是Symmetric），Client01與Client02之間的P2P通道沒有建立成功。此時，如果Client01與Client02之間要相互溝通信息，那么信息就會經過ACMS中轉。比如Client01要發信息給Client02，信息經過的路線將會是：Client01 => AS01 => ACMS => AS02 => Client02。

在ESPlatform群集模型中，從Client01到Client02信息有三種可能的路徑：

（1）當Client01到Client02之間存在P2P通道時，直接經由P2P通道到達。否則，進入（2）。

（2）當Client01到Client02之間連接的是同一個AS時，直接由該AS轉發。否則，進入（3）。

（3）經由ACMS轉發。

對于Client01而言，信息到底是經3條路徑中的哪一條到達Client02的，它并不需要關心， ESPlatform保證了這一點，而且對客戶端是透明的。

二.全局的好友管理和組管理

對于那些需要好友關系或組關系的應用來說，在單AS應用中，通常直接在服務端進程中實例化IFriendsManager的實現類和IGroupManager的實現類就可以了。但是，在ESPlatform群集中，由于每個AS都會用到IFriendsManager和IGroupManager，所以，最好有一個全局的好友管理和組管理。

我們可以這樣做，將IFriendsManager的實現類單獨部署在一臺服務器上，稱之為好友服務器FriendServer；將IGroupManager的實現類單獨部署在一臺服務器上，稱之為組服務器GroupServer。FriendServer和GroupServer都通過Remoting的方式暴露出對應的服務。所以，各個AS就是通過Remoting來訪問IFriendsManager和IGroupManager。很明顯，全局的FriendServer和GroupServer應該位于平臺層。

在部署好FriendServer和GroupServer后，只需要在初始化AS的服務端引擎時，將IFriendsManager和IGroupManager的Remoting引用注入到引擎對應的屬性，接下來AS就會自動訪問FriendServer和GroupServer暴露的服務了。

當然，這只是最簡單的情況，實際上，在真正應用時，仍然要考慮到一個非常重要的方面：性能。AS可能會頻繁訪問FriendServer和GroupServer暴露的服務，所以，非常有必要認真考慮：

（1）是否需要在FriendServer和GroupServer的內存中緩存好友/組關系信息以避免每次都從外部加載。

（2）是否需要在AS的內存中也緩存好友/組關系信息以避免每次都Remoting訪問FriendServer和GroupServer。

也許還有其它的方式，但是這點必需根據您的業務需求慎重考慮。

三.策略與原則

一般而言，群集系統都是相當復雜的系統，為了處理復雜性，原則是必需要遵守的，除非你有充分的理由，并能更好地解決問題。在使用ESPlatform群集平臺時，我們要充分重視以下幾點。

1.保證AS與ACMS之間網絡暢通

AS在任何時候都有可能訪問ACMS，比如用戶上下線的時候，AS需要向ACMS報告；有些客戶端之間的信息必需經過ACMS進行中轉，等等。如果AS與ACMS之間的網絡中斷，哪怕只是片刻，可能都會導致AS與ACMS之間的狀態數據不一致。

我們通常將AS與ACMS部署在同一個機房的同一個局域網內，以保證通信的質量和速度。

2.盡可能使需要相互溝通的客戶端連上同一個AS

一個新啟動的客戶端應該連接到哪個AS服務器，是由我們的AS分配策略來決定的。所以，為了盡可能地減少經ACMS轉發的消息數量，也就是盡可能地降低ACMS的負載，在設計AS的分配策略時，應特別注意盡可能地使那些需要相互溝通的客戶端連接到同一個AS服務個器上。這樣，即使兩個客戶端之間的P2P通道沒有打通，那么，他們之間的交互信息只要通過AS中轉就可以了，不需要麻煩到ACMS。

3.可能需要部署專門的轉發服務器TS

即使上面一點做得再好，仍然會有需要經ACMS轉發信息的情況存在。如果轉發的是低頻信息（比如IM系統中的文字聊天信息），關系不是很大。但是如果需轉發的是高頻信息（如視頻音頻數據），那么就不適合經ACMS中轉了。因為轉發高頻信息，會大大增加ACMS的負載，從而影響整個群集系統的性能。這個時候該怎么辦了？我們的經驗是：動態連接轉發服務器TS。

當無法成功創建P2P通道而且又不在同一個AS上的兩個客戶端Client01與Client02需要高頻通信之前，根據某種策略，選擇一個合適的轉發服務器TS，Client01與Client02都連接到這個TS，然后后續的高頻信息（甚至是所有要轉發的信息）都經過該TS中轉。顯而易見，在ESPlatform的層次模型中，TS也位于應用層。

（1）我們可以將TS看成是一種特殊類型的AS，它不參與任何具體的業務邏輯處理，只是簡單地轉發信息。

（2）根據需要，我們可以部署很多個TS，而且TS并不需要部署在ACMS/AS的同一個機房內。相反的，TS可能是部署在全國各地的。需要高頻通信的Client01與Client02選擇TS最簡單的策略是，看兩個客戶端到哪個TS的路由之和最短。

4.熱機備份ACMS

在群集模型中，很容易看到ACMS是整個群集系統的“單點”，只要ACMS掛掉，整個群集系統就無法正常工作了。所以，在部署ACMS時，最好使用雙熱機備份或多熱機備份，這樣在主ACMS意外當機后，另一臺備份機就立馬可以接手工作。

四.小結

ESPlatform提供了最基礎的群集模型（本文的第一個模型圖），而后續的進化模型都是在這個基礎上根據可能的需求所進行的常規變化。而且，這些變化可以依據更多的需求假設來進一步深化。比如，我們可以引入TCMS（轉發群集管理服務器）來管理所有的轉發服務器TS。再比如，在需要高頻廣播信息的系統中，我們還可以引入類似TS作用的廣播服務器BS來轉發所有的廣播信息，并引入BCMS（廣播群集管理服務器）來管理所有的BS。

但無論怎么變化，其基礎仍然是我們第一個模型圖所示的基礎模型，它是ESPlatform的核心模型。對于某些業務簡單的系統，最簡單的模型可能就已經足夠了。對于那些復雜的系統，在這個核心模型上要如何變化、如何深化，沒有固定的方向可言，其最終取決于我們系統的需求。正如有句話是這樣說的：憑空想象的模型是沒有用的，必須要與實際的需求結合起來，并在實戰中不斷淬煉。

下篇文章，我們將詳細介紹群集管理服務器ACMS，感謝關注。

閱讀 更多ESFramework開發手冊系列文章 。

-----------------------------------------------------------------------------------------------------------------------------------------------

關于ESFramework的任何問題，歡迎聯系我們：

電話：027-87638960

Q Q：372841921

ESPlatform 群集平臺（00） －－ 概念與模型