MuleSource CTO 给出是否选用 ESB 的检查清单

在 InfoQ 的网站上已经有了很多关于 ESB 的新闻和文章。然而，只要 ESB 还是当今企业应用领域的热点，关于它的报导肯定还会延续下去。最近，MuleSource 的 CTO Ross Mason 发表了一篇题为《用还是不用 ESB》的博文，他在文中给出了是否在项目中选用 ESB 的检查清单。

这篇文章并非 Ross Mason 的心血来潮之作，而是对 ThoughtWorks 员工 Erik Dörnenburg 的博文《让 ESB 的痛苦曝光》的回应。在这篇博文中，Erik 描述了一个典型的“简单问题复杂化”的例子：使用 ESB 来集成两个应用，而且只有两个。采用 ESB 的理由是架构师期望能让程序适应未来可能出现的变化。这似乎没什么问题。然而，在和项目的发起人经过一番交流之后，Erik 开始怀疑 ESB 的必要性；开发者对此的反应则是“只有痛苦”，ESB 不仅没有给项目带来好处，反而使它有延期的危险。通过对比引入 ESB 和没有 ESB 情况下的两副图，Erik 展示了引入 ESB 所带来的复杂性，并认为此项目中的 ESB 纯粹是“简历驱动开发（Resume-Driven Development）”的结果，这种开发方法的唯一目的就是要得到一份漂亮的简历（CV）。

在引用完 Erik 的博文之后，Ross Mason 给出了用于判断是否选用 ESB 的检查清单：

1. 你是否在集成至少 3 个应用 / 服务？如果你只需要在 2 个应用之间进行通信，使用点对点集成会更简单。
2. 你是否真的需要在未来插入更多的应用？尽量避免架构中有多余之物。更好的方式是保持简单，然后在需要时再重新构架。
3. 你需要使用的通信协议类型是否多于 1 种？要是你只使用 HTTP/Web 服务或只使用 JMS，那么你就无法从 Mule 提供的跨协议消息传递和转换中得到任何好处。
4. 你是否需要消息路由功能，如分裂（forking）和聚合（aggregating）消息流，或基于内容的路由？许多应用并不需要这样的功能。
5. 你是否需要发布服务供其他应用消费？这非常适合用 Mule，因为它提供了一个健壮和可伸缩的服务容器，但是在 Erik 的用例中，他们所需要的只是一个来自他们前端 Struts 应用的 HTTP 客户端。
6. 你是否有超过 10 个的应用要集成？避免大爆炸式的项目，考虑把这种项目分割成更小的块。首先把你的架构在 3 到 4 个系统中进行试验，在它对其他系统产生影响前把所有问题都搞定。
7. 你是否真的需要 ESB 的伸缩性？应用的伸缩性需求非常容易被过度构架。Mule 对伸缩性的支持使它成为了“内建”伸缩性的流行选择。但是，这要付出代价，因为你给架构中增加了一种新技术。
8. 你是否确切地理解了架构的目标？厂商往往把 ESB 描述成一个盒子，有许多应用环绕在其周围。实际上，这并不是它的工作方式。围绕集成点、协议、数据格式、IT 基础设施、安全等一开始有大量细节需要了解。从小做起有助于控制问题的范围，使莫名其妙的问题降至最少。在你了解你的架构并适当地划定范围之前，你都无法真正判断 ESB 是否对你合适。
9. 通常来说，总要验证产品解决方案是否符合你的需要。不要选择 ESB 或其他任何技术，仅仅因为：

• 让你的简历好看
• 虽然今天我不需要这些特性，但是将来有一天我可能会用到它们
• 我和销售们的老大一起渡过了一个相当不错的高尔夫周末

对于 Ross 的清单，Erik 评论说

绝佳的检查清单，我完全同意；只要出于合理的目的使用象 Mule 这样的 ESB，就能极大地简化项目。然而不幸的是，我们仍然可以看到许多架构甚至连你单子上的第一条都通不过。而且，这正是我在写我的那篇文章时所想到的。

孙子曰：“兵无常势，水无常形”。ESB 的存在并非就意味着你非得在项目中使用它。Ross Mason 的清单可能不太全面，可能带有个人偏见，但是它绝对有助于缓解“ESB 强迫症”。