目前的應用整合專案基本上都會基於服務匯流排產品(或商用或開源)進行實施的，有些使用者或許是之前深受點對點硬編碼整合之害，在通過服務匯流排/SOA實施整合專案時，會要求所有的系統之間互動全部通過服務匯流排實現。當專案真正上線執行時，卻會發現各種各樣的問題，嚴重的甚至出現整合伺服器宕機，嚴重影響業務的執行。

出現這種問題的原因，就是因為客戶在做整合時，沒有搞清服務匯流排的優劣勢，雖然服務匯流排是專門用於應用整合的，但是還是有一些整合的場景“不應該”使用服務總來實現。如下就是一些需要慎重使用服務匯流排的整合場景。

l  大報文傳輸

大資料量的傳送或查詢，比如BOM資料的傳輸，查詢過去一年的訂單等。在這樣的資料傳輸，如果使用服務匯流排，需要把大量資料打包到一個服務(比如Web Service，REST等)報文中。根據多數服務匯流排產品的特性，這樣的傳輸服務可能會長時間的在伺服器中佔用記憶體和執行緒資源，一旦出現大併發的情況，輕則會拖慢服務匯流排的效能，嚴重的可能會引起宕機。一般情況下，用HTTP報文包超過1MB，用JMS報文包超過5MB，就需要慎重考慮使用服務匯流排，可以考慮採用ETL或直連方式進行傳輸。

l  大檔案傳輸

與大報文傳輸類似，不要將檔案打包到服務報文中(比如Web Service的attachment中)進行傳輸，原因與大報文相同。建議採用FTP或者其他方式在服務匯流排之外實現檔案的傳輸。目前市面上，很多服務匯流排產品是能夠支援FTP協議的，可以通過服務匯流排操作FTP伺服器進行檔案傳輸。

l  系統內部的整合

曾經在專案中見過這樣的情況，客戶的某業務系統提供有多個服務介面(Web Service)，在實現整合時，需服務匯流排將該系統的這些介面進行組合呼叫，生成一個新的介面，供其他業務系統進行呼叫。在這個場景中，服務匯流排實現的完全是業務系統內部服務的編排與排程。對於這種情況，我更建議讓業務系統內部進行改造，增加一個這樣介面，然後再由服務匯流排進行封裝，供其他系統呼叫。因為，由服務匯流排進行系統內部介面排程效能遠不如系統內部的呼叫，如果介面互動的資料量比較大，並且邏輯比較複雜的話，那由服務匯流排進行組合呼叫後的介面效能會更加糟糕，同樣可能會拖累服務匯流排的執行。

l  複雜的業務邏輯

通過服務匯流排關聯多個系統的實現應用整合，在服務匯流排中承載的是整合邏輯，比如轉換、路由等，而不要去實現複雜的業務邏輯。曾經見過客戶的一個應用整合場景在服務匯流排中使用數十個整合元件來實現，編寫的很複雜的業務邏輯，而這個服務整合每次至少需要幾十秒中才能夠完成。這種服務在業務量增大時，也會大大拖累服務匯流排的效能，帶來潛在的危機。

l  高頻次資料傳輸

雖然很多服務匯流排產品都有不錯的效能，但是對於一些對效能要求很高，但是又沒有什麼格式轉換和監控需求的整合(比如一些裝置資料的實時採集場景)，我們也可以考慮不適用服務匯流排，直接採用直連方式，比如使用JMS或者Tuxedo之類高效能的傳輸方式進行對接。

以上是幾個需要慎重使用服務匯流排場景的簡單總結，供大家參考。總之，我們在應用服務匯流排時，需要讓服務在執行時儘量短時間的佔用服務匯流排記憶體和執行緒的資源，避免服務匯流排的阻塞，最大限度的保證服務匯流排的順暢執行。

歡迎關注我的微信公眾號：