企业级服务器设计与实现经验之开篇

 

      这个题目听起来蛮吓人的，毕竟本人的经验值也不高，却大放厥词在这里谈“企业级”。原因有二，一是把这一年以来的开发DataServer服务器的工作做个总结；二是希望能抛砖引玉，希望这方面的研究和交流繁荣起来，毕竟，目前讲这方面实战经验的文章资料太少了。

      正式开题之前，绝对有必要先简单的介绍相关的背景。在写这篇文章的时候，我在航天量子数码科技有限公司（Aeromatex）产品部工作，全权负责DataServer的设计与实现。

DataServer基于GIS/GPS是用于提供各种基于位置服务及其它远程信息服务的发布平台，它主要作为服务器端对各种终端（如手机、智能设备、网页浏览器等）提供服务。服务的类型很多，为了便于后面的展开，我简单的介绍两个。第一个是POI查询，POI即兴趣点，通俗的说就是感兴趣的位置，如某所大学，某个酒店。比如客户端请求“武汉大学”这个POI的信息，服务器就会返回与武汉大学相关信息，如地理位置（经纬度）、电话、邮编、简介等资料。第二个是路径规划服务，所谓路径规划，就是客户端发出一个类似“从地方A到地方B最短的路径该怎么走？”，服务端则会返回一条路径，该路径描述大致像“从A出发直走到D处左转……到达B”。

 

 

 

 

 

像POI查询、路径规划等服务，我们称之为功能服务。与功能服务相对的是非功能服务，如用户管理、流量记录、日志管理等。在一开始就将服务划分为功能性的与非功能性的，有利于后面的设计。基于服务的功能性与非功能性的划分，我们将DataServer服务器拆分为两个：功能服务器和应用服务器。

功能服务器的主要目标是高效稳定的提供纯的功能服务，不与具体的应用相关，也不管理用户，它作为应用服务器的后盾。DataServer应用服务器作为功能服务器的客户端，客户直接与应用服务器相连，应用服务器转发客户的功能请求给功能服务器，并将来自功能服务器的回复发送给客户端，另外应用服务器还要实现对用户的管理。它们之间的联系如下图所示。

 

 

就像所有企业级服务器所要求的一样，DataServer服务器（无论是应用服务器还是功能服务器）必须处理以下棘手的问题：

 

 

 

 

 

（1）      极大的并发量。如果是以TCP的方式提供服务，几千个客户同时在线是很正常的。

 

 

 

 

 

（2）      响应速度快。如果客户端发出一个请求后要等10秒以上才能得到回复，估计客户下次就没有兴趣再访问你的服务了。

 

 

 

 

 

（3）      稳定性。7×24小时连续工作，除非硬件故障。而解决硬件故障的方法之一是使用故障转移集群技术。

 

 

 

 

 

（4）      灵活。我们对DataServer的要求之一是实现功能服务的“热插拔”。我们采用插件技术来解决“热插拔”问题。

 

 

 

 

 

（5）      安全。服务器与客户端之间的通信消息必须加密。

 

 

 

 

 

（6）      无人看守。如果停/断电又来电后，DataServer能自动启动并加载服务然后进入运行。这样周末无人在时若发生停电又恢复供电的情况则无需人工干预了。

 

 

我们将功能服务做成插件，这样就可以在运行时加载/移除一项功能服务。因为位置服务的类型会越来越多，不停止服务器而加载新的服务进来是很基本的要求。为了能方便的更替通信协议，如把TCP方式改为UDP方式，我们把通信层也做成插件，更换通信协议，只需要更换通信插件即可。系统中主要的插件类型就是通信插件和功能插件。在以后的分析设计中，还会有更多类型的插件加入进来。

为了更清晰的介绍DataServer功能/应用服务器的设计与实现过程，我打算依照以下几个主题逐渐展开。在深入这些主题的的过程中，我们可以看到以上的棘手问题是如何一个个被解决的。主要的主题目录如下：

一．         系统框架。

（1）      基础结构

（2）      负载平衡集群

（3）      综合考虑 

 

二．         插件系统。

（1）      插件基础

（2）      插件加载器

（3）      插件管理者

（4）      系统插件综合管理器

（5）      通信插件

（6）      功能插件

（7）      基本请求处理者插件

（8）      回复截获者插件

（9）      用户任务报告者插件 

 

三．         通信层基础

（1）      Tcp监听者IXTcpListener――用于封装TCP监听者及监听线程。

（2）      线程安全的网络流――ISafeNetworkStream

（3）      用户连接上下文ContextKey

（4）      异步通信模型

（5）      完成端口模型

（6）      分布式远程处理 .NET Remoting 

 

四．         应用服务器与功能服务器之间功能性通信

（1）      TCP连接池

（2）      多TCP连接池管理器

（3）      TCP连接池调度者 

 

五．         应用服务器与功能服务器之间非功能性通信

（1）      功能服务器性能监视器（2）      功能服务器上下文信息发布者XmlParser

（2）      数据库基础配置管理者（3）      数据库信息配置控件DBConfigControl 

 

八．         基本用户管理。

（1）      用户合法性检查

（2）      定时掉线检查 

 

九．         消息管理――请求与回复消息

（1）      消息格式定义

（2）      消息加密

（3）      消息分裂器

（4）      消息分派器

（5）      消息处理器 

 

十．         日志记录。

十一．  其它

 

 

你也许感到奇怪，上面的各个主题似乎没有一个是关于3层/N层架构的。是的，没有，准确的说，这是一个“框架＋插件”的结构，是一种横向的架构，而3/N层架构侧重于纵向。但是横向架构中的某个插入的插件的实现方式可能就是3/N层结构的，比如后面将看到的功能插件。

上述的每个主题的一个小节都将在一期或多期中介绍，当然不一定按照上面的顺序。如果你也对这方面有兴趣，可以随时和我讨论，可以通过邮件[e-mail]和我交流。

 

 

 

 

 

感谢您的关注和参与。