设计及开发应用服务器（二）------相关技术.docVIP

设计与开发应用服务器（二）------相关技术 服务器的设计与开发涉及到诸多技术和问题，归纳一下大致可以分为以下几种： 服务器启动和接收数据过程 多线程策略 NIO 长连接 同步与异步 配置化支持 责任链模式 集群与负载均衡 数据包设计 服务端连接协议 客户端连接技术 服务器启动和数据请求过程 各种服务器所提供的功能和实现机制都不尽相同，但在启动和数据请求这块都长得差不多，遵循固定的一些流程和模式，启动过程一般按一下流程： 1）以main方法的形式提供由外部脚本触发的入口 2）载入配置文件，解析并构建上下文 3）初始化各个组件和资源 4）注册和启动监控和管理组件 5）启动连接监听 数据请求过程一般按一下流程： 1）侦听Socket 2）包装Connection 3）解析并包装数据 4）请求处理 5）向client发送处理结果 多线程策略 多线程的策略一般可以采取两种方式，一种是每一个线程负责监听、处理和返回结果所有事情，另外一种是把监听、接收、处理分开，各自都有独立的线程去处理。第一种策略比较简单，适用于处理不复杂的场景，图示如下： 第二种方式把一个较长的请求处理过程分割开，区分对待，这样能提高系统的吞吐量，比较适用与较为复杂的请求处理场景，图示如下： apache perfork在此基础上还有个main进程对这些work子进程进行管理，会根据请求的繁忙程度来调整work进程的数目，这也是可以借鉴的。 NIO NIO的特性非常适用于网络服务器的接收数据这块，因为不是每时每刻都有数据请求，因此没必要搞一堆Accept线程在那里监听等待，以Tomcat6的NIO接收数据为例： Amoeba也是采用NIO来接收数据流： 长连接 长连接顾名思义就是客户端与服务端保持连接，而不是每次请求都新建连接并在请求完后关闭连接，好处有以下几点： 减少新建和销毁线程所带来的代价 减少线程上下文切换带来的代价 适用与服务端需要监控客户端状态的场景，不需要通过客户端定时轮询来完成 建立了服务器主动向客户端推的通道 性能上与短连接的差异可以见以前的博文 构建高性能web之路------web服务器长连接 同步与异步 一般的情况下服务器端处理客户端请求都是同步的，客户端请求提交后会在一定的超时时间里等待服务器的response，这比较适用于短时间里能处理 完的请求，但如果一些请求，比如文件上传，在规定的超时时间里没法处理完，这样异步的处理就比较合适了，所谓异步就是客户端的请求提交后就可以结束这次请 求，不用等待response返回，在服务端处理完后主动把结果通知给客户端。Tomcat6推出的Comet技术即就是异步处理的典型，通过Comet 技术，客户端所需要的response信息不再需要主动的去索取，而是在服务器端以event的形式推至客户端。更多Comet的信息可见Tomcat官方文档 配置化支持 服务器的各种参数，比如线程池大小、连接协议等等，需要暴露出来可以配置，因此需要有配置管理机制。一般说来配置文件多以xml或 properties形式提供。对于properties比较简单，只是很难体现层次化结构，解析起来比较简单，通过Properties类就能很方便地 进行解析。而xml体现的信息更友好、更清晰，解析xml的方法比较多，一般用以下几种： SAX DOM JDOM、DOM4j、Digester等 前面两种比较原生态，SAX和DOM的区别就不再累述，JDOM、DOM4j和Digester都是基于前两种以上的开源框架，可以更加方便地调用。个人感觉如果xml不够复杂，不必使用太多的框架，原生态的东西就够用了。 解析完配置文件后，一般可以用更加有语义化的java bean来存储这些配置信息，这样可以更加方便其他模块的调用 责任链模式 责任链模式在服务器设计开发中比较常用，责任链模式的类图如下所示： 责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。Tomcat主要的架构pipeline-valve就是基于责任链模式。 通过责任链模式可以比较方便扩展对每次请求的处理，并且能很清新地明确各种处理之间的顺序和依赖关系 集群与负载均衡 为了保持集群实现简单，并更容易地实现横向扩展，尽量做到服务器之间无状态性，若需要状态可以参考Darkstar用集中式的Data service来抽象，保持逻辑处理的服务器是独立和平等的。在负载均衡这块可以采用硬负载（如F5）或软负载（LVS），这些都是比较成熟的方案，但如 果负载均衡仍然是系统的瓶颈，可以采用客户端负载均衡的做法，客户端做路由的机理如下图所示： 1）当服务端ready后，会和配置中心建立连接