设计与开发应用服务器相关技术.doc

设计与开发应用效劳器二-相关技术效劳器的设计与开发涉及到诸多技术与问题，归纳一下大致可以分为以下几种：· 效劳器启动与接收数据过程· 多线程策略· NIO· 长连接· 同步与异步· 配置化支持· 责任链模式· 集群与负载均衡· 数据包设计· 效劳端连接协议· 客户端连接技术效劳器启动与数据请求过程 各种效劳器所提供的功能与实现机制都不尽一样，但在启动与数据请求这块都长得差不多，遵循固定的一些流程与模式，启动过程一般按一下流程：1以main方法的形式提供由外部脚本触发的入口2载入配置文件，解析并构建上下文3初始化各个组件与资源4注册与启动监控与管理组件5启动连接监听数据请求过程一般按一下流程：1侦听Socket2包装Connection3解析并包装数据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后，会与配置中心建立连接，把自身状态信息发送到配置中心2当客户端ready后，会与配置中心建立连接，把所需要效劳的相关信息与路由策略同步到本地3效劳端有变动时，比方有机器宕机或迁移，配置中心会感知，并把改动立刻同步到客户端4客户端依据本地的路由信息直接与效劳端通信这种机制的最大优点就是客户端与效劳端直接通信，消除了loadBalance单点，但也具有明显的缺点，也就是很难做到按照效劳器空闲情况进展很智能的均衡负载，并且效劳端的变动也很难立刻同步到客户端。一般有以下实现措施：1客户端、效劳端与配置中心彼此之间保持长连接，保障通信的即时性2路由策略以业务为维度，如按方法、接口或者参数来路由。或者就是简单的随机与轮询3通过配置中心做一些监控的工作，保障效劳端的可用性4在客户端做容错，比方连接不上效劳端效劳端状态同步延迟时，做重试处理数据包设计 Tomcat是基于 的效劳器，因此它接收与发送的数据都是基于 协议的。如果自己设计的效劳器不是基于 ，比方是原始的socket，那么就需要设计一套数据协议，例如：数据协议的设计关键在于简单方便并容易扩展，数据协议就是客户端与效劳器端交流的手段，功能越复杂数据协议就越复杂，数据包就会越来越大，因此在设计上需要有所权衡效劳端连接协议 当客户端多样化后就会有多种连接协议共存的需求，比方activeMQ与tomcat就支持多种connector，以activeMQ为例就支持 openwire、ssl、stomp、xmpp等不同协议。支持多种协议无非就是在连接模块多开启几个端口的监听与相应协议的解析，做得更好的话最好是 插件的模式，实现可插拔，这样就不会因为多种协议搞得整个系统实现过于复杂与混乱客户端连接技术 客户端连接方案可以有多种选择，如果支持 协议，可以使用jdk提供的 Client工具，也可以直接使用网页。如果是socket， 使用java net里TCP或UDP相关的类即可。这里需要提一下，最近看到很多人采用flash作为客户端来与效劳端通信，并取得很不错的效果，flash提供了这 么一些工具与API来支持网络连接与数据传送：· Flash Socket API：通过这类API，使ActionScript代码可以建立套接字连接并读取与写入原始的二进制数据，其没有指定接收或发送的数据格式。· External Interface API：通过这类API，可以实现javascript与actionscript之间的通信，当然这里还有平安沙箱的存在。· Shared Object API：通过这类API，可以实现在本地或效劳器上面存储数据。当数据保存在本地的时候，其默认的可以存储的数据是每个域名100K，其与cookie还是有很大的不同点的。· LocalConnection API：通过这类API，可以实现swf文件之间的通信，这种通信是可以跨浏览器的。以上API的具体使用可以参考一下Flash的文档，这里想说一下flash做为客户端的好处：· flash的通用性可以很方便地使客户端普及· flash可以很方便地实现跨域通信，不像js或ajax有那么多限制· flash可以借助Shared Object与LocalConnection实现浏览器之间的关联，并且是完全跨浏览器的。以上是一些开发与设计效劳常用到的技术或需要考虑的问题，在今后的学习深入中有待补充。第 7 页