為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

???? 本人覺得這一章很重要，那就是 Spring默認(rèn)的channel 的實現(xiàn) DirectChannel，這個要大家多按照原文理解，開發(fā)者為何提供這樣的一個channel，以及該channel適用的場景。

DirectChannel

TheDirectChannelhas point-to-point semantics（語義） but otherwise is more similar to thePublishSubscribeChannelthan any of the queue-based channel implementations described above. It implements theSubscribableChannelinterface instead of thePollableChannelinterface, so it dispatches（分發(fā)） Messages directly to a subscriber（訂閱者）. As a point-to-point channel, however, it differs from thePublishSubscribeChannelin that it will only send each Message to a single subscribed（理解這句話，如果有多個訂閱者 該Channel 僅僅選擇其中一個訂閱者發(fā)送，而忽略其他訂閱者）MessageHandler.

(PS:DirectChannel 從字面理解是 基于 點(diǎn)對點(diǎn) 傳輸模式。事實上，他更像是一個 PublishSubscribeChannel 的實現(xiàn)，除了內(nèi)部實現(xiàn)消息隊列機(jī)制以外。 該類實現(xiàn)了 SubscribableChannel 接口 而不是 PollableChannel 接口。所以他會直接分發(fā)消息給訂閱者。 同時作為 點(diǎn)對點(diǎn) 的傳輸隊列，他有不同于傳統(tǒng)意義的 PublishSubscribeChannel。他每次僅僅發(fā)消息發(fā)送給訂閱者之一)

In addition to（除了） being the simplest point-to-point channel option, one of its most important features is that it enables a single thread to perform（扮演，充當(dāng)） the operations on "both sides" of the channel. For example, if a handler is subscribed to aDirectChannel, then sending a Message to that channel will trigger invocation of that handler'shandleMessage(Message)method directly in the sender's thread, before the send() method invocation can return.（這里要是有個時序圖就好了，第一次閱讀這里是無法理解的，NND，坑爹的老外，傷不起的外語水平）

(PS:除了上述提到的點(diǎn)對點(diǎn)傳輸模式是 DirectChannel 的特性外，還有一個比較重要的特征就是，該通道允許單線程同時 充當(dāng) 發(fā)送 與接受的角色，例如：一個訂閱者 注冊到 DirectChannel后，當(dāng)一個消息發(fā)送到該 channel，則直接觸發(fā)handleMessage(Message)方法在 send 方法執(zhí)行完之前。)

The key motivation（動機(jī)） for providing a channel implementation with this behavior（行為） is to support transactions（事務(wù)） that must span across the channel while still benefiting（受益） from the abstraction and loose coupling that the channel provides. If the send call is invoked within the scope of a transaction, then the outcome of the handler's invocation (e.g. updating a database record) will play a role in determining the ultimate result of that transaction (commit or rollback).

(PS:這樣做的動機(jī)是 為了 讓通道兩端的操作能包含在一個事務(wù)中。大概意思是這樣子的，其余的讀者自己理解)

Note

Since theDirectChannelis the simplest option and does not add any additional overhead that would be required for scheduling（調(diào)度） and managing the threads of a poller, it is the default channel type within Spring Integration. The general idea is to define the channels for an application and then to consider which of those need to provide buffering or to throttle input, and then modify those to be queue-basedPollableChannels. Likewise, if a channel needs to broadcast messages, it should not be aDirectChannelbut rather aPublishSubscribeChannel. Below you will see how each of these can be configured. (PS：由于 DirectChannel 的簡單性，使其無需增加任何額外的開銷即可提供調(diào)度以及管理線程輪詢，這是 Spring Integration 內(nèi)部默認(rèn)實現(xiàn)的channel。如果頂一個應(yīng)用程序的channel，首先需要考慮的是 該channel是否需要提供隊列緩存功能，之后是是否需要提供基于優(yōu)先級策略的PollableChannels， 如果你僅僅是為了實現(xiàn)消息廣播，則采用PublishSubscribeChannel是正確的選擇而不是DirectChannel。 如下將針對這些配置進(jìn)行展開描述 )

