当我们将基于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的任何问题，欢迎联系我们：
电话：027-87638960
Q Q：372841921
