浅谈web请求异步技术

1、一应用迁移及容器部署这次迁移主要的工作就是在服务框架的迁移，服务框架内部是小的osgi容 器，和当初在阿软做服务平台一样，当时是sca容器，道理都一样，如何打 通sca和osgi与应用服务器，主要涉及的就是classloader的互通。服务框架组的同学当时做过一个jetty的内置互通支持版本，其是修改了 jetty 的代码，在启动过程中植入了外部应用容器的初始化和循环互通。考虑到将 来jetty升级的方便，自己还是从新考虑做一个外部互通的支持版本。（期 间波折就不再此说了，大概说一两点关 键之处），首先是要启动外部容器, 由于jetty可以支持lifecycle的bean在jetty容器启动时

2、优先装载,因此夕卜 部容器就实现接口，在jetty的server配置中设置即可。然后需要将两个容 器互通（相互可以引用对方的服务接口），这需要在应用上下文构建的时 候相互关联两者的classloader, 种方式在server的appdeployer部署过程 中植入，一种在指定的appcontext部署中植入。这两种方式就是jetty支持 的两种模式,一种配置在etc目录下的jetty总配置文件中（server配置中）, 一种配置在contexts目录下（这种就是现在比较推崇的片段化部署），我选 择了后一种，因为对我來说不是所有应用都需要支持容器互通的，当丽只 有top这个应用。容器部署，je

3、tty真的是太干净了，首先类似于xml的解析实现没有（jdk可 只有框架接口） , iog4j没有，jndi需要另外引入插件支持,lib下的jetty插 件按需载入（在start.ini,start.config和启动脚本中口j指定），遥想当年的jboss 也应该是很干净，回顾今天的部署应用的jboss已经被贴了 n多膏约。因此 最终要的几个配置就是：启动脚本，etc下的jetty.xml（可以指定英他配置）, start.config （可以从jetty的jar包中获取出来自己指定和配置）,start.ini （启 动的默认配 置），contexts下的应用上下文配 置。容器部署和外部插件迁

4、移虽然不是异步化的工作，但是在异步化以前一定 要搞定，否则就无法谈到后续的应用迁移，总的來说jetty的模块化和扩展 做的很好，基本上任何步骤都能够替换和实现新的逻辑。（冇需要jetty配 置和hsf外部插件支持的同学可以直接找我）二.top管道化体系异步改造top的服务接入层就是由很多个管道切面组成的，流控，安全，业务校验， 路由，协议转换，响应格式转换等等，因此top自身很适合采用管道化流程 体系来构建，同时采用管道化体系构建能够简单的隔离业务逻辑，实现服务 降级，新功能beta发布。引入异步化概念后，对 于开发者其实不需要过多 了解，仅仅只需要配置异步化的管道，交出管道框架和容器协作来完

5、成异步 化的请求处理。这里顺带在捉一下上一篇屮说到的异步化的作用：差别化耦合系统的体系 设计，差别化流程中流程处理。异步化不会节省业务事务处理时间（反而会 增加），也不一定会提高系统可用性和稳定性（起码全局上来看，整体复 杂度增加，异常波及会被隔离，但是可能发现也较晚），也不一定会节省资 源（异步化往往是空间换时间，将业务状态独立于处理，提高处理 线程的 利用率，代价是增加了交互和存储的成本）。因此一直困扰top的服务分流和隔离可以通过异步化方式得以实现，方 式就是将系统处理和业务处理流程隔离，系统处理用少量线程就可以支持 大并发请求，同时将后续的业务处理交给业务工作池，而业务工作池的资源 分

6、配完全可以通过业务特征设置权重，也可以通过后台服务质量的反馈来自动调整，最终实现对服务使用者服务差别化，对不同质量的服务提供差别化的流量引入。同样和上一篇文章谈到的多种模式一样，改造支持两种模式，适合不同场 景。1. pull & check status & resume mode这种模式对于后端服务的要求较高，首先服务使用需要支持异步方式， 其次要求在完成服务后修改任务状态，而对于依赖方來说，会通过轮询的 方式去获取结果。流程图如下，不过第二个是第一个的改进，效果不错， 前者是检查所冇的任务状态，确定是否完成，放入任务的是前端系统，后 者是不需要检测任务状态，凡是获得任务，

7、即表示任务完成，放入任务的 是后端服务提供系统。2. push & complete mode这种模式下对于后端服务来说可以只捉供同步服务或者也支持异步服务， top-期改造采用这种模式，后端服务采用同步模式，具体测试结果参看后面 的测试部分。三测试场景：后台服务执行时间为1秒,no think time,容器为nginx+jetty并发用户数jetty连接池线 程数量业务线程池 线程数量loadtps200 （异步）2002000.8180400 （异步）2002000.7208200 （同步）2002001.16190400 （同步）2002001190200 （异步）200400

8、0.95195400 （异步）2004000.84390200 （同步）2004000.82195400 （同步）2004000.88195200 （同步）4004000.7174400 （同步）4004000.85350结论：tps还是取决于两个线程池的线程多少，在异步化后系统消耗并没有明显增加，容器连接池的放大和业务线程池的放大都可以提高处理效率，同时业务线程池较为轻量，容量翻倍处理基本也是翻倍，容器的线程池 放大处理能力会有衰减。场景：200并发用户，调用user.get服务,no think time,容器线程池400,业务线 程池500.结论：没有前段nginx对于数据缓冲处理，je

9、tty处理效率一般，因此需要假 设jetty作为前段预处理容器（必要的时候也可以作为反向代理）场景：200并发用户，调用user.get服务,no think time,容器线程池200,业务线 程池500.容器并发用户|请求处理模式tpsapache + jboss200同步507nginx + jetty200同步1060nginx + jetty200异步1027jetty200异步670结论：同步模式下apache+jboss与nginx+jetty相差很大的级别（load也相差一 倍多）。异步模式下的nginx+jetty与同步模式相差不大，因此异步带来的损耗 可 以忽略。没有nginx作为前端整体性能下降很大。场景:200并发用户,no think time,容器线程池200,业务线程池500.容器请求服务请求处理模式tpsnginx + jettytime.get1534nginx + jettyt