TheDirectChannelinternally delegates to a Message Dispatcher to invoke its subscribed Message Handlers, and that dispatcher can have a load-balancing（負(fù)載均衡） strategy. The load-balancer determines how invocations（調(diào)用） will be ordered in the case that there are multiple handlers subscribed to the same channel. When using the namespace support described below, the default strategy is "round-robin"(輪詢) which essentially（本質(zhì)上，基本的） load-balances across the handlers in rotation（輪流）.

（PS：DirectChannel 可以充當(dāng)消息分發(fā)的角色定位，并且該分發(fā)是基于負(fù)載均衡策略。負(fù)載均衡實現(xiàn)了對訂閱該通道 的消息訂閱者按照順序循環(huán)調(diào)用。其內(nèi)部實現(xiàn)的默認(rèn)策略是 循環(huán) 機(jī)制。這個是負(fù)載均衡的最基本的一種實現(xiàn)。 ）

Note

The "round-robin" strategy is currently the only implementation available out-of-the-box（開箱即用） in Spring Integration. Other strategy implementations may be added in future versions. (PS:這種循環(huán)的負(fù)載均衡策略已經(jīng)被 Spring Integration實現(xiàn)，它屬于開箱即用 的一種功能。其他的策略需要在以后的版本中加入)

The load-balancer also works in combination with（與.....組 合） a boolean failover（故障轉(zhuǎn) 移） property. If the "failover" value is true (the default), then the dispatcher will fall back to（回滾到） any subsequent（隨后的） handlers as necessary when preceding（前面的） handlers throw Exceptions. The order is determined by an optional order value defined on the handlers themselves or, if no such value exists, the order in which the handlers are subscribed（訂閱）.

(PS:負(fù)載均衡 常與 故障轉(zhuǎn)移 配合使用，對于DirectChannel的 failover 值，默認(rèn)是 開啟的。當(dāng)前一個訂閱者調(diào)用發(fā)生異常 分發(fā)器會回滾當(dāng)前狀態(tài)到下一個訂閱者重新處理，其調(diào)用的順序是由handlers自身的 order 屬性決定。如果不存在這樣的值 則有訂閱者默認(rèn)的順序決定。 )

If a certain（某些） situation requires that the dispatcher always try to invoke the first handler, then fallback in the same fixed order sequence every time an error occurs, no load-balancing strategy should be provided. In other words, the dispatcher still supports the failover boolean property even when no load-balancing is enabled. Without load-balancing, however, the invocation of handlers will always begin with the first according to their order. For example, this approach works well when there is a clear definition of primary, secondary, tertiary, and so on. When using the namespace support, the "order" attribute on any endpoint will determine that order.

(PS:假如在某一場景下需要分發(fā)器總是嘗試調(diào)用第一個 handler，發(fā)生異常 回滾也是采用固定的序列，不需要負(fù) 載均衡的策略支持。換句話說：分發(fā)器支持在關(guān)閉負(fù)載均衡的模式下仍舊對 failover 有效。因此，調(diào)用handlers順序總是 按照第一次排序的順序進(jìn)行。例如 當(dāng)清晰的定義了 第一 、第二 、第三 等順序，那么這種工作機(jī)制將會很好的運(yùn)行)

Note

Keep in mind that load-balancing and failover only apply when a channel has more than one subscribed Message Handler. When using the namespace support, this means that more than one endpoint shares the same channel reference in（引用） the "input-channel" attribute. (PS:值得一提的是，無論是負(fù)載均衡 還是 故障轉(zhuǎn)移 應(yīng)用的場景至少該通道多于一個訂閱者訂閱，當(dāng)采用命名空間時， 這意味者至少一個以上的endpoint分享統(tǒng)一 channel 通過 input-channel 屬性。)

ExecutorChannel

TheExecutorChannelis a point-to-point channel that supports the same dispatcher configuration asDirectChannel(load-balancing strategy and the failover boolean property). The key difference between these two dispatching channel types is that theExecutorChanneldelegates to an instance ofTaskExecutorto perform the dispatch. This means that the send method typically will not block, but it also means that the handler invocation may not occur in the sender's thread. It therefore does not support transactions spanning the sender and receiving handler.

