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

我们将DataServer拆分为功能服务器和应用服务器，基于如下几个方面的考虑：
（1） 能更简单的添加不同类型的应用。在这种拆分的状态下，如果需要增加一个新的应用，那么只需要增加一个新的应用服务器即可。比如，现有的应用服务器是以TCP的方式提供服务，如果我想增加一种以WebService方式来发布我们的服务，那么我只要增加一个WebService应用服务器，而不管是TCP应用服务器还是WebService应用服务器，它们的后端都是通过同一个功能服务器来提供功能处理的。
（2） 功能服务器框架可复用。由于功能服务器只处理功能请求，不参与用户管理等其它具体与应用相关的内容，所以它是一个单纯的服务器，正是由于这种单纯性，使得功能服务器框架可以高度复用。比如，你想开发一套自己的特殊服务，那么完全可以将整个功能服务器搬过来，只要开发你自己的一系列功能插件来提供你想要的服务就OK了，这就把本来开发一个系统的工作量缩减为为开发几个插件工作量。这是一种高级的复用。
（3） 集群更容易实现。我们知道，功能服务器处理所有的功能请求，所以，当在线用户人数增多时，一个功能服务器忙不过来，这是常见的情况，而应用服务器由于只作简单的用户管理和转发数据，没有太大的计算工作，所以应用服务器处理起来一般是游刃有余的，瓶颈在功能服务器。在这样的情况下，我们可以让一台应用服务器连上多个功能服务器，然后加上调度功能，即可简单的实现负载平衡集群，如果把对功能服务器的性能监视做得更深入一些，甚至可以做到故障转移集群。我们不用再求助COM+等类似的东东了。



（4） 实现功能服务器的“热插拔”。前面提到了实现功能插件的“热插拔”是功能服务器的一个基本需求，在运行的过程中可以动态的添加/移除功能服务器自然也是我们的基本需求之一了。当我们发现某台功能服务器需要停机维修时，只要在与之相关的应用服务器上点一下“移除”按钮就可以了；由于访问量的增加，当我们购买了一台新的机器作为功能服务器时，只要在相应的应用服务器上点一下“动态连接到功能服务器”按钮就可以了。一切都那么灵活，全在运行时完成，服务器不用停止，客户不用等待。
有人提出，将功能服务器FS和应用服务器AS拆开，FS和AS之间的通信就需要时间，这样会降低整体系统的效率。确实是会有点影响，但是考虑到AS与FS通常位于同一局域网内，它们之间可以通过TCP来保证可靠快速的通信，即使AS与FS位于异地，也可以通过专线来减少通信对系统整体性能的影响。考虑到上面列出的几点优势，我们有足够的理由来采用AS/FS这种灵活的模型。