`
agapple
  • 浏览: 1583776 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

(业务层)异步并行加载技术分析和设计

阅读更多

背景

   前段时间在做应用的性能优化时,分析了下整体请求,profile看到90%的时间更多的是一些外部服务的I/O等待,cpu利用率其实不高,在10%以下。 单次请求的响应时间在50ms左右,所以tps也不会太高,测试环境压力测试过程,受限于环境因素撑死只能到200tps,20并发下。

 

I/O

目前一般的I/O的访问速度: L1 > L2 > memory -> disk or network
 
常见的IO: 
  1. nas上文件 (共享文件存储)
  2. output/xxx (磁盘文件)
  3. memcache client /  cat client  (cache服务)
  4. database (oracle , mysql)  (数据库)
  5. dubbo client  (外部服务)
  6. search client (搜索引擎)

思路

 

正因为考虑到I/O阻塞,长的外部环境单个请求处理基本都是在几十ms,刚开始的第一个思路是页面做ajax处理。 

 

使用ajax的几个缺陷:

 

  1. 功能代码需进行重构,按照页面需求进行分块处理。 一次ajax请求返回一块的页面数据
  2. 数据重复请求。因为代码是分块,两次ajax中获取的member对象等,可能就没法共用,会造成重复请求。
  3. ajax加载对seo不优化,公司还是比较注重seo,因为这会给客户带来流量价值,而且是免费的流量。
  4. ajax技术本身存在一些磕磕碰碰的点: 跨域问题,返回数据问题,超时处理等。
  5. ajax处理需要有嵌入性,每个开发都需要按照ajax特有的规范或者机制进行编码,有一定的约束

顺着ajax的思路,是否有一种方式可以很好的解决I/O阻塞,并且又尽量的透明化,也不存在ajax如上的一些问题。 

 

所以就有了本文的异步并行加载机制的研究。原理其实和ajax的有点类似: 

 

 

一般ajax的请求: 

 

  • request就代表html页面的一次渲染过程
  • 首先给页面的一块区域渲染一块空的div id=A内容和一块div id=B的内容
  • 浏览器继续渲染页面的其他内容
  • 在页面底部执行具体的js时,发起div id=A的请求,等A返回后填充对应的div内容,发起div id=B的请求,返回后同样填充。

说明:不同浏览器有不同的机制,默认执行js都是串行处理。

 

看一下异步并行机制的设计时序图: 

说明: 结合ajax的思路,异步并行加载机制在原理设计上有点不同,就是针对ajax的请求发起都是并行的。 

引入的问题:

   但同样,引入并行加载的设计后,需要考虑的一个点就是如果A和B的数据之间是有一定的依赖关系时怎么处理。 

   例子

if(modelA.isOk()){//先依赖modelA的请求
    modelB.getXXX()
}

 

解释下依赖关系,帖子中很多人理解上有一些偏差。

 

   B服务依赖A,指B服务的请求发起或者请求参数,取决于A的返回的结果。 那假定这个A返回结果是一个pojo bean,那依赖结果的概念是指依赖bean具体的属性。因为你直接依赖A,那只能是if(modelA == null)这样的一种关系, 一般更多情况是说我要看下if(modelA.level = 'PM') 

 

 

一种解决思路:

 

    半自动化处理。 任何异步并行加载的时机点,全都取决于代码编写的顺序。 如果有依赖关系的存在,比如例子中的B依赖A的结果,则B会阻塞等待至A的结果返回,最后A和B的处理就又回归到一个有顺序序的请求处理。

 

 

 

 

最后从技术实现上看: 
  从技术实现上说,在调用serviceA获取结果的时,我会直接返回一个假的LazyLoad产生的mock对象。此时对应的属性值全为null,在你具体依赖到该modelA的属性数据时,就会有一个阻塞等待,转为串行的过程。 

 

例子:

 

ModelA modelA = serviceA.getModel(); //1. 异步发起请求
ModelB modelB = serviceB.getModel(); //2. 异步发起请求
// 3. 此时serviceA和serviceB都在各自并行的加载model
if(modelA.isOk()){//4. 此时依赖了modelA的结果,阻塞等待modeA的异步请求的返回
    ModelC modelC = servicec.getModel(); //5. 异步发起请求
}
// 6.  此时serviceB和serviceC都在各自并行的加载model
......
modelB.xxxx() //7. 数据处理,modelB已经异步加载完成,此时不会阻塞等结果了
modelC.xxxx() //8. 数据处理,modelB已经异步加载完成,此时不会阻塞等结果了

 

来看个对比图: 


很明显,一次request请求总的响应时间就等于最长的依赖关系请求链的相应时间。 

 

(业务层)异步并行机制的优点:

  1. 继承了ajax异步加载的优点
  2. 增加了并行加载的特性

相比于ajax的其他优势:

  1. 同时不会对页面seo有任何的影响,页面输出时都是一次性输出html页面
  2. 减少了ajax异步发起的http请求
  3. 两块代码的资源不会存在重复请求,允许进行资源共享
从目前来看,异步并行机制还是有比较大的应用场景。具体是否能做到对一线开发者透明,以及对应业务的开发成本,那就得看一下具体的代码实现

实现

根据以上分析,分析核心模型:


 说明:
  1. 原本服务service。 这个不用多解释,就是原本存在的一些需要被代理的对象,比如DAO,rpc调用客户端等。
  2. 代理参数设置。 比如设置一些超时时间等
  3. 并行执行容器。 一个多线程处理的容器,执行并行加载
  4. 代理服务。  对服务service的一个包装过后的代理对象
  5. 代理服务Model 。  代理对象根据客户端的一些请求返回对应的代理Model,用于代理控制。
具体的类图设计:


 
说明: 
  1. AsyncLoadProxy就是模型中对应的代理服务
  2. AsyncLoadConfig就是模型中对应的代理参数设置
  3. AsyncLoadExecutor就是模型中对应的并行执行容器。
一些技术描述:
  • AsyncLoadEnhanceProxy是目前代理服务的一种技术实现,基于cglib的动态代理。后续可以研究下javassist技术,据说性能上比cglib要高。
  • AsyncLoadMethodMatch是针对参数设置的一个细化,类似于spring的aop的切面点(PointCut)的概念,在具体的切面上执行异步并行加载机制。
  • AsyncLoadExecutor目前是采用了jdk1.5中cocurrent包的pool池技术。支持两个队列设置:running队列,就绪队列。 针对就绪队列满了后,提供REJECT(拒绝后续请求)/BLOCK(阻塞等待队列有空位置)两种处理模式。

一个使用例子: 
// 初始化config
AsyncLoadConfig config = new AsyncLoadConfig(3 * 1000l);
// 初始化executor
AsyncLoadExecutor executor = new AsyncLoadExecutor(10, 100);
executor.initital();
// 初始化proxy
AsyncLoadEnhanceProxy<AsyncLoadTestService> proxy = new AsyncLoadEnhanceProxy<AsyncLoadTestService>();
proxy.setService(asyncLoadTestService);
proxy.setConfig(config);
proxy.setExecutor(executor);
// 执行测试
AsyncLoadTestService service = proxy.getProxy();
AsyncLoadTestModel model1 = service.getRemoteModel("first", 1000); // 每个请求sleep 1000ms
AsyncLoadTestModel model2 = service.getRemoteModel("two", 1000); // 每个请求sleep 1000ms
AsyncLoadTestModel model3 = service.getRemoteModel("three", 1000); // 每个请求sleep 1000ms

long start = 0, end = 0;
start = System.currentTimeMillis();
System.out.println(model1.getDetail());
end = System.currentTimeMillis();
want.number(end - start).greaterThan(500l); // 第一次会阻塞, 响应时间会在1000ms左右

start = System.currentTimeMillis();
System.out.println(model2.getDetail());
end = System.currentTimeMillis();
want.number(end - start).lessThan(500l); // 第二次不会阻塞,因为第一个已经阻塞了1000ms,并行加载已经完成

start = System.currentTimeMillis();
System.out.println(model3.getDetail());
end = System.currentTimeMillis();
want.number(end - start).lessThan(500l); // 第三次也不会阻塞,因为第一个已经阻塞了1000ms,并行加载已经完成
// 销毁executor
executor.destory();
 

一些扩展

   因为目前大家都比较喜欢于spring的ioc,aop等一些配置方式,类似于编程式事务和声明式事务。为方便以后使用,做了下扩展。
 

扩展一:AsyncLoadFactoryBean

类似于spring的ProxyFactoryBean的概念,基于spring FactoryBean接口实现。

 

配置事例:

 

<!-- 并行加载容器-->
<bean id="asyncLoadExecutor" class="com.alibaba.tpolps.common.asyncload.AsyncLoadExecutor" init-method="initital" destroy-method="destory">
	<property name="poolSize" value="10" /> <!-- 并行线程数 -->
	<property name="acceptCount" value="100" /> <!-- 就绪队列长度 -->
	<property name="mode" value="REJECT" />  <!-- 就绪队列满了以后的处理模式 -->
</bean>
<bean id="asyncLoadMethodMatch" class="com.alibaba.tpolps.common.asyncload.impl.AsyncLoadPerl5RegexpMethodMatcher" >
	<property name="patterns">
		<list>
			<value>(.*)RemoteModel(.*)</value> 
		</list>
	</property>
	<property name="excludedPatterns"> <!-- 排除匹配方法 -->
		<list>
			<value>(.*)listRemoteModel(.*)</value>
		</list>
	</property>
	<property name="excludeOveride" value="false" />
</bean>
<bean id="asyncLoadConfig" class="com.alibaba.tpolps.common.asyncload.AsyncLoadConfig">
	<property name="defaultTimeout" value="3000" />
	<property name="matches">
		<map>
			<entry key-ref="asyncLoadMethodMatch" value="2000" /> <!-- 针对每个match设置超时时间 -->
		</map>
	</property>
</bean>
<!-- 异步加载模FactoryBean -->
<bean id="asyncLoadTestFactoryBean" class="com.alibaba.tpolps.common.asyncload.impl.spring.AsyncLoadFactoryBean">
	<property name="target">
		<ref bean="asyncLoadTestService" /> <!-- 指定具体的服务 -->
	</property>
	<property name="executor" ref="asyncLoadExecutor" />
	<property name="config" ref="asyncLoadConfig" />
</bean>
 
思考: 后续可考虑,基于通配符拦截对应的目标service。
 

扩展二: AsyncLoadTemplate

基于模板模式,提供异步并行机制。可以编程方式指定进行异步并行加载的执行单元。 比如针对好几个service的调用合并为一次并行加载。

事例代码:

 

AsyncLoadTestModel model2 = asyncLoadTemplate.execute(new AsyncLoadCallback<AsyncLoadTestModel>() {

    @Override
    public AsyncLoadTestModel doAsyncLoad() {
        // 总共sleep 2000ms
        return asyncLoadTestService.getRemoteModel("ljhtest", 1000);
    }
});
System.out.println(model2.getDetail());

 

 

思考

 

  1. 基于cglib的技术局限,存在一些限制。比如final类,java原始类型等不支持异步并行。一点技术局限性
  2. 并行加载机制不适合于cpu密集性的应用,针对I/O密集型的应用效果会比较明显,设置好对应的并行加载容器。具体参数需要细细斟酌,进行相关的压力测试和分析。
  3. 对开发的一个嵌入性,需要考虑对应的Timeout机制,比如异常处理等。同样,我们也可以设置没有timeout(个人不太建议)

最后

具体的代码可以访问:  https://github.com/agapple/asyncload

 

 

 

ps : 大家有兴趣或者有更好的一些想法,可以一起讨论下。 至于其他语言的异步并行加载方案也可以一并讨论下,小成本大收益,何乐而不为呢!

 

 

 

说明一下:(2月24号新增的内容)

 

设计的初衷是追求尽量少的嵌入性,尽可能的对业务开发透明。所以会采用字节码增强的方式进行处理。

 

最理想的情况:

1. 普通开发人员完成业务编码开发,按照正常的方式,不需要关心异步加载这一套。

2. 最后项目的技术经理或者架构师,配置一份xml,决定哪些service的哪几个方法要进行异步并行加载。

3. 项目进入提测,回归测试等。

  • 大小: 7.9 KB
  • 大小: 3.5 KB
  • 大小: 12.9 KB
  • 大小: 79.9 KB
分享到:
评论
32 楼 cljhyjs 2011-02-24  
agapple 写道
cljhyjs 写道
LZ的想法很有创意,但是考虑到如果把这块功能抽象,采用类似拦截机制的方法在业务服务层做封装,可能需要考虑的问题会很多。 毕竟抽象层无法判断各个方法之间的依赖关系,即使采用显式的等待方式,可能也会增加程序的复杂度,或者实现封装代码块的复杂度。
   建议采用半自动化方式,由开发人员自己决定是否将方法投入到异步并行的容器中。就像spring中的ECcache、jbosscache配置使用一样。


这个你可以看看主文中的代码例子。

因底层技术是采用字节码增强方式,包括service和model都会织入一定的代码,具体开发者是感觉不到的。就和正常的写代码是一样的方式,至于依赖关系的串行处理,也是植入代码内部的。

原先设计的理念就是尽量做到无嵌入,对开发透明。

理想的情况就是普通开发人员完成业务编码开发后,由项目的技术经理或者架构师,配置一份xml,决定哪些service的哪几个方法要进行异步并行加载。


这也是一种方法,何必不让开发者自己在applicationContext.xml中配置,决定哪些service以及方法需要异步并行加载呢?
31 楼 agapple 2011-02-24  
cljhyjs 写道
LZ的想法很有创意,但是考虑到如果把这块功能抽象,采用类似拦截机制的方法在业务服务层做封装,可能需要考虑的问题会很多。 毕竟抽象层无法判断各个方法之间的依赖关系,即使采用显式的等待方式,可能也会增加程序的复杂度,或者实现封装代码块的复杂度。
   建议采用半自动化方式,由开发人员自己决定是否将方法投入到异步并行的容器中。就像spring中的ECcache、jbosscache配置使用一样。


这个你可以看看主文中的代码例子。

因底层技术是采用字节码增强方式,包括service和model都会织入一定的代码,具体开发者是感觉不到的。就和正常的写代码是一样的方式,至于依赖关系的串行处理,也是植入代码内部的。

原先设计的理念就是尽量做到无嵌入,对开发透明。

理想的情况就是普通开发人员完成业务编码开发后,由项目的技术经理或者架构师,配置一份xml,决定哪些service的哪几个方法要进行异步并行加载。
30 楼 agapple 2011-02-24  
tutu1982 写道
其实我说的自动识别依赖关系不是指

if(modelA.getXX()){ 
    modelB = serviceB.getModelB(); 
}

这一个逻辑块,我关心的是如何能够动态识别得到if(?){}这个逻辑,这个逻辑才是服务接口间的依赖关系的表达,如果这个逻辑需要手写的话,那对开发人员的编码思维是强侵入的。


主要看你这个依赖是怎么定义了。

比如有这么一个登录的业务,首先验证帐号密码,在密码验证通过后,我需要更新一下群发消息通知一下别人。

这么一个需求,正常的编码也肯定会是
if(modelA.isLoginSuccess()){
  modelB  = serviceB.sendMessage()
}

这是一个业务,肯定需要开发人员进行编码,如果想单纯的依赖配置文件,我觉得反而对老系统有嵌入性了。
目前的想法,就是老的逻辑代码怎么写,加了异步加载后代码逻辑尽量都保持一致。

同样异步并行加载会存在一定技术上的难以规避的问题,比如如果直接使用modelA == null进行判断,因为异步返回的是一个假的,具体结果目前无法控制。

29 楼 cljhyjs 2011-02-24  
tutu1982 写道
其实我说的自动识别依赖关系不是指

if(modelA.getXX()){ 
    modelB = serviceB.getModelB(); 
}

这一个逻辑块,我关心的是如何能够动态识别得到if(?){}这个逻辑,这个逻辑才是服务接口间的依赖关系的表达,如果这个逻辑需要手写的话,那对开发人员的编码思维是强侵入的。



这个想法有挑战性。。。
28 楼 tutu1982 2011-02-24  
其实我说的自动识别依赖关系不是指

if(modelA.getXX()){ 
    modelB = serviceB.getModelB(); 
}

这一个逻辑块,我关心的是如何能够动态识别得到if(?){}这个逻辑,这个逻辑才是服务接口间的依赖关系的表达,如果这个逻辑需要手写的话,那对开发人员的编码思维是强侵入的。
27 楼 cljhyjs 2011-02-24  
LZ的想法很有创意,但是考虑到如果把这块功能抽象,采用类似拦截机制的方法在业务服务层做封装,可能需要考虑的问题会很多。 毕竟抽象层无法判断各个方法之间的依赖关系,即使采用显式的等待方式,可能也会增加程序的复杂度,或者实现封装代码块的复杂度。
   建议采用半自动化方式,由开发人员自己决定是否将方法投入到异步并行的容器中。就像spring中的ECcache、jbosscache配置使用一样。
26 楼 agapple 2011-02-24  
cljhyjs 写道
LZ说的问题是实现业务的代码块,通常都是用串行的写法,即:
function test(){
   A.call(**);
   B.call(**);
}

如果这两个方法的调用没有依赖关系,那就可以采用异步并行处理的方法。缩短方法test()的执行所需要的时间,提升CPU的利用率。该方法所需要执行时间为:max(A.call(),B.call());

当然如果这两个方法有前后的依赖关系,那还得采用这种串行执行的方法。该方法所需要执行时间为:max(A.call()+B.call());



理解比较到位,:D

目前是否需要串行处理是透明处理,对具体写业务代码可以没有嵌入。 技术实现可以看下code,采用cglib字节码动态处理

示例代码: AsyncLoadFactoryBeanTest.java
25 楼 cljhyjs 2011-02-24  
LZ说的问题是实现业务的代码块,通常都是用串行的写法,即:
function test(){
   A.call(**);
   B.call(**);
}

如果这两个方法的调用没有依赖关系,那就可以采用异步并行处理的方法。缩短方法test()的执行所需要的时间,提升CPU的利用率。该方法所需要执行时间为:max(A.call(),B.call());

当然如果这两个方法有前后的依赖关系,那还得采用这种串行执行的方法。该方法所需要执行时间为:max(A.call()+B.call());

24 楼 agapple 2011-02-23  
tutu1982 写道
不是很明白LZ说的自动识别依赖的方式。

如果业务开发人员写出的业务逻辑中调用比较多的服务接口,除非这些服务接口都按照某种统一的编码规范进行处理,不然很难从方法内部分析出依赖关系来。

但不知道通过分析堆栈轨迹或者字节码等方式能否得到相应的效果。

AllenZhang:
timeout这一块我觉得可以通过一个统一的事务管理器来控制,不用每个方法都关注


其实你可以思考下一般有依赖关系的代码会怎么写。
比如:
if(modelA.getXX()){
    modelB = serviceB.getModelB();
}


你可以在modelA.getXX()方法植入代码,进行相应的控制,说白了等待A的结果返回。:) 
23 楼 tutu1982 2011-02-23  
不是很明白LZ说的自动识别依赖的方式。

如果业务开发人员写出的业务逻辑中调用比较多的服务接口,除非这些服务接口都按照某种统一的编码规范进行处理,不然很难从方法内部分析出依赖关系来。

但不知道通过分析堆栈轨迹或者字节码等方式能否得到相应的效果。

AllenZhang:
timeout这一块我觉得可以通过一个统一的事务管理器来控制,不用每个方法都关注
22 楼 agapple 2011-02-23  
AllenZhang 写道
最关键的问题是:
事实上如果不参看客户端代码,要如何自动识别依赖?
这一点还需要和timeout一起考虑。方法之间是否依赖可能会随着时间变化。


一种lazy的检查机制,你要依赖,必然会操作对应的model内的属性。这时机上可以植入相应的控制代码
21 楼 AllenZhang 2011-02-23  
最关键的问题是:
事实上如果不参看客户端代码,要如何自动识别依赖?
这一点还需要和timeout一起考虑。方法之间是否依赖可能会随着时间变化。
20 楼 agapple 2011-02-23  
tutu1982 写道
嗯,半自动确实能解决,但这样就给业务开发人员带来了一定的负担,我一直在思考能否对业务开发人员做到全透明


现在已经基本透明了阿,开发在代码层面上不会感觉到任何AsyncLoad代码的存在。

半自动只是在我后端程序上的实现,会自动识别依赖并走串行处理。 对于开发来说,就和正常的写代码是一样的
19 楼 tutu1982 2011-02-23  
嗯,半自动确实能解决,但这样就给业务开发人员带来了一定的负担,我一直在思考能否对业务开发人员做到全透明
18 楼 agapple 2011-02-23  
tutu1982 写道
页面的几个调用有业务上的先后顺序,通过并行处理的话可能会乱序,这个方面你怎么考虑的



主文档中,已经有提到。

=============================
引入的问题:
   但同样,引入并行加载的设计后,需要考虑的一个点就是如果A和B的数据之间是有一定的依赖关系时怎么处理。
   例子
Java代码
if(modelA.isOk()){//先依赖modelA的请求 
    modelB.getXXX() 


一种解决方案: 半自动化处理。 任何异步并行加载的时机点,全都取决于代码编写的顺序。 如果有依赖关系的存在,比如例子中的B依赖A的结果,则B会阻塞等待至A的结果返回。 A和B的处理就又回归到一个有顺序序的请求处理
17 楼 agapple 2011-02-23  
donglee 写道
我做过类似的一个实现,是做接口服务调用,
主要是用jdk并发包中的BlockingQueue和Future机制,
基本是按生产者-消费者模型,有一个线程会执行定时任务,检测Future是否拿到结果,和你的modelA.isOk())作用应该类似。



理念上貌似有所不同吧,isOk()这是我随意写的一个内容。整套机制目前是无嵌入性,不需要应用代码实现任何接口或者啥的。

不存在一个定时任务去检查。 而是在你的model想要进行一个getXXX()方法调用时,再去检查future的结果(已拿到就直接返回,没拿到就阻塞), 所以这时的检查是一个lazy的过程。
16 楼 donglee 2011-02-23  
大任务包含分支任务分解,可以参考下fork/join并行分解模型
15 楼 donglee 2011-02-23  
我做过类似的一个实现,是做接口服务调用,
主要是用jdk并发包中的BlockingQueue和Future机制,
基本是按生产者-消费者模型,有一个线程会执行定时任务,检测Future是否拿到结果,和你的modelA.isOk())作用应该类似。
14 楼 tutu1982 2011-02-23  
页面的几个调用有业务上的先后顺序,通过并行处理的话可能会乱序,这个方面你怎么考虑的
13 楼 agapple 2011-02-23  
opal 写道
ModelA modelA = serviceA.getModel(); 
ModelB modelB = serviceB.getModel(modelA.getResult()); 
ModelC modelC = serviceC.getModel(modelB.getResult()); 


这种情况????


针对这种情况,就回归到最原始的串行请求了,因为所有的服务处于一条的依赖关系链中。

总的请求的响应时间等于依赖关系链的所有服务请求之后。

新的例子:
ModelA modelA = serviceA.getModel(); 
ModelD modelD = serviceD.getModel();  //加入多这么一次请求
ModelB modelB = serviceB.getModel(modelA.getResult()); 
ModelC modelC = serviceC.getModel(modelB.getResult()); 


加入多了一次modelD的请求,这个请求的响应时间就可以被“挤“出来了,最后总的响应时间就=max(serviceD , serviceA+serviceB+serviceC);

因为我们的代码开发,存在很多的情况就是调用服务取到了结果,并不立即去使用,这样就有一定的提升空间了

相关推荐

Global site tag (gtag.js) - Google Analytics