(PS:ExecutorChannel 是 點(diǎn)對點(diǎn) 通道的實現(xiàn)，同時他支持 DirectChannel 的分發(fā)器特性，（負(fù)載均衡與故障轉(zhuǎn)移）。 兩者之間一個顯著的不同之處是 ExecutorChannel 內(nèi)部是通用一個 TaskExecutor 實例實現(xiàn)的。這意味著調(diào)用該 通道的 send 方法不會發(fā)生阻塞，同時這將意味著 對handler的調(diào)用將不會與sender 公用統(tǒng)一線程， 該模式不支持事務(wù)，發(fā)送與接受分別受限與不同的線程 )

Tip

Note that there are occasions（場合） where the sender may block. For example, when using a TaskExecutor with a rejection-policy（數(shù)量限制） that throttles（節(jié) 流） back on the client (such as theThreadPoolExecutor.CallerRunsPolicy), the sender's thread will execute the method directly anytime the thread pool is at its maximum capacity and the executor's work queue is full. Since that situation would only occur in a non-predictable way, that obviously（明顯） cannot be relied upon for（依 靠，依賴） transactions. (PS:注意在某些場合下，調(diào)用ExecutorChannel 的send 也有可能被阻塞。例如 ，當(dāng)使用的 TaskExecutor 受管以一個數(shù)量限制的客戶端（線程池），當(dāng)池中沒有可用的線程是，或者執(zhí)行隊列 當(dāng)前沒有空位是，則會被阻塞。因為這種情況的發(fā)生是不可預(yù)測的)

Scoped Channel

Spring Integration 1.0 provided aThreadLocalChannelimplementation, but that has been removed as of 2.0. Now, there is a more general way for handling the same requirement（需求） by simply adding a "scope" attribute to a channel. The value of the attribute can be any name of a Scope that is available within the context. For example, in a web environment, certain（特定的，這里是指：session、request、goal等） Scopes are available, and any custom Scope implementations can be registered with the context. Here's an example of a ThreadLocal-based scope being applied to a channel, including the registration of the Scope itself.

(PS:在Spring Integration 1.0 版本中，提供了基于線程范圍的 ThreadLocalChannel實例，但是在2.0中被移除了。 現(xiàn)在提供一個更加通用的方法來滿足該需求，那就是通過 channel 的scope的屬性。該屬性的值可以是在Spring 容器中可被識別的任何值。例如在 web環(huán)境中，一些特定的Scope 是可用的。 并且這些都已經(jīng)被注冊到Spring 容器中。如下的代碼 展示了 基于線程 范圍生命周期的配置，包括這側(cè) 線程Scope 到Srping容器)

<int:channel id="threadScopedChannel" scope="thread"><int:queue /></int:channel><bean class="org.springframework.beans.factory.config.CustomScopeConfigurer"><property name="scopes"><map><entry key="thread" value="org.springframework.context.support.SimpleThreadScope" /></map></property></bean>

The channel above also delegates to a queue internally, but the channel is bound to（綁定） the current thread, so the contents of the queue are as well. That way the thread that sends to the channel will later be able to receive those same Messages, but no other thread would be able to access them. While thread-scoped channels are rarely（很少，極少） needed, they can be useful in situations（場景） whereDirectChannelsare being used to enforce（執(zhí)行） a single thread of operation but any reply Messages should be sent to a "terminal" channel. If that terminal channel is thread-scoped, the original sending thread can collect its replies from it.

(PS : 上述的channel 同時作用于其內(nèi)部的隊列。由于channel 綁定了當(dāng)前的工作線程，所以其內(nèi)部隊列同樣被作用。 這樣線程不經(jīng)可以發(fā)送，還可以接受這些消息。當(dāng)時其他線程是無法訪問該channel的。事實上，基于thread-scoped 的channle 很少被用到。一個比較有用的場景是 當(dāng)通過 DirectChannels 在單線程下執(zhí)行一個消息發(fā)送后任何響應(yīng)的消息 可以發(fā)送到這個終端的 channel 中。如果這個channel 是基于 thread-scoped，那么原先的發(fā)送線程可以通過他獲取任何響應(yīng)的消息)

轉(zhuǎn)載于:https://my.oschina.net/qfhxj/blog/95369

總結(jié)

以上是生活随笔為你收集整理的#翻译NO.5# --- Spring Integration Framework的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。