Shuttle（飛梭）服務(wù)總線是一個免費的.NET開源軟件項目，它為開發(fā)面向消息的事件驅(qū)動架構(gòu)（EDA）系統(tǒng)提供了一種新方法。盡管它仍處于起步階段，不過它已被應(yīng)用于生產(chǎn)系統(tǒng)之中。

相關(guān)要點如下：

• 用C#（基于.NET 3.5）開發(fā)而成
• 核心功能不依賴于任何第三方產(chǎn)品或項目
• 既支持命令消息，又支持事件消息（Pub/Sub）
• 具有集成的消息分發(fā)功能
• 包含一個命令行管理程序，以便輕松應(yīng)對各種操作要求
• 廣泛使用接口，以便替換或擴展功能
• 通過自動重試提供容錯能力

為何要使用服務(wù)總線？

盡管在使用服務(wù)總線（service bus）時需要做一些思維模式的轉(zhuǎn)變，不過這么做卻是大有裨益的。通過在你的系統(tǒng)中設(shè)計一條服務(wù)總線，讓其在特定終結(jié)點（endpoint）上執(zhí)行非常明確的功能，這樣你就可以專心設(shè)計在隔離環(huán)境下運行的那一小部分軟件。可以對此類終結(jié)點進行獨立地版本控制及維護，而前提是你對此類終結(jié)點所做的解耦工作已達到所需的程度。

基本上是說，你最終會在不同組件之間發(fā)送消息，并對這些消息進行異步處理。由于這會導(dǎo)致出現(xiàn)“即發(fā)即棄（fire-and-forget）”的情況，因此需要認真考慮系統(tǒng)的工作方式。而由此帶來的用戶體驗可能完全不同于傳統(tǒng)實現(xiàn)，即那種立即處理對用戶所請求的全部操作的方式。

比如就是簡單地發(fā)送一封電子郵件。你可以先設(shè)置好某個終結(jié)點去處理與之有關(guān)的命令消息類型（command message type）。然后，當(dāng)你需要發(fā)送電子郵件時，你就可以使用如下代碼：

Bus.Send(new SendEMailCommand{From = "someone@from.com",To = "someone@to.com",Subject = "testing e-mail",Body = "Hello"});

你可能想知道，這么做與你自己直接發(fā)送此郵件的到底有何不同之處：

• 這條消息發(fā)送調(diào)用是即時的，而我們不用等著此調(diào)用執(zhí)行完成
• 由于請求會被排入隊列，因此就避免了瓶頸
• 要是此郵件發(fā)送失敗，就會自動重發(fā)此郵件
• 只要得到的數(shù)據(jù)正確無誤，就可以保證此郵件最終會被發(fā)出去；或者，至少在發(fā)生問題時可以采取手動操作進行處理

因此，客戶端代碼不用關(guān)心該終結(jié)點到底是如何發(fā)送數(shù)據(jù)的。而終結(jié)點可能會用簡單郵件傳輸協(xié)議（SMTP）發(fā)送數(shù)據(jù)，甚至還可能會用某種自定義的網(wǎng)絡(luò)服務(wù)（web-service）發(fā)送數(shù)據(jù)。

Shuttle是如何發(fā)揮其魔力的？

Shuttle服務(wù)總線依賴于兩件事：

• 消息（Message），及
• 隊列（Queue）

隊列基礎(chǔ)設(shè)施可以是任何實現(xiàn)。通常情況下，你會想使用某種真正的隊列技術(shù)，例如微軟消息隊列（MSMQ）。目前Shuttle提供直接現(xiàn)成支持的隊列有，微軟消息隊列（MSMQ）及Sql Server基于表的隊列（table-based queues）。如果你想使用任何其他實現(xiàn)，要解決的問題就是實現(xiàn)有關(guān)接口，因此你會干得不錯。Shuttle使用統(tǒng)一資源標識符（URI）的結(jié)構(gòu)去表示隊列，例如：

• msmq://{machine}/{queue}
• sql://{connection-name}/{table}

為了實現(xiàn)你自己的隊列，你只需簡單挑選一種方案，并在你的隊列實現(xiàn)中解析這種結(jié)構(gòu)。

為了組織你的終結(jié)點，Shuttle使用了通用服務(wù)主機去簡化部署。讓一個新的終結(jié)點生效，就是解決該終結(jié)點所用隊列的配置問題，然后啟動你的服務(wù)即可，正如以下配置文件及代碼片段所示：

<?xml version="1.0"?> <configuration><configSections><sectionname="serviceBus"type="Shuttle.ESB.Core.ServiceBusSection, Shuttle.ESB.Core"/></configSections><serviceBus><inboxworkQueueUri="msmq://./inbox-work"journalQueueUri="msmq://./inbox-journal"errorQueueUri="msmq://./shuttle-error"/></serviceBus> </configuration>public class ServiceBusHost : IHost, IDisposable{private IServiceBus bus;public void Dispose(){bus.Dispose();}public void Start(){bus = ServiceBus.Default().Start();}}

