Web请求异步处理降低应用依赖风险

Web请求异步处理降低应用依赖风险2011-08-14 infoq 岑文初问题凸现

年关到了，商家忙着促销，网站忙着推广，阿里软件的服务集成平台也面临第一次多方大规模的压力考验。根据该平台5.3版本的压力测试结果，我们估算了一下现有的推广会带来的压力，基本上确定了服务集成平台年底不需要扩容。SA（System Administrator，系统管理员）为了保险起见还是通过请求方式来做定时的心跳检测，保证服务集成平台的可靠性。结果阿里旺旺推广开始的第一天，SA的报警短信就在几个忙时段不停地发告警，但是查看生产环境的服务器状况以及应用状况后看不出有什么问题，于是开始怀疑是否告警机制不是很合理。几日的访问记录统计报告看过以后，发现了几个问题，首先由于推广是在 IM登录时段集中式的推广，因此高峰期比较集中，压力也很大，而告警发生的时刻也是那些时候；另外发现那些推广使用的API的处理时间比较长，同时还有些出现了问题，这几天除了服务集成平台告警以外，那些API服务器也在告警；因此可以看出问题应该是由于API提供商响应速度慢而拖累了服务集成平台的处理能力，监控机制在高峰情况下没有得到及时的响应，就认为是服务器已经处于无效状态。

其实这类问题在我们现在的应用体系架构中常常出现，原因是现在很少再有纯粹“封闭式”应用，对数据库的依赖，对存储的依赖，对第三方系统的依赖等等。这也让我回忆到在前一阵子参加的安全会议中，腾迅的安全技术团队的负责人说安全现在最大的问题就在于合作的第三方的安全不受控而引发的安全潜在影响。Web应用未尝不是，从最基本的事务处理要小粒度，不要在事务中包含第三方依赖，到心跳检测，容错方案的制定等，都已经让我们对这方面的问题有所注意。但是往往这类问题不是局部设计可以看到的，如果没有一个总体架构设计者对于全局的把握、协调和防范，那么问题出现并且带来的影响将会很大。

从前对于服务集成平台的压力测试主要是在ISP服务“基本正常”的情况下做的，但是这次问题的暴露就要求我们在第三方依赖出现边界问题时，及时做出一些措施或者改进设计。

问题分析以及解决方案

问题原因：

Http请求处理的阻塞方式。

后端服务处理时间过长，服务质量不稳定。

Web Container接受请求线程资源有限。

解决方案：

改阻塞方式为非阻塞方式来处理请求。

设置后端超时时间，主动断开连接，回收资源。

修改容器配置，增加线程池大小以及等待队列长度。

解决方案一是最难做到的，后面的篇幅将描述对于这方面技术的探索。

解决方案二比较容易，允许各个ISP设置自己API容许的最大超时时间。

解决方案三Tomcat和JBoss在Connector中有两个参数配置（maxThreads和acceptCount）可以做调整。