总线技术究竟该不该用？

今天的企业应该为总线技术的使用操心吗？Tom Nolle通过检视包括老企业服务总线在内的总线的角色回答了这个问题。

曾几何时企业服务总线（ESB）被视为企业IT的核心。今天，不仅ESB受到了比被废弃还要糟糕的攻击，若干开发趋势似乎对更简单的消息总线也发起了质疑。在本诀窍提示中，我们将探讨这个关键问题：总线技术该不该用，如果不该用，替代方案是什么？

总线还是不总线？要想回答这个问题，我们先从理解总线的类型和价值开始，然后再看看针对当前的分布式应用和Web应用有哪些替代方案，最后再看看如何同时做到总线和非总线并存。

IT总线技术是用来对软件要素进行解耦的，解耦后的要素以事务或消息的形式配合处理工作。总线架构不是从特定目的地来源发放工作，而是把工作放到总线上，并让合适的流程取走工作。这种做法比传统设计更加敏捷，因为后者的组件之间要显式地相互调用，这样哪怕简单得变化也会传导到应用的整个结构内。

总线技术已经演变

现在的总线技术无疑是从分布式流程提供简单交互手段的基本型消息总线演变过来的。随着时间的转移，越来越多复杂的功能已经被添加进来，提供对信息的格式控制以及流程的注册。还有一种转变是从简单的总线方法，即每个消息通常只有一个目的地，转变为可支持多个的代理结构，在很多情况下也提供发布和订购的灵活性。这一演变引起了对何为消息系统的相当大的困惑，而这也是面向消息中间件的一般概念背后的一个驱动力。

今天，我们有归类为消息的总线，也有归类为服务的总线，后者包括了ESB。所有目前的产品相对于早期总线的基本功能集已经追加了相当一部分功能，这种功能增加得越来越多（有人称之为膨胀），导致了反对总线声音的反弹。大多数总线都是当作不透明产品提供出来的，哪些使用它们的人也许没意识到与他们能做的所有事情有关的过载问题，这会导致设计上的悲剧性错误，引发性能问题。

总线的基本问题应该是：你是否需要这些功能？总线架构已经演变到支持组件耦合宽松到临时起意的地步，现在往往会包含有转换能力去协调接口和逻辑以便驾驭消息。如果你希望组件注册和工作流协调在运行时完成或不需要软件架构仲裁就发生的话，所有这一切都很好，但这的确增加了成本和过载。

评估总线先看替代方案

评估总线价值的最好办法也许是看看替代方案如何。如果你没有总线替代方案，你就得管理通过某些其他手段进行的组件间的工作转移。最有名的是店面（storefront）设计模式。一个组件充当“店面”，代理多个通过它来访问的功能，但这些功能都是被店面抽象化了的，以便对店面用户不可见。

店面设计模式成为微服务非常流行的一个模式；它们代表了实现微服务的优选方式。店面的使用使得复杂进程被分成为简单任务，只要是合理的，并且这些任务是按照有用的方式分布，且不会对进程的用户造成任何影响，怎么分都行。

店面系统的成功依赖于商店的选择，这意味着功能要向上划分，以便高层进程可以用商店（store）表示，然后分解为微服务。很容易会定义太多的高级进程，这么做会把进程细节暴露出来，而这些细节有可能会随着软件设计演变或甚至在虚拟化或云计算的使用中被改变。

现代WebyuREST组件化、API设计的组合，再加上微服务和店面设计模式的使用，有可能几乎在任何情况下消除新应用对总线的使用。软件架构师的问题是没有太多可以利用的机会来测试这一理论。现在大多数的开发都会与现有设计发生相互作用或影响，而后者往往都是基于总线的。

必要时刻假定你要进行总线化

总的来说，最好的办法是，在必须如此的时候假定你会进行总线化。今天的应用演进聚焦在移动和Web访问驱动的功能性演进，以及虚拟化和云推动的资源动态化上。处理这两种你有可能就能有效处理好用不用总线的问题。

对于Web和移动功能演进，你可为已有应用开发前端元素，采用店面-微服务架构，然后把结果提供给传统基于总线的应用后端，让它来进行处理，从而保留现有的软件。最好的处理办法是，把Web流终结到一个组件里面，用它来管理无状态前端要素的状态，然后用对静态数据结构的支持来隔离连接总线的组件，免受前端变更的影响。

对于资源动态化的演进，预期你的问题大多数情况下会是支持负载变化下的组件实例伸缩性上，或者在出现失败的情况下替换实例。要处理这个问题，可考虑开发新的连接总线的组件，让它充当某用来为水平伸缩性和故障切换服务的微服务集的店面。最终，你可能用多个店面中的一个来替换掉总线结构。

如果使用得当，服务和消息总线可改善安全性和合规性管理。如果你已经在靠总线技术来支持这些任务，现在打算不用总线，那你就得在安全和治理相关方面增强你的应用生命周期管理实践，否则就会有连累到信息和业务流程的风险。不要一下子跟风去上全新的流行技术，总线也有自己的好处。