浅谈Web请求异步技实孽.docVIP

一． 这次迁移主要的工作就是在服务框 架的迁移，服务框架内部是小的OSGI容器，和当初在阿软做服务平台一样，当时是SCA容器，道理都一样，如何打通SCA和OSGI与应用服务器，主要涉及的就是ClassLoader的互通。 服务框架组的同学当时做过一个Jetty的内置互通支持版本，其是修改了Jetty的代码，在启动过程中植入了外部应用容器的初始化和循环互通。考虑到将来Jetty升级的方便，自己还是从新考虑做一个外部互通的支持版本。（期间波折就不再此说了，大概说一两点关 键之处），首先是要启动外部容器，由于Jetty可以支持LifeCycle的Bean在Jetty容器启动时优先装载，因此外部容器就实现接口，在Jetty的Server配置中设置即可。然后需要将两个容器互通（相互可以引用对方的服务接口），这需要在应用上下文构建的 时候相互关联两者的classLoader，一种方式在Server的AppDeployer部署过程中植入，一种在指定的AppContext部署中植入。这两种方式就是Jetty支持的两种模式，一种配置在etc目录下的jetty总配置文件中（Server配置中），一种配置在contexts目录下（这种就是现在比较推崇的片段化部署），我选择了后一种，因为对我来说不是所有应用都需要支持 容器互通的，当前只有TOP这个应用。 容器部署，Jetty真的是太干净了，首先类似于xml的解析实现没有（jdk可只有框架接口），log4j没有，jndi需要另外引入插件支持，lib下的jetty插件按需载入（在start.ini,start.config和启动脚本中可指定），遥想当年的jboss也应该是很干净，回顾今天的部署应用的jboss已经被贴了N多膏药。因此最终要的几个配置就是：启动脚本，etc下的jetty.xml(可以指定其他配 置)，start.config (可以从jetty的jar包中获取出来自己指定和配置)，start.ini（启动的默认配 置），contexts下的应用上下文配 置。 容器部署和外部插件迁移虽然不是 异步化的工作，但是在异步化以前一定要搞定，否则就无法谈到后续的应用迁移，总的来说jetty的模块化和扩展做的很好，基本上任何步骤都能够替换和实现新的逻辑。（有需要jetty配置和hsf外部插件支持的同学可以直接找我） ? 二．TOP TOP的服务接入层就是由很多个管道切面组成的，流控，安全，业务校验，路由，协议转换，响应格式转换等等，因此TOP自身很适合采用管道化流程体系来构建，同时采用管道化体系构建能够简单的隔离业务逻辑，实现服务降 级，新功能beta发布。引入异步化概念后，对 于开发者其实不需要过多了解，仅仅只需要配置异步化的管道，交由管道框架和容器协作来完成异步化的请求处理。 这里顺带在提一下上一篇中说到的 异步化的作用：差别化耦合系统的体系设计，差别化流程中流程处理。异步化不会节省业务事务处理时间（反而会增加），也不一定会提高系统可用性和稳定性（起 码全局上来看，整体复杂度增加，异常波及会被隔离，但是可能发现也较晚），也不一定会节省资源（异步化往往是空间换时间，将业务状态独立于处理，提高处理 线程的利用率，代价是增加了交互和存储的成本）。 因此一直困扰TOP的服务分流和隔离可以通过异步化方式得以实现，方式就是将系统处理和业务 处理流程隔离，系统处理用少量线程就可以支持大并发请求，同时将后续的业务处理交给业务工作池，而业务工作池的资源分配完全可以通过业务特征设置权重，也 可以通过后台服务质量的反馈来自动调整，最终实现对服务使用者服务差别化，对不同质量的服务提供差别化的流量引入。 ? 同样和上一篇文章谈到的多种模式 一样，改造支持两种模式，适合不同场景。 1.?????? Pull Check Status Resume Mode 这种模式对于后端服务的要求较高，首先服务使用需要支持异步方式，其次要求在完成服务后修改任务状态，而对于依赖方来说，会通过轮询的方式去获 取结果。流程图如下，不过第二个是第一个的改进，效果不错，前者是检查所有的任务状态，确定是否完成，放入任务的是前端系统，后者是不需要检测任务状态， 凡是获得任务，即表示任务完成，放入任务的是后端服务提供系统。 ? ???????????????????????????????????????????????? ? ? ? ? ? 2.?????? Push Complete Mode 这 种模式下对于后端服务来说可以只提供同步服务或者也支持异步服务，TOP一期改造采用这种模式，后端服务采用同步模式，具体测试结果参看后面的测试部分。 ? ? ? ? ? 三． ? 场景： ???????? 后台服务执行时间为1秒，no think ti