應(yīng)該注意的是，通用主機既能以控制臺應(yīng)用程序的方式運行，又能作為服務(wù)去安裝。這樣就讓調(diào)試終結(jié)點變得特別容易，因為當(dāng)你在Visual Studio中調(diào)試時，你可以將通用主機指定為啟動應(yīng)用程序。

一旦通用主機從收件箱隊列中獲取到一條特定的消息，通用主機就會嘗試找到處理程序，并將消息傳送給此處理程序以供處理。至于那些找不到處理程序的消息，或被移至錯誤隊列，或被丟棄，采取何種處理方式就要根據(jù)配置文件中所指定的信息而定了。

命令消息與事件消息

由于命令（command）是一個要求執(zhí)行特定功能的明確請求，因此命令會被發(fā)送至單獨的終結(jié)點。這意味著，為了發(fā)送消息，你需要知道某個終結(jié)點實現(xiàn)了特定的行為。因此，命令導(dǎo)致了更高程度的行為耦合。而如果在發(fā)送消息時，那個接收消息的終結(jié)點是可配置的，那么便可隨時更改終結(jié)點。

譬如，你可能有如下命令：

• SendEMailCommand
• ConvertDocumentCommand
• DeleteFileCommand
• CancelOrderCommand

剛好相反，事件（event）可能沒有或有多個訂閱者（subscriber）。通常情況下，事件應(yīng)該被明確定義，因為從業(yè)務(wù)角度看必需這么做。因此，按理說，除非是那種根據(jù)未來需求定義的事件，否則事件至少會有一個訂閱者。一旦事件被發(fā)布出來，每個訂閱者都會收到一份事件消息副本。

這不同于消息分發(fā)（message distribution），因為一條分布式消息只會被發(fā)送至一個工作者的收件箱隊列。

譬如，你可能有如下事件：

• EMailSentEvent
• DocumentConvertedEvent
• FileDeletedEvent
• OrderCancelledEvent

為了在消息中添加任何必需的即席數(shù)據(jù)（ad-hoc?data），Shuttle服務(wù)總線允許你為消息指定消息頭。此外，還可以使用相關(guān)ID（correlation ID）去對有關(guān)消息進行分組。

可伸縮性（Scalability）

Shuttle使你獲得了不少的可伸縮性（scalability），由于消息被排入隊列，因此也就不會出現(xiàn)刻不容緩的緊迫瓶頸。即使有些終結(jié)點可能會被配置成多線程的，但是這并不意味著某個特定的終結(jié)點不會由于接收過量消息而導(dǎo)致性能下降。每個終結(jié)點都要有將消息分發(fā)給其他終結(jié)點的內(nèi)置能力，一旦任何其他終結(jié)點通知分配器（distributor）它有可執(zhí)行工作的空閑線程，就可以運用此能力分發(fā)消息。而要做到這一點，只需配置一下就好了。

模塊（Modules）

Shuttle使用了一種可觀測的管道（pipeline）結(jié)構(gòu)。各種事件以特定順序被注冊到管道中，而觀察者（observer）也可以被注冊到管道中去響應(yīng)各自的事件。

為了保持可擴展性（extensibility），你可以把自己的模塊實現(xiàn)注冊到Shuttle之中。通過添加響應(yīng)各自管道事件的觀察者，這些模塊通常會與特定的管道相連。而且為了隨需應(yīng)變，你甚至可以把自定義事件添加到管道中。

對于依賴注入及日志記錄的支持怎么樣？

由于Shuttle為了解耦而如此廣泛地使用了接口，因此你就可以根據(jù)個人喜好，自由接入任何依賴注入（DI）或日志記錄的實現(xiàn)。默認實現(xiàn)不依賴于任何第三方組件，不過目前還有作為依賴注入實現(xiàn)的Castle Windsor及作為日志記錄實現(xiàn)的Log4Net可供選用。

生產(chǎn)環(huán)境下的Shuttle案例

Shuttle在南非某大型短期保險公司的實施已大獲成功，取代了陳舊的文檔索引系統(tǒng)。

客戶通過電子郵件發(fā)送與索賠有關(guān)的文檔，而郵件會被Lotus Domino電子郵件系統(tǒng)接收到。然后，FileNet Email Manager（電子郵件管理器）應(yīng)用程序會將這些電子郵件提取出來，并放置到IBM FileNet Content Engine（內(nèi)容引擎）中。內(nèi)容引擎經(jīng)過配置，用以響應(yīng)任何電子郵件分類為已提交的新文檔。內(nèi)容引擎被設(shè)計用于處理這些送達郵件，并寫出一份包含相關(guān)數(shù)據(jù)的XML文件。

從那里開始，Shuttle Content Engine（內(nèi)容引擎）終結(jié)點會拾取這些XML文件，然后發(fā)布事件以表明新內(nèi)容已被放置到了內(nèi)容引擎中。由于此終結(jié)點的結(jié)構(gòu)并沒有具體到索引過程，因此就有可能重用此終結(jié)點，用于發(fā)布任何新內(nèi)容。而且應(yīng)由此內(nèi)容引擎負責(zé)簡單寫出相關(guān)的XML文檔。

