企业级服务器设计与实现经验之系统框架（二）－－功能/应用服务器主体框架

前面两篇文章已经介绍了功能服务器FS与应用服务器AS拆开的原因和它们各自的职责。这篇文章我们主要来看看FS和AS的主体框架是怎样的。首先要说明，无论FS或AS，它们都是一个复杂的系统，特别是AS，它有许多的管理、记录功能，所以单凭这一篇文章是不可能将它们的每一个方面描述清楚的。相反，我在此文中仅仅给出它们的骨架结构，许多细节都将忽略，看过第一篇文章读者可以根据主题目录知道，这些细节会在后面的文章中逐渐补充进来。

FS和AS的最大特点就是采用了“框架＋插件”的结构模式。让我们先来了解一下FS的骨架是什么样子的。

一.功能服务器结构

各模块主要作用

（1）网络通讯插件管理模块：用于加载、管理所有通信插件。通信插件的主要作用是接收客户端来的消息，不作任何处理直接转发给消息分派模块。
（2）消息分派模块：将从通讯插件来的字节流分裂为一个或多个请求消息，然后针对没有请求消息，调用对应的功能插件来处理，并将处理点结果返回给通信插件，最后由通信插件发送给客户端。
（3）UI用户界面：用于显示当前的连接，和每个连接上正在请求的服务。并控制加载的各个功能插件和通信插件的相关信息。
（4）功能插件管理模块：用于加载、管理所有的功能插件。
（5）日志记录模块：将一些重要的事件信息写入到Windows的事件日志中或日志数据库中。

DSCore系统基本特点

（1）
DSCore框架不提供任何具体的功能服务，所有的功能服务封装在各个插件中。

（2）
DSCore框架主要用于整合各个基础模块，并管理所有的插件。

（3）
插件机制可以解决动态加载/卸载服务（所谓“热插拔”）的问题。
（4）
DSCore功能服务器将支持TCP、UDP、WebService、.Net
Remoting这四种主流的通信协议。并且这四种通信协议也封装在各自的插件中。当需要更换通信协议时，只需要加载对应的通信插件即可。
（5）
DSCore功能服务器采用“异步＋线程池”或完成端口来对大并发性提供支持。
（6）
DSCore功能服务器将采用对象池来管理连接信息对象。
（7）
功能服务器是一个可复用的框架，它可以适用于各种C/S模式应用的服务端框架，面对不同的应用，只需要替换与应用相关的功能插件即可。

二.应用服务器结构
应用服务器的结构相对相对功能服务器来说要复杂许多。





各主要模块/插件的作用如下：

（1）
用户管理模块：用于管理所有在线用户的状态，并对用户作定时掉线检查。

（2）
Basic消息处理插件：用于处理非功能请求，如登录请求、退出请求等。

（3）
消息分派模块：根据消息的类别（基本请求、功能请求），将基本请求转发给Basic消息处理插件处理，而将功能请求通过连接池管理者转发给功能服务器进行处理。

（4）
回复截获者插件：用于截获每一个请求的回复数据，并对期望类型的回复进行跟踪或其它处理。
（5）
用户任务报告者插件：用于将需要永久存储的信息记录到数据库或文件，甚至可以发送到专门用户服务器的消息队列。

为了更好的理解各个模块/插件之间的互动关系，可以参见下面的AS消息关联图。



注意，由“小圆圈”引出的是事件，而一个箭头指向小圆圈表示预定事件。上面的图示是在AS以TCP方式发布服务时的消息关联图，如果是UDP方式，这个结构将会简单许多。所以后面的讨论我们将主要集中在TCP方式上，而对其它的通信方式，则可以类推之。

对于上图，可能还有很多不清晰的地方，没关系，在后面的介绍中，这些地方会逐渐的清晰起来。从下期开始我们将依照第一篇文章的主题目录逐渐深入到各个方向的细节中去。下期再见！