ESPlatform 群集平台(00) -- 概念与模型

       当我们将基于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)管理所有的在线用户及其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部署在同一个机房的同一个局域网内,以保证通信的质量和速度。

2.尽可能使需要相互沟通的客户端连上同一个AS

       一个新启动的客户端应该连接到哪个AS服务器,是由我们的AS分配策略来决定的。所以,为了尽可能地减少经ACMS转发的消息数量,也就是尽可能地降低ACMS的负载,在设计AS的分配策略时,应特别注意尽可能地使那些需要相互沟通的客户端连接到同一个AS服务个器上。这样,即使两个客户端之间的P2P通道没有打通,那么,他们之间的交互信息只要通过AS中转就可以了,不需要麻烦到ACMS。

3.热机备份ACMS

       在群集模型中,很容易看到ACMS是整个群集系统的“单点”,如果ACMS挂掉,虽然每个AS还可以独立工作,但跨AS的消息就无法完成转发了。所以,在部署ACMS时,最好使用双热机备份或多热机备份,这样在主ACMS意外当机后,另一台备份机就立马可以接手工作。

四. 小结

       ESPlatform提供了最基础的群集模型(本文的第一个模型图),而后续的进化模型都是在这个基础上根据可能的需求所进行的常规变化。

       但无论怎么变化,其基础仍然是我们第一个模型图所示的基础模型,它是ESPlatform的核心模型。对于某些业务简单的系统,最简单的模型可能就已经足够了。对于那些复杂的系统,在这个核心模型上要如何变化、如何深化,没有固定的方向可言,其最终取决于我们系统的需求。正如有句话是这样说的:凭空想象的模型是没有用的,必须要与实际的需求结合起来,并在实战中不断淬炼。 

 

      下一篇:ESPlatform 群集平台(01) -- 迁移到群集平台 

      上一篇:ESFramework 开发手册(13) -- ESFramework 二次开发说明 

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

下载免费版本的ESFramework 以及 demo源码  

阅读 更多ESFramework开发手册系列文章

Q Q:168757008

官网:www.oraycn.com

导航

首页

官方网站

立即咨询 

站内搜索

ESFramework 通信框架

详细说明

SDK下载

ESFramework FAQ

版本变更记录

OMCS 语音视频框架

详细说明

SDK下载

OMCS FAQ

版本变更记录

OrayTalk 企业即时通讯系统

详细说明

客户端下载

傲瑞实用组件

SDK下载

NPush 消息推送组件

StriveEngine 轻量级的通信引擎

MFile 语音视频录制组件

MCapture 语音视频采集组件

MPlayer 语音视频播放组件

OAUS 自动升级系统

傲瑞组件 FAQ

授权

授权流程

产品授权说明

产品选购指南

授权SDK使用说明

其它

SDK使用技巧

联系我们

电话:027-87638960

Q Q:168757008

邮件:master@oraycn.com