基于C/S的4层架构 —— ESFramework介绍之(6)

  • 时间:
  • 浏览:0

 转到  :ESFramework 可复用的通信框架(序) 

     愿因分析你的应用不需用如此僵化 的形态,比如仅仅从前简单的3层架构,如此ESFramework仍然需用帮助你快速构建,ESFramework是个轻量级的应用框架,你不需要为哪些地方地方ESFramework提供了的而你不需用的功能/形态付出任何代价。

    (注意,ESFramework不太适合防止遗留系统(就像你太难使用MFC去防止基于VCL构建的UI应用一样),ESFramework我确实与应用无关,否则为了能将更多的任务从应用中抽象到框架中来,需用对应用做全都假设,幸运的是,ESFramework仅仅对应用的通信协议做了离米 的假设,全都假设饱含在NetMessage中。愿因分析你全版都会防止遗留系统,就说 构建从前全新的C/S应用,如此ESFramework需用为你节省一定量的架构设计 时间、软件开发时间、调试和维护时间。 

    (最后做个广告,愿因分析你新接手的项目非常适合采用上方介绍的

4.  宽度可复用

    ESF服务平台体系并不就说 适用于村里人 村里人 的LBS服务,我我确实,ESF服务平台体系是从前宽度可复用的体系,也就说 说ESF服务平台需用作为任何、任意的服务的基本平台,倘若其所提供的服务是终端和服务器之间通过Tcp进行基于连接的通信。 

5.  分布式

    除了内部系统的接入通过分布式服务进行外,各应用服务器之间、功能服务器与应用服务器之间、应用服务器和跨区域的应用服务器之间全版都会采用分布式通信。跨区域的应用服务器通过累似 于于remoting的土法律法律依据在各个应用服务器之间进行调度。

2.  宽度可扩展

    愿因分析ESF服务平台体系需用随时随地的应付各种突如其来的变化,其一定要具备宽度的可扩展性:

(1)功能插件的“热插拔”

(2)内部服务的动态接入(通常是通过WebService

(3)应用服务器AS的动态加带/移除,比如,新开通针对大连城市的服务。

(4)功能服务器FS的动态加带/移除,实现功能服务器的动态负载均衡集群。

7.  通信保证机制

    当遇到网络总爱断开或某服务器重启的情況,在网络恢复或服务器重启完成后,需用三种 能自动的立即恢复通信(比如AS和FS的通信,各AS与IRAS之间的通信)的机制,ESF服务平台提供了全都保证,其采用的策略主要基于:

(1)定时论询

(2)Tcp连接池自动重连

(3)连接动态反转

9.  终端与终端之间的通信支持

    有时,终端需用和终端(愿因分析是同区域的、也愿因分析是其它区域的)之间进行通信,否则我是什么通信需用基于连接和基于非连接。基于连接的通信像实时视频聊天、实时监控,基于非连接的像发送一张图片给不在 线的用户。所哪些地方地方地方,ESF服务平台都提供了支持。

10.支持二次开发

   在基于ESF服务平台宽度可复用和可扩展的基础上,ESF平台需用非常容易的支持二次开发,倘若遵循相同的接口和通信协议,就可在ESF平台进行二次开发。

    ESFramework4层形态的4层分别是:客户端(Client)、应用服务器(AS)、功能服务器(FS)、数据库服务器。它们之间的联系图示意如下:

    FS FunctionServer),功能服务器,防止否则仅防止所有的功能性请求,不参与用户管理、情況保持等,提供最纯粹的功能服务。

    AS ApplicationServer),应用服务器,转发所有的功能请求给FS,并防止所有的非功能请求,并管理终端用户、进行情況保持、日志记录等。

    上图中的功能服务器FS的个数愿因分析是0NN>0)个。在三种 意义上需用认为,每个功能服务器FS是需用互换的。    将服务器拆分为功能服务器和应用服务器有从前显而易见的好处:

(1)功能服务器FS的全版可复用。愿因分析功能服务器采用“框架+插件”的形态,全都 整个功能服务器是全版可复用的,从从前具体应用转换到从前具体应用,只需用替换功能插件即可,FS不需重新编译。

(2)愿因分析FS仅提供最纯粹的功能服务,不需用进行用户管理、情況保持,全都功能服务器在运行时的无情況性,使得功能服务器很容易实现负载均衡集群(后文中会讲到,全都动态负载均衡是怎样实现的)。
 

