Web请求异步处理降低依赖风险
Author：文初
Email：[email protected]
Blog：http://blog.csdn.net/cenwenchu79
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" ?>
问题凸现：
年关到了，商家忙着促销，网站忙着推广，阿里软件的服务集成平台也面临第一次多方大规模的压力考验，根据5.3版本的压力测试结果，估算了一下现有的推广会带来的压力，基本上确定了服务集成平台年底不需要扩容。SA为了保险起见还是通过请求方式来做定时的心跳检测，保证服务集成平台的可靠性。结果旺旺推广开始的第一天，SA的报警短信就在几个忙时段不停的发告警，但是察看生产环境的服务器状况以及应用状况也看不出有什么问题，开始怀疑是否告警机制不是很合理。但几日的访问记录统计报告看过以后，发现了几个问题，首先由于推广是在IM登录时段集中式的推广，因此高峰期比较集中，压力也很大，而告警发生的也是那些时候，再则，发现那些推广使用的API的处理时间比较长，同时还有一些出现了问题，这几天除了服务集成平台告警以外，那些API服务器也在告警，因此可以看出问题应该是由于API提供商响应速度慢而拖累了服务集成平台的处理能力，监控机制在高峰情况下没有得到及时的响应，就认为是服务器已经处于无效状态。其实这类问题在我们现在的应用体系架构中常常出现，现在很少有纯粹“封闭式”应用，对DB的依赖，对存储的依赖，对第三方系统的依赖等等。这也让我回忆到就是前一阵子参加的安全会议中，腾迅的安全技术团队的负责人说起关于安全现在最大的问题就在于第三方合作安全的不受控而引发安全潜在影响。Web应用未尝不是，从最基本的事务处理要小粒度，不要包含第三方依赖到事务中，到心跳检测，容错方案的制定，都已经让我们对这方面的问题有所注意。但是往往这类问题不是局部设计可以看到的，如果没有一个总体架构设计者对于全局的把握以及协调和防范，那么问题出现并且带来的影响将会很大。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" ?>
早先对于服务集成平台的压力测试主要是在ISP服务“基本正常”的情况下做的，但是这次问题的暴露就要求我们对于这种第三方依赖出现边界问题需要做出一些措施或者改进的设计。
问题分析以及解决方案：
问题原因：
1． Http请求处理的阻塞方式。
2． 后端服务处理时间过长，服务质量不稳定。
3． Web Container接受请求线程资源有限。
解决方案：
1． 改阻塞方式为非阻塞方式处理请求。
2． 设置后端超时时间，主动断开连接，回收资源。
3． 修改容器配置，增加线程池大小以及等待队列长度。
解决方案一是最难做到的，后面的篇幅讲描述对于这方面技术的探索。
解决方案二比较容易，允许各个ISP设置自己API容许的最大超时时间。
解决方案三Tomcat，JBoss在Connector中有两个参数配置（maxThreads和acceptCount）可以做调整。
第一个方案其实和Jdk1.5支持的NIO就是一种想法，只是我们在Socket中都已经采用了，而在Http请求处理中要依赖于Web Container开发商的实现所以至今还没有被广泛应用，不过在开源社区已经有用Mina实现的Http协议处理的框架，但是现在的Web应用高效的Web请求处理仅仅是很小的一方面，还有很多类似于安全，缓存，监控等等附加功能也占据着很重要的地位。
Servlet 3规范经过快一年的推广，已经被各大Web Container厂商所接受，Tomcat6、JBoss5、Jetty7都宣称自己对Servlet3作了较好的支持，而在Servlet3中最广为关注的一个特性就是异步服务处理Servlet（Async Servlet），这点也是解决我目前面临问题的最好的手段。
Servlet 3 与服务异步处理：
Servlet 3主要的新特性分成四部分：内嵌式的使用模式，Annotation的支持，Async Servlet的支持，安全提升。内嵌式的使用很早就在Jetty中被实现，也成为Jetty的优势之一，Annotation也只能说是锦上添花的部分，安全暂时没有怎么用到，最关心的还是Async Servlet部分。Async Servlet到底是什么样的概念，这里就大致描述一下在Servlet3规范中的介绍：
1. 支持 Comet（彗星）。最早期Http请求就是无状态的请求和响应，所有的数据一次性在请求后返回给客户端由客户端渲染。后来发展到AJAX，页面的请求和渲染由全局变成了局部。而Comet适合事件驱动的 Web 应用和对交互性和实时性要求很强的应用，通过建立客户端和服务端的长连接通道，在一次请求后可以主动推送服务端数据的变更情况到客户端。长连接建立的策略有两种：Http Streaming和Http Long Polling。前者客户端打开一个单一的与服务器端的 HTTP 持久连接。服务器通过此连接把数据发送过来，客户端增量的处理它们。后者由客户端向服务器端发出请求并打开一个连接。这个连接只有在收到服务器端的数据之后才会关闭。服务器端发送完数据之后，就立即关闭连接。客户端则马上再打开一个新的连接，等待下一次的数据。
2. 支持Suspending a request。通过在ServletRequest中增加suspend,resume,complete将Http请求处理的block模式转变成为not block模式，同时支持对于状态的查询（suspend,resume,timeout）。
3. 请求处理过程中支持事件机制。响应也支持状态查询。
图 异步服务请求基本流程
现实中的异步服务处理：
Tomcat 的异步服务处理
这里使用的是Tomcat 6.0.14版本。在Tomcat中对于异步处理描述在Advanced IO中作了说明，主要分成两部分：Comet的支持和异步输出。
Comet的支持作用分成两部分：请求读数据的非阻塞，响应处理的异步执行。前者可以防止在大流量数据上传时在传输过程中信道空闲等待的资源浪费，后者用于在处理请求时，依赖于第三方或者本身处理比较耗时的情况下，悬挂起请求处理线程，提高请求处理能力，完成处理后异步输出结果。
Servlet不再是原来对于几个标准的Http请求类型的方法实现，而是对于事件响应的处理。Comet定义了4个基础的事件：
1．EventType.BEGIN：客户端建立起连接时激发的事件，可以用于资源初始化。
2．EventType.READ：有数据可以被读入的事件。（熟悉NIO的事件模式应该可以了解）
3．EventType.END：请求处理结束时激发的事件，可以用于资源清理。
4．EventType.ERROR：当请求处理出现问题时激发的事件。（IO异常，超时等）
还有一些子事件类型，例如超时就属于ERROR的子事件类型，可以在事件处理中更加精确的定位事件类型。
必需的配置：在server.xml中配置如下（红色部分）：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" />
实际代码范例如下：
//CometProcessor接口必需被实现，一旦实现以后，则该Servlet在配置好以后不会再调用service,get,post等方法的实现。
public class SIPCometTomcatServlet extends HttpServlet implements CometProcessor
{
@Override
//事件处理响应方法实现
public void event(CometEvent event) throws IOException, ServletException
{
if (event.getEventType() == CometEvent.EventType.BEGIN)
{
//设置事件超时时间
event.setTimeout(10 * 1000);
//另起线程处理后台工作，异步返回结果，事件响应将不等待后台处理直接返回
new Handler(event.getHttpServletRequest(),event.getHttpServletResponse()).start();
}
else if (event.getEventType() == CometEvent.EventType.ERROR)
{
//结束事件，回收request,response资源
event.close();
}
else if (event.getEventType() == CometEvent.EventType.END)
{
event.close();
}
}
//另起一个线程异步处理请求。
class Handler extends java.lang.Thread
{
private HttpServletResponse response;
private HttpServletRequest request;
public Handler(HttpServletRequest request,HttpServletResponse response)
{
this.response = response;
this.request = request;
}
@Override