FS （ FunctionServer ），功能服务器，处理并且仅处理所有的功能性请求，不参与用户管理、状态保持等，提供最纯粹的功能服务。
AS （ ApplicationServer ），应用服务器，转发所有的功能请求给 FS ，并处理所有的非功能请求，并管理终端用户、进行状态保持、日志记录等。
上图中的功能服务器 FS 的个数可能是 0 到 N （ N>0 ）个。在某种意义上可以认为，每个功能服务器 FS 是可以互换的。
将服务器拆分为功能服务器和应用服务器有两个显而易见的好处：
（1） 功能服务器 FS 的完全可复用。由于功能服务器采用“框架＋插件”的结构，所以整个功能服务器是完全可复用的，从一个具体应用转换到另一个具体应用，只需要替换功能插件即可， FS 不需重新编译。
（2） 由于 FS 仅提供最纯粹的功能服务，不需要进行用户管理、状态保持，这种功能服务器在运行时的无状态性，使得功能服务器很容易实现负载均衡集群（后文中会讲到，这种动态负载均衡是如何实现的）。
如果 ESFramework 仅仅做到这一步，就没有必要拿出来和大家分享了， ESFramework 不仅对这种 4 层架构给予了充分完整的支持， ESFramework 更进了一步，它可以支持“类似地域分布式”的体系结构。读者可能已经了解到，上面的 4 层架构已经是一种分布式架构了，那么这里说的“类似地域分布式”又是什么意思？
可以这么说，
4
层架构是一种“纵向”的架构，“类似地域分布式”则侧重于“横向”，在“类似地域分布式”体系结构中，每一个具体的“
4
层架构的实现”只是其中的一个组成元素。我举个例子，现在我们的一个应用需要为全国范围内的所有大城市的手机用户提供某种基于
C/S
的手机增值服务。我们的经验是，为每个城市配置一个应用服务器
AS
，由于大量的计算在该
AS
对应的
FS
上，所以可能需要多个
FS
为这个
AS
服务。而每个城市的
AS
之间可能需要相互通信（比如处理漫游用户），这就需要将
AS
也管理起来，管理
AS
的服务器是
IRAS
（跨区域服务器）。如此一来，我可以画出下图作为例子：
图中的
FunAddin
是
功能插件
，这再前文已介绍过了。整个体系中，终端请求的服务主要分为两大类，一是向应用服务器
AS
请求功能服务，另一类是终端与终端之间的非功能通信。所有的功能服务由功能插件（
FunAddin
）进行处理，所有的非功能通信由应用服务器处理或中转。如果，终端请求的功能服务位于外部系统，则功能插件会自动定位外部系统的地址，然后通过
WebService
等方式向外部系统提交请求。
好了，读者已经了解了
ESFramework
中的
4
层结构和“类似地域分布式”结构是怎么回事了，下面我简单概述一下
ESFramework
对
4
层结构和“类似地域分布式”结构提供了哪些强有力的特性支持：
1．
基于构件
除了所有的功能插件是构件外，整个
ESF
平台也是由构件组装而成。其好处是：
（1）
快速搭建系统
（2）
促进构件复用，如
AS/IRAS/FS/IRFS
可以使用同一个通信组件来完成通信层工作。
（3）
实现功能插件的“热插拔”，可以在运行时动态的添加
/
移除功能服务
2．
高度可扩展
由于
ESF
服务平台体系需要随时随地的应付各种突如其来的变化，其一定要具备高度的可扩展性：
（1）
功能插件的“热插拔”
（2）
外部服务的动态接入（通常是通过
WebService
）
（3）
应用服务器
AS
的动态添加
/
移除，比如，新开通针对大连城市的服务。
（4）
功能服务器
FS
的动态添加
/
移除，实现功能服务器的动态负载均衡集群。
3．
高度可伸缩
随着我们提供的服务日渐深入人心，我们的用户的数量会急剧增加，所以
ESF
服务平台体系必须具备高度可伸缩性来提高系统的最大负载和吞吐量。
（1）
由于功能服务器需要进行大量的功能运算，所以平台的瓶颈通常位于功能服务器，这可以通过功能服务器的动态集群来解决。集群中的各个功能服务器之间的负载均衡由对应的应用服务器
AS
来调度。
（2）
当单个区域的常在线用户数量突破
5000
～
10000
时，我们需要添加
AS
进行区域级的负载均衡，这可以通过具有端口映射功能分硬件来解决。
4．
高度可复用
ESF
服务平台体系并非只是适用于我们的
LBS
服务，其实，
ESF
服务平台体系是一个高度可复用的体系，也就是说
ESF
服务平台可以作为任何、任意的服务的基本平台，只要其所提供的服务是终端和服务器之间通过
Tcp
进行基于连接的通信。
5．
分布式
除了外部系统的接入通过分布式服务进行外，各应用服务器之间、功能服务器与应用服务器之间、应用服务器和跨区域的应用服务器之间都是采用分布式通信。跨区域的应用服务器通过类似于
remoting
的方式在各个应用服务器之间进行调度。
6．
简单部署、自动升级
由于
ESF
服务平台体系服务的区域可能非常多，比如各个大城市可能都需要部署应用服务器和功能服务器，所以如果通过人工进行部署和升级是非常低效的，
ESF
服务平台提供了自动升级、加载、运行的功能。
（1）
服务平台安装后，仅仅需要修改配置文件中的几个参数即可正常运行。
（2）
当功能插件拥有新版本的时候，可以在不停止服务的情况下，自动升级到新版本。
（3）
当各服务器系统（
AS/IRAS/FS/IRFS
）有新版本时，会在该系统重启的时候自动升级到新版本。为了在升级的时候不终止服务，服务器系统可以使用逐步升级的方式。
7．
通信保证机制
当遇到网络突然断开或某服务器重启的情况，在网络恢复或服务器重启完成后，需要一种能自动的立即恢复通信（比如AS和FS的通信，各AS与IRAS之间的通信）的机制，
ESF
服务平台提供了这种保证，其采用的策略主要基于：
（1）
定时论询
（2）
Tcp
连接池自动重连
（3）
连接动态反转
8．
漫游支持、跨区域功能请求支持
在
ESF
服务平台体系中，漫游是指某一区域的用户登录到另外一区域的应用服务器
AS
上，对于此
AS
来说，该用户是漫游用户。如果用户登录到某
AS
却请求其它区域的功能服务，则是跨区域的功能请求。
ESF
服务平台对这两种情况都给予了充分的支持。
9．
终端与终端之间的通信支持
有时，终端需要和终端（可能是同区域的、也可能是其它区域的）之间进行通信，并且这种通信可以基于连接和基于非连接。基于连接的通信像实时视频聊天、实时监控，基于非连接的像发送一张图片给不在线的用户。所有这些，
ESF
服务平台都提供了支持。
10
．支持二次开发
在基于
ESF
服务平台高度可复用和可扩展的基础上，
ESF
平台可以非常容易的支持二次开发，只要遵循相同的接口和通信协议，就可在
ESF
平台进行二次开发。
11
．客户端框架
如果应用的客户端也可以使用
.NET
开发，则
ESFramework
也提供了完善的支持，在
ESFramework
的支持下，开发客户端仅仅需要开发业务插件就可以了，而整个网络通信、多线程、升级部署等，都由框架完成了。后面的文章中我会介绍如何在
AgileIM
中开发自定义的业务插件。
上面的所有特性将会在“
基于
C/S
的
4
层架构
”部分分节介绍，感谢关注！
如果你的应用不需要这么复杂的结构，比如仅仅一个简单的3层架构，那么ESFramework仍然可以帮助你快速构建，ESFramework是个轻量级的应用框架，你不会为那些ESFramework提供了的而你不需要的功能/特性付出任何代价。
（注意，ESFramework不太适合处理遗留系统（就像你很难使用MFC去处理基于VCL构建的UI应用一样），ESFramework虽然与应用无关，但是为了能将更多的任务从应用中抽象到框架中来，必须对应用做一些假设，幸运的是，ESFramework仅仅对应用的通信协议做了最少的假设，这个假设包含在
NetMessage
中。如果你不是处理遗留系统，而是构建一个全新的C/S应用，那么ESFramework可以为你节省大量的架构设计时间、软件开发时间、调试和维护时间。）
（最后做个广告，如果你新接手的项目非常适合采用上面介绍的
4
层架构或“类似地域分布式”体系结构，希望我们有合作的机会：）通过
agilesoft@163.com
联系我）
