SEDA

1.Overview

     SEDA(Staged Event-Driven Architecture)的核心思想是把一个请求处理过程分成几个Stag,不同资源消耗的Stag使用不同数量的线程来处理,Stag间使用事件驱动的异步通信模式。

     更进一步,在每个Stage中可以动态配置自己的线程数,在超载时降级运行(如输出纯文字页面)或拒绝服务。

     在每个Stage的通常有如下组件:

  • Incoming Event Queue ,事件队列。
  • Admission Controller  阀门,拒绝服务。
  • Dynamically sized Thread Pool, 线程池。
  • Event Handler ,实际处理业务的Compinent。
  • Resource Controller ,控制Stage的参数。

2.Web2.0+SOA环境下的SEDA应用

    Web2.0对架构师提出了新的挑战 ,  JavaEE 的同步调用机制(除JMS),有限的线程池与连接池(超出范围性能会下降),固定的定义在JNDI的资源对Web2.0/SOA的需求并不吻合。对BEEP,SCTP这些协议,必须依靠JCA另行编写模块来实现长连接模型。

    Java EE 迎合 Web 2.0(IBM DW) 提出,从统计学上看在系统总线程数固定的情况下,使用SEDA能获得较高的Throughput,阶段间的资源差异越大就越明显。
    比如处理一个Web 2.0常用Mashup请求,有如下几步:

  1. 接收用户请求(1单位时间)
  2. 数据库查询(4单位时间)
  3. 根据数据库查询结果,准备Web Service调用参数(1单位时间)
  4. 发起Web Service调用((16单位时间))
  5. 将结果渲染返回给用户(2单位时间)
       

     那么SEDA会使用一条线程处理1.接收用户请求、3.准备WebService、5.返回结果,两条线程处理2.数据库查询, 而5条线程处理耗时最多的4.WebService请求。
     结果表明,当远程调用所花时间不变,而本地操作得到优化时,系统通量也能获得明显提高。

3. Mule 中的SEDA 实例

      Mule是SEDA架构的遵循者。每个Component间,用inbound->outBound的Queue异步相连,每个Component可以设置自己的线程池大小,队列长度。

      因此SEDA中的Stag间事件驱动异步链接,Stag内Incoming Event Queue,Thread Pool,Event Handler都有了。

<mule-descriptor class="code-quote" name="&amp;lt;span"></mule-descriptor>"RadioCarUMO" implementation="radioCar">

    <threading-profile class="code-quote" maxthreadsactive="&amp;lt;span"></threading-profile>"5" maxThreadsIdle="10" poolExhaustedAction="WAIT" threadWaitTimeout="-1" id="component" doThreading="true"/>
    <queue-profile class="code-quote" maxoutstandingmessages="&amp;lt;span"></queue-profile>"6"/>
    <inbound-router></inbound-router>
        <endpoint class="code-quote" address="&amp;lt;span"></endpoint>"RadioCarsQueue"/>
        <router class="code-quote" classname="code-quote"></router>"org.mulefair.routing.BennyTheGatekeeper"/>
    
    <outbound-router></outbound-router>
        <router class="code-quote" classname="code-quote"></router>"org.mule.routing.outbound.OutboundPassThroughRouter">
             <endpoint class="code-quote" address="&amp;lt;span"></endpoint>"FairAreaQueue"/>
        
    

   而例子中的InboundRouter BennyTheGatekeeper,则实现了administration controller的角色,本来poolExhaustedAction="WAIT",而administration controller可以通过计数器,直接refuse需求,将请求转发到alarm queue。

   整个Stag中唯一缺失是动态改变资源参数的Resource Controller,threadpool也不是Dynamically sized Thread Pool,但这似乎不重要了。

    再一次觉得Mule充当Service Container比ESB时还要称职。

posted @ 2013-01-17 11:04  primeli  阅读(170)  评论(0编辑  收藏