ESPlatform 群集平台（00） －－ 概念与模型
当我们将基于ESPlus/ESFramework开发的应用程序的服务端部署在一台服务器上时，就可以称这台服务器为应用服务器（AS）。在下列两种情况下，就可以考虑是否需要迁移到群集平台。
（1）当在线用户数量不断增加时，我们可能需要部署数台或更多的AS来分担负载。
（2）当用户分散在全国各地甚至全球时，要保证这些用户的到同一台AS的网络质量都很良好，几乎是不可能的。
在应用规模不断增大时，通常（1）与（2）两种情况会同时出现 。这样，我们可以选择在一些重要的城市部署AS节点，如此，客户端登在录时就可以选择对自己而言相对最优的AS节点登录。
但是了，如果没有ESPlatform统一管理，这些AS中的任何一个都是独立的孤岛，不能与其它的AS进行协作。对于某些特殊的应用来说，也许是可以的。但是，对于大多数需要群集的应用来说，必须要将众多的AS管理起来，并能协调它们的工作。
特别是那些任意两个客户端（这两个客户端可能连接上了不同的AS）之间需要相互通信的应用，使用ESPlatform是非常合适的。 使用ESPlatform群集系统，所有的在线用户就像连接在同一个AS上一样，服务端实例对于客户端而言，是透明的。
一. 群集基础模型
在单个AS应用中，我们的关注焦点在于服务端和客户端。而在多AS的群集应用中，我们需要增加一个核心关注点，那就是平台层。ESPlatform群集模型可以划分为三层：平台层、应用层（即AS位于的层）、客户端。如下图所示的是ESPlatform所支持的最简单的群集模型：
平台层的核心是ACMS（应用群集管理服务器），用于管理ESPlatform群集中的所有应用服务器。ACMS的主要职责可概括为：
（1）管理所有的在线AS。
（2）管理所有的在线用户及其P2P地址。
（3）在AS之间转发消息。
（4）提供服务接口给群集外的其它系统调用。
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之间的状态出现了不一致，整个群集的运行都可能受到严重的影响以及出现莫名的错误。
建议AS与ACMS部署在同一个机房的同一个局域网内，以保证通信的质量和速度。如果AS与ACMS分布在广域网，则必须使用同样保障的高质量的专线连接。
2.尽可能使需要相互沟通的客户端连上同一个AS
一个新启动的客户端应该连接到哪个AS服务器，是由我们的AS分配策略来决定的。所以，为了尽可能地减少经ACMS转发的消息数量，也就是尽可能地降低ACMS的负载，在设计AS的分配策略时，应特别注意尽可能地使那些需要相互沟通的客户端连接到同一个AS服务个器上。这样，即使两个客户端之间的P2P通道没有打通，那么，他们之间的交互信息只要通过AS中转就可以了，不需要麻烦到ACMS。
3.热机备份ACMS
在群集模型中，很容易看到ACMS是整个群集系统的“单点”，如果ACMS挂掉，虽然每个AS还可以独立工作，但跨AS的消息就无法完成转发了。所以，在部署ACMS时，最好使用双热机备份或多热机备份，这样在主ACMS意外当机后，另一台备份机就立马可以接手工作。
四. 客户端如何选择最优的应用服务器登录？
一般二次开发时，会构建一个登录决策服务器（LogonDecisionServer） ，LogonDecisionServer通过 WebAPI 暴露服务。客户端在登录之前，先访问该WebAPI获取自己要登录的应用服务器AS节点的IP和端口，然后再去登录目标AS。
那么，LogonDecisionServer 一般采用哪些策略来决定请求的客户端最适合登录那台AS了？
1. 如果单单是为了解决服务器负载过大而使用群集的情况，LogonDecisionServer 每次就分配当前负载最小的那台AS给请求的客户端。
2. 如果分布式群集主要是为了解决不同区域的客户端到服务器的网络质量问题，那么，通常有两种方案：
（1）在服务端决策。
在LogonDecisionServer配置文件中配置好 “地理区域 - 应用服务器IP与端口” 的映射表，当客户端来请求时，LogonDecisionServer首先根据客户端的IP找到其所对应的地理区域，然后在从映射表中匹配到其对应的应用服务器AS，将其IP与端口返回给客户端。
（2）在客户端决策。
每次客户端请求时，LogonDecisionServer都将在线的所有的AS的IP与端口列表返回给客户端，客户端针对列表中的每一个IP进行ping测试，然后通过比较ping值和抖动、丢包情况综合决定网络通道质量最好的那台AS服务器作为要登录的目标服务器。
五. 小结
ESPlatform提供了最基础的群集模型（本文的第一个模型图），而后续的进化模型都是在这个基础上根据可能的需求所进行的常规变化。
但无论怎么变化，其基础仍然是我们第一个模型图所示的基础模型，它是ESPlatform的核心模型。对于某些业务简单的系统，最简单的模型可能就已经足够了。对于那些复杂的系统，在这个核心模型上要如何变化、如何深化，没有固定的方向可言，其最终取决于我们系统的需求。正如有句话是这样说的：凭空想象的模型是没有用的，必须要与实际的需求结合起来，并在实战中不断淬炼。
下一篇：ESPlatform 群集平台（01） －－ 迁移到群集平台
上一篇：ESFramework 开发手册（13） －－ ESFramework 二次开发说明
-----------------------------------------------------------------------------------------------------------------------------------------------
Q Q：168757008
