? 关于mule所遵从的标准只有SEDA、EIP、MEPs，对于JBI和SCA都是部分参考，翻译一篇infoQ的SEDA文章：
?
? 是什么？它可不是你爹喝的威士忌，它是Staged Event-Driven Architecture的缩写。它是对于把系统活动按照 阶段和事件来 分解筛选的提议架构。
? 以SEDA视角来看，一个对服务的请求可以分解为数个阶段、每个阶段负责一部分对请求的处理。阶段之间使用请求队列链接，通过控制每个处理阶段的负载评估，服务便可以执行集中的负载管理（例如：过滤掉那些能造成资源瓶颈的请求）. 通过这种方式，计算机系统便可以更好的伸缩、而不必再用传统的靠CPU堆出性能的方法、在请求大规模并发时可以应付一刻、其他所有时间这些CPU都根本用不上。
? SEDA作为年轻俊杰 的Ph. D论文的一部分出现，他的论文是关于在极端负载下如何管理网络服务性能的。我们建议你读一读： 大负荷网络服务的自适应超载控制，那是这篇文章的基础。
? 描述SEDA的一个方法是使用一些家伙的隐喻：就像吃进牛奶面包和麦片粥、一会、经过数个不同阶段、它们会产生不同的输出物...
? Ok！换种比喻、想象一下我们的幼儿园要组织小朋友们去游乐园游玩，但是对于一小撮不明真相的小朋友这会给他们制造撒野的机会就像打翻了装满蚂蚁的罐子...所以对于游园者制定规则是必须的，游园的孩子都有一样的安排：一是旋转木马、二是过山车、三是碰碰车、四是恐怖谷...等等，这就是服务请求，有固定的路线经过一些服务阶段，像过山车这种就对映着SEDA阶段的概念。
? 但是，你可能也有体会，上述每个游乐项目都有不同容量的，因此我们遭遇了瓶颈。如果你体验过那种没大人带的孩子排的长队，你就知道、每位爹妈、姨妈、叔叔、老师都知道，这是个和排队时间长短同比例的滋长混乱的时刻，队伍很快会挤成一团，所以无论对于孩子还是我们的阶段式请求处理，排长队都是要尽力避免的。
? 来看看SEDA如何拯救我们于排长队的水火、下面是SEDA的阶段 图：
一个阶段 有数个组件：
- Incoming Event Queue 入口事件队列
- Admission Controller 入口控制器
- Dynamically sized Thread Pool 动态线程池
- Event Handler 事件处理器
- Resource Controller 资源控制器
? Incoming Event Queue 入口队列，这是请求事件在被服务组件处理以前呆的地方，可以看作是等待碰碰车的孩子们排的长队，和它相关的是Admission Controller 入口控制器 ，作为进入队列的控制者角色。
? dynamically-sized Thread Pool 动态线程池中的线程会从入口队列中取出一批事件并调用Event Handler 事件处理器 ，事件处理器处理每一批事件，然后分发0或多个事件——把他们放到下一个处理阶段 的入口队列 中去（原文：dispatches zero or more events by placing them on the event queues of other stages.）用到我们的游乐园的话：碰碰车的大池子就扮演了Thread Pool线程池，线程与事件处理器加起来就是碰碰车了，它们为孩子也就是事件来提供服务（原文：the combination of the threads and Event Handler matches the a number of radio cars driving around with kids）
? 最终，每个阶段 都由dynamic Resource Controller动态资源控制器 来协调它的理想运转模式，它调整阶段 参数。资源控制器 观察每个阶段 的负荷和性能来调整执行每个阶段 的线程的数量，在碰碰车当中 资源控制器 的角色是在碰碰车大池子当中调整车的数量：增加或减少池中的车子。
? 到现在为止还不错，那么我们如何把排队等待的时间保持在可接受水平上？使用SEDA机制，首先我们使用碰碰车的Thread Pool线程池机制：负责碰碰车的人（充当了资源控制器 角色）在需要时直接增加更多车子，但是这样只能应付一阵，碰碰车大池子即将在某个临界点上耗尽...
? 许多应用在这种情况下就黔驴技穷了，我们还有第二个绝活： 碰碰车队列的Admission Controller入口控制器 ，作为观察者、无论人还是计算机都干同样的事：需要重点处理某些元素/人（xxxxx）、当队列排满时、 重负荷的处理任务/捣乱的孩子就会被拒绝！游乐园中、班尼就是这么一个看门人（admission controller），他的重要职责就是保持队形整齐、看住那些调皮捣蛋的孩子，你可能也见过、看门人（Admission Controller）即能把捣蛋者揪出队伍、也能让他们靠后排！当处理能力足够的时候才会为他们服务.
? 仍有很多情况会使处理能力耗尽、SEDA也还有一打的对策呢！这些对策使用了Resource Controller资源控制器+Admission Controller入口控制器 ，他们俩提供关于队列和资源状态的信息，因此可以得知何时队列已达上限、所有资源是否可用，这些信息交给Event Handler事件处理器 —它有非常手段来处理负荷，其中之一是Service Degradation服务降格 . 在我们的游乐园中，服务降格就类似于把每个孩子坐碰碰车的时间从五分钟减少到2分钟，诚然，这样有点不太地道、糊弄小孩、他们会生气、不过：tmd让你玩会就不错了！总比没得玩强吧？通过调整服务级别、我们整个系统得以优雅体面地gracefully degrade降格服务 。
? 至此我们讨论完了在一个单独的SEDA阶段 如何处理负荷超载，但是就像上面提过的， 服务包含了一连串的 阶段 ，当队列达到上限，很方便就可以用某种手段通知连串起始位置的阶段 ，当请求事件被Admission Controller入口控制器 拒绝服务时、SEDA会发出入队失败通知、通知在连串的阶段链中逆流而上直达起始位置的那个阶段！（原文：sending an enqueue failure to the stage upstream.）这就像两个一根绳连接的锡铁可以用来通话、一个罐子在碰碰车、另一个在旋转木马。当旋转木马获得碰碰车反馈时，它即可开始处理情况：它可以把请求转发掉（就像让孩子们先去过山车而不是碰碰车、过山车从5分钟延长到10分钟）、最糟糕的情况是：拒绝服务！
? 通过使用上述机制、我们得到了一个可伸缩、xx控制超载的系统，而不是在某个瓶颈继续堆积已经饱和的请求！那么，{zh1}一个问题：这一切与mule有何关系？
? mule与SEDA：
? 
? Mule环境下、组件在其中执行的环境、被特指为model 模型 概念，模型 封装并管理着一个service服务 实例的运行时行为。并可以配置为在数种不同模式下运转。默认是一种基于SEDA的模式，在此模式下、Mule把每个组件当作一个阶段，有他自己的线程池 和工作队列。
? SEDA阶段 包含：
- Incoming Event Queue 入口事件队列
- ?Admission Controller 入口控制器
- ?Dynamically sized Thread Pool 资源控制器
- ?Event Handler 事件处理器
- ?Resource Controller 资源控制器
? 在Mule当中：与Incoming Event Queue 入口事件队列相对映的是inbound router or endpoint入站路由或端点； Event Handler事件处理器则相当于 component组件自身；因此我们只缺Admission Controller入口控制器、Resource? Controller 资源控制器、 Dynamically sized Thread Pool 资源控制器：
Admission Controller入口控制器
? 入口控制器 与SEDA阶段的入口事件端点相关联，最简单的实现方式就是inbound router入站路由， 可以控制什么样的订阅事件才会被组件接收以及怎样接收，参见： ? .
? 例如、我们的好朋友班尼看门人， 负责监控碰碰车队列的，就可以做为一个Inbound Router入站路由，如下配置：
123
? 班尼，还不算{zj2}武器、游乐园老板还不敢把宝都压在他身上，这就是助手Kitty B凯蒂出现的原因，或者更准确说是监视班尼，为确保碰碰车项目能排队秩序井然，Mule让我们可以使用数种链式inbound routers入站路由，每个入站路由都得接收一个入口(kindergarten brat) in the queue, in order to grant it entry:
className="org.mule.routing.ForwardingCatchAllStrategy">
? 上幼儿园的孩子们并不蠢，他们学会了用一个巧克力棒贿赂班尼，甚至当他们太小个子太矮不能玩碰碰车的时候！不过还好、凯蒂可不是吃素的，她把捣蛋者拒之门外，此时拒之门外的孩子就可以统一交给catch-all-strategy去处理，当没有inbound routers入站路由接收某个队列事件的时候它便介入了，在上面的例子中，标准Mule ForwardingCatchAllStrategy 会把所有被拒绝事件发往指定端口，对于巧克力贿赂未遂的孩子（chocolate bribing kindergarten brats (CBKB)）将会发往RejectedFromRadioCars队列。因此，xx可以说mule提供了{zy1}的可插拔的入口控制。
?
Resource Controller 资源控制器
? 综上所述，SEDA提出Resource Controllers资源控制器 概念用于 管理某一个阶段中的资源，如果碰碰车队列持续增长、资源控制器只要简单的增加碰碰车以满足需求即可。
? 结果，Mule使得我们可以配置阶段 如何初始化、线程数量、对象池尺寸等大多数方面。例如：请参看以下碰碰车阶段 的配置片段：
name="RadioCarUMO"
implementation="radiocarEventHandler"
inboundEndpoint="RadioCarQueue">
...
maxThreadsActive="4"
maxThreadsIdle="2"
poolExhaustedAction="ABORT"
threadWaitTimeout="-1"
doThreading="true"/>
...
?? Mule允许我们调整可分配给阶段 的线程数量（上面配置是1.x的、对映于2.2.1的service、RadioCarUMO是component。每个service就是一个阶段 、这里配置了这个阶段的{zd0}活跃线程、{zd0}空闲线程、线程池耗尽触发动作、线程等待超时...），这样碰碰车管理员就很容易指定到底有多少车可以用.。然而，Mule不提供out-of-the-box机制以便调整所用线程数量，运行期间、Instead, Mule takes it upon its shoulders to make sure a stage operates with optimal parameters?. 既然我们已经满足于让班尼做看门人，把Resource Controller资源控制权力交给 Mule就是个好选择了。 However, if more control is needed over your resources, the default SEDA Model implementation can simply be overridden to achieve this?.
Utilizing Mule Statistics 利用mule的统计数据
? Mule针对components组件、queues队列和overall environment整体环境收集了大量统计数据。我么可以加以利用，例如Event Handler事件处理器， 关于每个阶段的队列尺寸统计可以免费获取到，这样我们就可以祭出Service Degradation服务降格利器 ，当队列尺寸达到某一阀值时降低每个孩子坐碰碰车的时间、孩子们不喜欢，但是我们的游乐场得以优雅体面的运转 ，and the best part is that Benny will receive all the heat from the children that were cut short after standing in line for an eternity (a child’s eternity)（这段没大看懂）.
? 统计数据也可以利用来帮助实现Outbound Router 出站路由，当孩子们玩完碰碰车，他们就把班尼抛到脑后了。giving him heat because of the reduced duration. If Benny is wearing his lenses, or in Mule-terms; is looking at the component statistics , he knows which Amusement park Events are not full. With this knowledge he could advice the kids who just gave him heat to head for the queues where the progress is painstakingly slow. This is a way of controlling the resources of the whole Amusement park environment.（这一段大意应该是：如果班尼在观察着游乐场情况的话他就知道哪个游乐项目目前很空闲，他就可以建议孩子们先去玩那一项，这是一种控制整个游乐场资源的方式）
? 如上所描述，SEDA是一种强大的机制，使用它你的系统可以动态处理负载爆发、而不会导致整个应用的资源枯竭。
? 本文我们描述了SEDA本身以及它在Mule中如何实现，我们举了游乐场例子，总结例子、我们得到以下的mule游乐场应用模型，把它的精髓记在心里吧：
?
? 捣蛋者通过Mule Fair queue公平队列或channel 通道进入游乐园，听话孩子则由park guide导游 安排单独从园区大门口进入，导游负责导引小家伙们(towards one of the many fair events), 碰碰车是{dy}个，也是{zlx}的一个。然后是旋转木马和过山车。
? 前面提过，碰碰车的看门人是我们最棒的班尼，他相当于Mule Inbound Router 入站路由。虽然班尼老混蛋会被巧克力棒贿赂！但是最烦心的还在后头：如果一个孩子的名字包含字母‘e’那么班尼会直接拒绝他并把他赶到大门口。 Not the most useful Admission Controller you could think of, but still, he’s all we’ve got?.
? 一旦玩完碰碰车，孩子们会聚到大门口重新排队。
? 如果碰碰车队列或者其他任何游乐项目的队列太长，班尼就会开始扮演Resource Controller资源控制器角色啦：减少碰碰车服务时间 。如果这样还不管用，他会向Alarm Queue 发出入队失败信号事件，示意大门口的Park Guide导游 不要再让孩子们来碰碰车排队啦！直到队伍不再拥塞。
? So, folks, this is very much it. Go and play with Mule and SEDA as a way to handle scalability under high loads of traffic!
is currently Senior Software Architect at Bouvet. Rune has Java experience since 1996, and worked with large distributed Java systems since 1999. He as worked for several years as senior architect, lead developer and project manager with SOA systems both in telecom and the retail business. Has also held SOA talks both on international conferences and the Norwegian JUG as well. Author of the article "Evolutionary integration with ESBs" published at InfoQ in June 2007.
is currently working as a consultant at Bouvet. Rune has Java experience since 1998 and is a board member of javaBin, Norway’s Java User Group.
?
?
? 备忘一些mule标准相关网址： （ 、 、 ）、 、 ，全英文，但是非常好的资料。
