对于最多几千人同时在线的通信应用，通常使用单台服务器就可以支撑。但是，当同时在线的用户数达到几万、几十万、甚至百万的时候，我们就需要很多的服务器来分担负载。但是，依据什么规则和结构来组织这些服务器，并使它们能相互协调合作，是最关键的问题。如果你的通信应用是基于ESFramework通信框架构建的，当同时在线的用户人数剧增时，就可以非常容易地迁移到ESPlatform，以解决巨大并发的问题。
ESPlatform 旨在协助快速构建大型的基于ESFramework通信框架的通信应用。ESPlatform也是通过应用服务器群集（Cluster）来解决巨大并发。ESPlatform支持三种群集模型：垂直分割模型、水平分割模型、交叉模型（垂直分割与水平分割相结合）。在介绍这三种模型之前，我们先简单描述一下ESPlatform中的几种服务器角色：
中心服务器Center Server：基于ESPlatform.Center构建。
（1） 管理所有的应用服务器AS。
（2） 管理所有在线用户列表。
（3） 在AS之间转发消息。
好友服务器Friend Server：管理全局的好友关系网络。
群组服务器Group Server：管理所有动态组、静态组。
应用服务器AS: 基于ESFramework通信框架/ESPlus/ESPlatform.Application构建，实现客户需要的业务流程。
1.水平分割群集模型
水平分割群集模型的关键点在于：所有的AS服务器都是对等的，是可以相互替换的，每台AS都提供相同的服务，即每台AS都能处理所有类型的消息，客户端无论登录到哪台AS都可以正常工作。该模型的伸缩性体现在，当用户人数增大时，我们可以动态的添加AS服务器来分担负载。
2.垂直分割群集模型
垂直分割群集模型的关键点在于：各AS服务器不是对等的，AS不能相互替换，每台AS提供服务可能都不相同，即每台AS能处理的消息类型仅仅是所有消息类型的一个子集。 所以，客户端如果需要获得完整的服务，就需要与每个AS都建立一个通信通道。该模型的伸缩性体现在，当用户人数增大时，我们可以继续拆分服务（即消息类型），将新拆分出来的服务交给新增加的AS服务器来处理。请注意，在拆分服务的时候，我们要遵守业务高内聚的原则 -- 将关系松散的业务拆开，而将关系紧密的放在一起。
还有一种典型的使用垂直分割模型的情况：当客户端与单个AS之间通信的消息频率非常高时，单个通信通道使得消息之间相互等待的状况更加恶劣，这时我们可以将一部分消息类型拆分出来给其它的AS处理。在客户端看来，单的通信通道变成了多个通信通道，以消除高频消息的拥塞状况。
3.交叉群集模型
交叉模型要复杂一些，其关键点在于：首先，对提供的服务（即消息类型）进行垂直分割，然后针对垂直分割得到的每一个服务子集，都采用一组对等的AS来处理（即水平分割）。这样就将垂直分割模型与水平分割模型结合起来了，以达到更强的可伸缩性。
比如上图示范中，我们将所有的服务分为M和N两组，M组有两台AS、N组有三台AS；而M CenterServer用于管理M组的所有AS，N CenterServer用于管理N组的所有AS。
4.进一步增加可伸缩性
在上述的三种群集模型中，水平分割模型是最简单、最直观的，也是最容易部署的。首先，客户端只需要与一个AS连接；其次，扩展时只需要增加提供完整服务的对等服务器，不需要对服务进行拆分；再次，扩展时客户端不用做任何修改，连配置都不用。所以，如果不是特别需要，我们建议尽可能地采用水平分割模型。而且，即使是采用水平分割模型，我们也还可以在具体的应用中进一步地增加可伸缩性，以达到类似垂直分割模型或交叉模型的效果。比如，当AS提供某个服务非常的消耗CPU或内存时，那么AS可以将其转交给功能服务器（FS）处理，如下图所示：
当然，这种利用FS来扩展AS的结构不仅仅可用于水平分割模型，同样也可用于垂直分割模型和交叉模型，以达到更强的伸缩性。
从利用FS来增强AS的层面来看，似乎水平分割模型已经可以完成所有高并发、高性能的任务，其实不然。有些情况下，还是必须要使用垂直分割模型或交叉模型的。比如，水平分割模型中，客户端都是单通道的，当客户端需要与服务器进行非常高频率的通信时，由于单通道的限制会导致出现消息拥塞的状况，这时就必须考虑使用垂直分割模型或交叉模型了。
正如你所想，对于利用FS进行AS增强，ESPlatform并不需要做任何特别的工作来支持，这点完全可以由具体应用根据具体情况自己完成，而且也非常容易。
对于在实际的基于ESFramework通信框架的通信项目中，如何搭建ESPlatform提供的三种群集模型，我们将在后面详细介绍。而ESFramework通信框架、ESPlus中当初有一些不起眼的基础设施和组件，正是为构建ESPlatform应用而存在的；也正是有这些基础设施和组件的存在，才使得将基于ESFramework通信框架的应用服务器迁移到ESPlatform是如此的简单，有些也许只要修改一下配置就可以做到。
最后要说明一点的是，ESPlatform的目的是解决大型应用中与通信相关的问题，当然也包括消息处理（这就和具体项目的业务衔接起来了），但是，在大型应用中，还有很多其它的问题可能需要专门领域的框架才能解决。比如，像类似文件服务器这样的应用，需要处理巨大数量的文件存储，就需要用到分布式的文件存储系统DFS，等等，这些就是ESFramework通信框架/ESPlatform之外的技术了。