UOP设计思想之异步处理

在WEB/WAP这种以http协议为主的大用户应用中,即时性是非常重要的一个指标.客户端对一个
请求的响应时间的感受,可以说是衡量大规模用户的WEB应用的第一指标.
适时地采用异步处理,不仅可以提高对客户端的响应速度,而且使交互过程更为可靠!

如果有些事我们不得不做,那就要看在什么时候做,让谁做更合适.软件设计中,我们总是把最难
实现的部分让API提供者来做.事实上让调用者来做和让API提供者来做,在整个流程中这个工作(最终会变
成CPU执行的指令序列)是无法缩减的,但放在最适合的地方,就使你的整个架构非常优雅.

同样,如果在一次请求响应中一段逻辑必须执行,除非用户要看到它的即时效果,否则你不应该
让它在交互过程中完成.所以异步调是一个非常好的解决方案.

象一些耗时的"后台操作",我们可以在当前应答处理中另外启动一个线程,而把用户最想看到的
内容即时反馈给用户.比如用户点击某一页面,要发一封信给某人.我们可以把发信的过程在新的线程中执
行,而当前响应的线程中告诉用户"已经成功发送信件给某人",这样真正发信要多久,并不影响用户看到这
个提示.
事实上对于"发信"这种动作,用户不可能即时知道结果,即使你的SMTP是101%的发送成功,但邮件
在网络中路由,以及收信方的邮件服务器的可靠都不是你能控制的,所以只要你"告诉用户信件已经发送"就
足够了,你不可能告诉他"信件已经成功被对方接收",万一那个新线程不知道什么不太可能的原因死了,用
户也无法追究你的提示是否可靠.

UOP思想的核心就是无论你如何实现,给用户以最好的感受是根本目的.其它的都只是手段.
异步调用不仅仅是提高交互的响应速度,而且是提高可靠性的手段.
无论如何你都无法保证"发信"这样的动作能100%连结到SMTP的服务器,如果不能连结,至少要超等
时以后才会继续执行,而此时往往发生异常.也就是用户在等待了超时的时候后还是看到出错的信息,这种
感受对你的应用威胁是致命的,所以如果在用户不可见线程中处理这个过程,用户就无法觉察.
很多例子是我们在处理一个请求时,要连结另一个URL或数据库,如果不是通过这些资源获取内容
向用户输出必要的信息,我们就没有必要在当前线程中处理,因为一旦你要连结的URL或数据库不能连结,在
等待很久后最终还是抛出异常.

我经常用的方案是把要处理的对象放到一个static的数据结构中,在正常的响应逻辑比如Servlet
的service方法中,只要把这个对象put到这个数据结构中就足够了,然后service方法继续执行与用户交互相
关的事,而后台启动专门的Listener来处理这些数据,这样即使这个Listener出现任何阻塞或异常,用户也是
不可知的.这种方案对于触发日志,通知等后台操作的处理非常合适.不仅仅加强交互界面的友好性,而且你
的架构逻辑结构也非常清析合理.

我经常用到的编程习惯是不在主要逻辑中实现具体方法.比如一个service方法,它要处理若干步骤.
如果有300行以上的代码,你的这个响应看起来就不够清析了.我一直是这样做:


publicvoidservice(argList.....){
step1();
step2();
step3();
step4();
step5();
........

}

privatevoidstep1(){
//具体操作
}
privatevoidstep2(){
//具体操作
}
privatevoidstep3(){
//具体操作
}
privatevoidstep4(){
//具体操作
}
privatevoidstep5(){
//具体操作
}

其他的如果要看你的这个逻辑过程,最先肯定要看service方法,只有简单几行,清楚地告诉他整个
过程要干什么.至于如何他可以看下面具体的实现.


事实上,异步处理本身正好就是这种编程习惯的一个扩展.既然它能提高用户交互的速度和保证交
互的可靠,又使你的结构如此优雅,那么,适时地使用异步处理吧!