總線技術究竟該不該用？

今天的企業應該為總線技術的使用操心嗎？Tom Nolle通過檢視包括老企業服務總線在內的總線的角色回答了這個問題。

曾幾何時企業服務總線（ESB）被視為企業IT的核心。今天，不僅ESB受到了比被廢棄還要糟糕的攻擊，若干開發趨勢似乎對更簡單的消息總線也發起了質疑。在本訣竅提示中，我們將探討這個關鍵問題：總線技術該不該用，如果不該用，替代方案是什么？

總線還是不總線？要想回答這個問題，我們先從理解總線的類型和價值開始，然后再看看針對當前的分布式應用和Web應用有哪些替代方案，最后再看看如何同時做到總線和非總線并存。

IT總線技術是用來對軟件要素進行解耦的，解耦后的要素以事務或消息的形式配合處理工作。總線架構不是從特定目的地來源發放工作，而是把工作放到總線上，并讓合適的流程取走工作。這種做法比傳統設計更加敏捷，因為后者的組件之間要顯式地相互調用，這樣哪怕簡單得變化也會傳導到應用的整個結構內。

總線技術已經演變

現在的總線技術無疑是從分布式流程提供簡單交互手段的基本型消息總線演變過來的。隨著時間的轉移，越來越多復雜的功能已經被添加進來，提供對信息的格式控制以及流程的注冊。還有一種轉變是從簡單的總線方法，即每個消息通常只有一個目的地，轉變為可支持多個的代理結構，在很多情況下也提供發布和訂購的靈活性。這一演變引起了對何為消息系統的相當大的困惑，而這也是面向消息中間件的一般概念背后的一個驅動力。

今天，我們有歸類為消息的總線，也有歸類為服務的總線，后者包括了ESB。所有目前的產品相對于早期總線的基本功能集已經追加了相當一部分功能，這種功能增加得越來越多（有人稱之為膨脹），導致了反對總線聲音的反彈。大多數總線都是當作不透明產品提供出來的，哪些使用它們的人也許沒意識到與他們能做的所有事情有關的過載問題，這會導致設計上的悲劇性錯誤，引發性能問題。

總線的基本問題應該是：你是否需要這些功能？總線架構已經演變到支持組件耦合寬松到臨時起意的地步，現在往往會包含有轉換能力去協調接口和邏輯以便駕馭消息。如果你希望組件注冊和工作流協調在運行時完成或不需要軟件架構仲裁就發生的話，所有這一切都很好，但這的確增加了成本和過載。

評估總線先看替代方案

評估總線價值的最好辦法也許是看看替代方案如何。如果你沒有總線替代方案，你就得管理通過某些其他手段進行的組件間的工作轉移。最有名的是店面（storefront）設計模式。一個組件充當“店面”，代理多個通過它來訪問的功能，但這些功能都是被店面抽象化了的，以便對店面用戶不可見。

店面設計模式成為微服務非常流行的一個模式；它們代表了實現微服務的優選方式。店面的使用使得復雜進程被分成為簡單任務，只要是合理的，并且這些任務是按照有用的方式分布，且不會對進程的用戶造成任何影響，怎么分都行。

店面系統的成功依賴于商店的選擇，這意味著功能要向上劃分，以便高層進程可以用商店（store）表示，然后分解為微服務。很容易會定義太多的高級進程，這么做會把進程細節暴露出來，而這些細節有可能會隨著軟件設計演變或甚至在虛擬化或云計算的使用中被改變。

現代WebyuREST組件化、API設計的組合，再加上微服務和店面設計模式的使用，有可能幾乎在任何情況下消除新應用對總線的使用。軟件架構師的問題是沒有太多可以利用的機會來測試這一理論。現在大多數的開發都會與現有設計發生相互作用或影響，而后者往往都是基于總線的。

必要時刻假定你要進行總線化

總的來說，最好的辦法是，在必須如此的時候假定你會進行總線化。今天的應用演進聚焦在移動和Web訪問驅動的功能性演進，以及虛擬化和云推動的資源動態化上。處理這兩種你有可能就能有效處理好用不用總線的問題。

對于Web和移動功能演進，你可為已有應用開發前端元素，采用店面-微服務架構，然后把結果提供給傳統基于總線的應用后端，讓它來進行處理，從而保留現有的軟件。最好的處理辦法是，把Web流終結到一個組件里面，用它來管理無狀態前端要素的狀態，然后用對靜態數據結構的支持來隔離連接總線的組件，免受前端變更的影響。

對于資源動態化的演進，預期你的問題大多數情況下會是支持負載變化下的組件實例伸縮性上，或者在出現失敗的情況下替換實例。要處理這個問題，可考慮開發新的連接總線的組件，讓它充當某用來為水平伸縮性和故障切換服務的微服務集的店面。最終，你可能用多個店面中的一個來替換掉總線結構。

如果使用得當，服務和消息總線可改善安全性和合規性管理。如果你已經在靠總線技術來支持這些任務，現在打算不用總線，那你就得在安全和治理相關方面增強你的應用生命周期管理實踐，否則就會有連累到信息和業務流程的風險。不要一下子跟風去上全新的流行技術，總線也有自己的好處。