SEDA - 江南白衣博物馆

1.Overview

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

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

SEDA模式的意义：

一来是让不同资源消耗的Stag使用不同的线程数量，达到资源的最优配置(统计学上的详见 Java EE 迎合 Web 2.0(IBM DW))

二来可以让不同的服务入口配置不同的资源，保证某些核心服务有足够的资源运行，非核心服务不会抢占完了所有资源，如果单纯由Tomcat来控制线程，就分不出这个轻重。

在每个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单位时间)
数据库查询(4单位时间)
根据数据库查询结果，准备Web Service调用参数(1单位时间)
发起Web Service调用((16单位时间))
将结果渲染返回给用户(2单位时间)

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

3. Mule 中的SEDA 实例

Using SEDA to Ensure Service Availability(InfoQ)

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

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

<mule-descriptor name="RadioCarUMO" implementation="radioCar">

    <threading-profile maxThreadsActive="5" maxThreadsIdle="10" poolExhaustedAction="WAIT" threadWaitTimeout="-1" id="component" doThreading="true"/>
    <queue-profile maxOutstandingMessages="6"/>
    <inbound-router>
        <endpoint address="RadioCarsQueue"/>
        <router className="org.mulefair.routing.BennyTheGatekeeper"/>
    </inbound-router>
    <outbound-router>
        <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
             <endpoint address="FairAreaQueue"/>
        </router>
    </outbound-router>
</mule-descriptor>

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

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

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