企业级服务器设计与实现经验之系统框架（一）

http://blog.csdn.net/zhuweisky/article/details/411825

 

 这个题目听起来蛮吓人的，毕竟本人的经验值也不高，却大放厥词在这里谈“企业级”。原因有二，一是把这一年以来的开发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层结构的，比如后面将看到的功能插件。

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

 

 

 

我们将DataServer拆分为功能服务器和应用服务器，基于如下几个方面的考虑：

（1）       能更简单的添加不同类型的应用。在这种拆分的状态下，如果需要增加一个新的应用，那么只需要增加一个新的应用服务器即可。比如，现有的应用服务器是以TCP的方式提供服务，如果我想增加一种以WebService方式来发布我们的服务，那么我只要增加一个WebService应用服务器，而不管是TCP应用服务器还是WebService应用服务器，它们的后端都是通过同一个功能服务器来提供功能处理的。

（2）       功能服务器框架可复用。由于功能服务器只处理功能请求，不参与用户管理等其它具体与应用相关的内容，所以它是一个单纯的服务器，正是由于这种单纯性，使得功能服务器框架可以高度复用。比如，你想开发一套自己的特殊服务，那么完全可以将整个功能服务器搬过来，只要开发你自己的一系列功能插件来提供你想要的服务就OK了，这就把本来开发一个系统的工作量缩减为为开发几个插件工作量。这是一种高级的复用。

（3）       集群更容易实现。我们知道，功能服务器处理所有的功能请求，所以，当在线用户人数增多时，一个功能服务器忙不过来，这是常见的情况，而应用服务器由于只作简单的用户管理和转发数据，没有太大的计算工作，所以应用服务器处理起来一般是游刃有余的，瓶颈在功能服务器。在这样的情况下，我们可以让一台应用服务器连上多个功能服务器，然后加上调度功能，即可简单的实现负载平衡集群，如果把对功能服务器的性能监视做得更深入一些，甚至可以做到故障转移集群。我们不用再求助COM+等类似的东东了。

         

（4）       实现功能服务器的“热插拔”。前面提到了实现功能插件的“热插拔”是功能服务器的一个基本需求，在运行的过程中可以动态的添加/移除功能服务器自然也是我们的基本需求之一了。当我们发现某台功能服务器需要停机维修时，只要在与之相关的应用服务器上点一下“移除”按钮就可以了；由于访问量的增加，当我们购买了一台新的机器作为功能服务器时，只要在相应的应用服务器上点一下“动态连接到功能服务器”按钮就可以了。一切都那么灵活，全在运行时完成，服务器不用停止，客户不用等待。

 

 

    有人提出，将功能服务器AS拆开，AS之间的通信就需要时间，这样会降低整体系统的效率。确实是会有点影响，但是考虑到FS通常位于同一局域网内，它们之间可以通过AS与AS/FS这种灵活的模型。