Shuttle Indexing（索引）終結(jié)點訂閱那些新的內(nèi)容消息，而且消息一送達，終結(jié)點就開始跟蹤與特定郵件一起送達的所有文檔，因為每封郵件都有唯一標示符，而且此標示符已被附加到每份文檔的內(nèi)容引擎元數(shù)據(jù)中。一旦搜集到與一封郵件相關(guān)的所有文檔，命令消息就會被發(fā)送至Shuttle Document Conversion（文檔轉(zhuǎn)換）終結(jié)點，用以將HTML格式郵件正文及全部JPG格式文件轉(zhuǎn)換為TIFF格式文檔。

文檔轉(zhuǎn)換終結(jié)點對于索引過程一無所知，而僅僅執(zhí)行各種文檔轉(zhuǎn)換。一旦某個文檔轉(zhuǎn)換完成，就會發(fā)布事件以通知某個文檔轉(zhuǎn)換已成功或失敗。任何系統(tǒng)需要文檔轉(zhuǎn)換的系統(tǒng)都會訂閱這些事件消息。為了既能建立針對于特定系統(tǒng)的消息，也能建立不針對于特定系統(tǒng)的消息，請求轉(zhuǎn)換的系統(tǒng)可以在轉(zhuǎn)換請求命令中使用相關(guān)ID（correlation ID），和/或?qū)⒚?值對頭添加到傳出的轉(zhuǎn)換請求命令消息中。這些頭信息始終會被附加到由Shuttle所發(fā)送的任何相關(guān)消息中。

一旦完成了所有需要的文檔轉(zhuǎn)換，就會給Shuttle OvaFlo終結(jié)點發(fā)送一條命令消息，用以在IBM FileNet Process Engine（流程引擎）中創(chuàng)建索引工作流實例。OvaFlo是由Ovations Group公司開發(fā)的一款元工作流（meta-workflow）框架產(chǎn)品。

為了執(zhí)行實際的索引，用戶會訪問基于網(wǎng)絡(luò)的索引應(yīng)用程序。此應(yīng)用程序會從OvaFlo終結(jié)點中得到下一個可用索引工作流實例，并顯示相關(guān)文檔的分類。每份文檔會被鏈接到一個具體的索賠、及輸入的任何其他的相關(guān)索引數(shù)據(jù)。此外，也可以用于處理系統(tǒng)用戶所提出的將某些文檔轉(zhuǎn)換為TIFF格式的請求。當(dāng)把各種分門別類的文檔放置到一個文件中時，此功能就特別有用。一旦用戶覺得對數(shù)據(jù)很滿意，就可以提交該任務(wù)以示完成。這一步是通過發(fā)出一條命令消息后異步處理的，以便讓用戶可以立即繼續(xù)處理下一索引任務(wù)。

在某些情況下，會發(fā)現(xiàn)來自web前端的工作卻在后臺系統(tǒng)工作中排隊。譬如文檔轉(zhuǎn)換就是這種情況，其中在從前端發(fā)起請求之前，來自送達郵件的所有需要的轉(zhuǎn)換都在被處理中。我們通過通用主機，使用相同的編譯程序集 ，就可以簡單安裝一個單獨的Shuttle Document Conversion（文檔轉(zhuǎn)換）終結(jié)點，不過我們要修改此終結(jié)點的配置，以便使用其自身隊列。然后前端將轉(zhuǎn)換請求發(fā)送給這個高優(yōu)先級終結(jié)點，接著那些轉(zhuǎn)換會得到及時地處理。而所有的后臺轉(zhuǎn)換仍會被發(fā)送至原有的終結(jié)點。

因此，在這個例子中，Shuttle被用于將不同的系統(tǒng)粘合到一起。由于該系統(tǒng)具有所需的內(nèi)置容錯能力，因此它比前一系統(tǒng)要穩(wěn)定得多。而且由于沒有積壓工作被創(chuàng)建出來，因此系統(tǒng)性能非常出色。

結(jié)論

Shuttle為你在實現(xiàn)企業(yè)服務(wù)總線（ESB）時提供了另一種自由選擇。這個項目托管在CodePlex上：

• 項目網(wǎng)站
• 維基
  

優(yōu)點：

• 新項目
• 高度可擴展
• 免費開源軟件
• 命令行管理程序

缺點：

• 新項目
• 必須手動處理進程狀態(tài)數(shù)據(jù)

隨著時間的推移和社區(qū)的支持，出現(xiàn)了各種不同的實現(xiàn)可用于擴展，其中包括更多的隊列、依賴注入（DI）、及其他選擇。

?

原文轉(zhuǎn)自這里, 英文原版

轉(zhuǎn)載于:https://www.cnblogs.com/bibiKu/archive/2013/04/03/2998133.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的.Net开源 Shuttle（飞梭）服务总线（ESB）入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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