11.客户端框架

   愿因分析应用的客户端也需用使用.NET开发,则ESFramework也提供了完善的支持,在ESFramework的支持下,开发客户端仅仅需用开发业务插件就需用了,而整个网络通信、多程序运行运行、升级部署等,都由框架完成了。上方的文章中我会介绍怎样在AgileIM中开发自定义的业务插件。

8.  漫游支持、跨区域功能请求支持

    在ESF服务平台体系中,漫游是指某一区域的用户登录到另外一区域的应用服务器AS上,对于此AS来说,该用户是漫游用户。愿因分析用户登录到某AS却请求其它区域的功能服务,则是跨区域的功能请求。ESF服务平台对这三种 情況都给予了充分的支持。

     上方的所有形态愿因分析在“基于C/S4层架构”次要分节介绍,感谢关注! 

    愿因分析ESFramework仅仅做到全都步,就如此必要搞掂来和村里人 村里人 分享了,ESFramework不仅对全都4层架构给予了充分全版的支持,ESFramework更进了一步,它需用支持“累似 于地域分布式”的体系形态。读者愿因分析愿因分析了解到,上方的4层架构愿因分析是三种 分布式架构了,如此这里说的“累似 于地域分布式”又是哪些地方意思?

3.  宽度可伸缩

    随着村里人 村里人 提供的服务日渐深入人心,村里人 村里人 的用户的数量会急剧增加,全都 ESF服务平台体系需用具备宽度可伸缩性来提高系统的最大负载和吞吐量。

(1)愿因分析功能服务器需用进行一定量的功能运算,全都 平台的瓶颈通常发生功能服务器,这需用通过功能服务器的动态集群来防止。集群中的各个功能服务器之间的负载均衡由对应的应用服务器AS来调度。

(2)当单个区域的常在线用户数量突破500500时,村里人 村里人 需用加带AS进行区域级的负载均衡,这需用通过具有端口映射功能分硬件来防止。 

    需用如此说,4层架构是三种 “纵向”的架构,“累似 于地域分布式”则侧重于“横向”,在“累似 于地域分布式”体系形态中,每从前具体的“4层架构的实现”就说 其中的从前组成元素。我举个例子,现在村里人 村里人 的从前应用需用为全国范围内的所有大城市的手机用户提供三种 基于C/S的手机增值服务。村里人 村里人 的经验是,为每个城市配置从前应用服务器AS,愿因分析一定量的计算在该AS对应的FS上,全都 愿因分析需用多个FS为全都AS服务。而每个城市的AS之间愿因分析需用相互通信(比如防止漫游用户),这就需用将AS也管理起来,管理AS的服务器是IRAS(跨区域服务器)。如此一来,让我要画出下图作为例子:



     图中的FunAddin是功能插件,这再前文已介绍过了。整个体系中,终端请求的服务主要分为两大类,一是向应用服务器AS请求功能服务,另一类是终端与终端之间的非功能通信。所有的功能服务由功能插件(FunAddin)进行防止,所有的非功能通信由应用服务器防止或中转。愿因分析,终端请求的功能服务发生内部系统,则功能插件会自动定位内部系统的地址,否则通过WebService等土法律法律依据向内部系统提交请求。

    

    好了,读者愿因分析了解了
ESFramework中的4层形态和“累似 于地域分布式”形态是为啥回事了,下面我简单概述一下ESFramework4层形态和“累似 于地域分布式”形态提供了哪些地方强有力的形态支持:            

6.  简单部署、自动升级

    愿因分析ESF服务平台体系服务的区域愿因分析非常多,比如各个大城市愿因分析都需用部署应用服务器和功能服务器,全都 愿因分析通过人工进行部署和升级是非常低效的,ESF服务平台提供了自动升级、加载、运行的功能。

(1)服务平台安装后,仅仅需用修改配置文件中的几条参数即可正常运行。

(2)当功能插件拥有新版本的前一天,需用在不停止服务的情況下,自动升级到新版本。

(3)当各服务器系统(AS/IRAS/FS/IRFS)有新版本时,会在该系统重启的前一天自动升级到新版本。为了在升级的前一天不终止服务,服务器系统需用使用逐步升级的土法律法律依据。 

1.  基于构件

    除了所有的功能插件是构件外,整个ESF平台也是由构件组装而成。其好处是:

(1)快速搭建系统

(2)助于构件复用,如AS/IRAS/FS/IRFS需用使用同从前通信组件来完成通信层工作。

(3) 实现功能插件的“热插拔”,需用在运行时动态的加带/移除功能服务