文章： 采访与书评：Spring Integration in Action

Mark Fisher，Jonas Partner，Marius Bogoevici以及Iwein Fuld合著的 《Spring Integration in Action》一书介绍了 Spring Integration框架，该框架基于 Spring编程模型提供了众所周知的 企业级集成模式（Enterprise Integration Pattern，EIP）的一种实现。在基于Spring的应用中它实现了轻量级的消息传递并支持使用声明式的适配器实现应用集成。

相关厂商内容

SpringOne首次空降中国·北京Spring&CloudFoundry，12月7~8日，限额免费报名中

QCon全球软件开发大会2013(北京)，18主题近百位讲师，11月26前6折优惠报名

Web开发国际权威专家Douglas Crockford，确认参加QCon北京2013大会

百度技术沙龙第三十二期：讲讲地图开发那些事（11月17日 周六）

2012RIA天地行•西南游戏开发者大会11月25日，火热报名中

相关赞助商

SpringOne大会于12月7~8号首次落户北京，免费限额报名中， 了解详情！

作者对Spring Integration框架的讨论是从异步消息架构的核心组件开始的：Message、Channel以及Message Endpoint。正如他们在第1章中所言，Spring Integration就是“企业级集成模式遇到了控制反转（Inversion of Control）”。作者通过示例应用和代码样例详细讨论了企业级集成模式以及Spring Integration框架是怎样实现这些模式的。

本书还涵盖了Spring Integration提供的对邮件和文件适配器、Web服务以及使用Spring Batch框架对文件进行批处理的支持。为了使讨论更完整，作者还谈及了使用JMX实现对消息组件的监控和管理。最后，本书讨论了测试的话题，谈及了怎样通过模拟（mock）服务来实现对异步系统和消息组件的测试。

InfoQ与Mark Fisher和Iwein Fuld讨论了这本书以及Spring Integration框架的优势和局限性。

InfoQ: 有这样一种趋势，就是将应用集成作为基于云的服务。你能介绍一下这种“集成即服务（Integration as a Service）”的新理念吗？Spring Integration框架能够怎样提供帮助？

Iwein: Spring Integration本身并不是什么“服务（as a Service）”。这是一件好事儿。作为开发人员，你感兴趣的是与其他*aaS API集成，而使用ESB作为混合服务通常并不会简化什么事情。在服务架构中，使用Spring Integration是很容易的，在云中何尝不是如此呢。SI的优点在于集成而不是服务。就是说，Cloud Foundry对Spring应用提供了原生的支持因此也就支持了Spring Integration，它还提供了Spring Integration支持的服务——如RabbitMQ、Redis、MongoDB以及关系型数据库——所以对你来说所有的可能性和例子都是信手拈来的。

InfoQ: 在消息架构中，使用NoSQL数据存储是不是通常比关系型数据库更好，比如在Queue Channel和Messages Store中存储消息？在消息应用中，使用NoSQL数据库进行持久化的优缺点是什么？

Iwein:如果你使用NoSQL存储的话，在写以及简单的“按键值”查询的时候通常会有点优化。NoSQL存储与消息模型的配合更为自然。也就是说，对于关系型数据库来说针对这种使用方式进行优化也不是很难的事情，所有说选择Spring Integration作为消息框架并不是选择NoSQL存储的决定性因素。

Mark: 另外，NoSQL存储并不是放之四海皆准的，因此更有意义的讨论是通过为不同的NoSQL存储提供适配器，让Spring Integration支持更为广泛的应用。例如，使用我们在2.2版本中添加的Channel Adapter，你可以很容易地以消息驱动方式更新Redis ZSET中的score。

InfoQ: 在有效且高效地处理和分析不同类型的业务数据方面，大数据、数据挖掘以及数据处理最近得到了很多关注。Spring Integration和Spring Batch框架是如何适应大数据领域的呢？

Iwein: 如果你想基于用后就扔掉的代码快速得到结果的话，那Spring Integration和Spring Batch可能并不适合你。但是，如果你想要的是一个可维护的解决方案，那它们就适合了。长期存在的应用程序通常更看重可维护性而不是快速推向市场，Spring组合产品正是能够在这类应用中发挥其价值。在大数据领域，很多事情都是容易发生变化的。通常的解决方案会快速完成、收回投资然后丢弃掉。如果你们的应用是这样的话，那尽可以忽略Spring Integration。

Mark:但是，我们开始设计的3.0版本的一个主题就是对大数据的支持。它不仅会包含HDFS适配器、为Apache Hadoop项目无缝集成Spring，还可能会包含将disruptor model应用于socket层次的连接工厂这样的特性。结合Spring Integration的低开销特性，应该能够满足很多大数据解决方案的吞吐量需求。另外，在探索“现实世界”大数据场景的时候，我们认识到，最终需要解决的通常是集成问题：结合来自多个数据源的数据、定义跨不同系统的数据流动、创建多个处理步骤的流水线等等。很明显，在处理“传统”企业级集成时所用的工具和框架是可以用在这里的。

InfoQ:安全是企业级应用开发中很重要的一个方面，在集成用例中更是如此。您能介绍一下Spring Integration为保护各种消息组件所提供的安全支持吗？在这个领域的最佳实践是什么？

Iwein: 在消息系统的安全要么在传输层做，要么在消息层做，要么在两者上都做。很酷的一点是Spring Integration在这两方面都涉及到了。鉴于SSL HTTPS之下就是HTTP了，所以SI本身不需要知道这些。在消息层，Spring Integration将安全问题委托给Spring WS的安全组件。这样很好，我们本身躲过了这个问题。在我看来，如果关心安全的话，你要保护好消息。你只需要保证最终的接受者和最终的发送者是可信的，而不需要为整个网络拓扑负责。很多组织走的是另外一条路， 他们完全忽略了消息层的安全，因为他们认为“管好传输层就好了”。这是很愚蠢的做法，就像安装操作系统的人没有给你安装键盘记录器那样，但现实中这种做法却广泛存在。安全领域的最佳实践就是时刻保持警惕，别相信什么最佳实践。

Mark:Spring Integration还提供了Channel Interceptor，它只是简单地委托给了一个Spring Security授权管理器，但是如果SecurityContext上已经填充了来自传输层的可用信息的话，通常还会加以检查。

InfoQ: 在书中你们也讨论了如何测试消息应用中的不同组件。能介绍一些这方面的技术吗？Spring和 Spring Integration框架怎样简化对消息组件的测试的？

Iwein: 相当清楚，第18章就是关于这一点的。在我进行SI测试并编写这一章时，最让我大开眼界的事情就是若想了解多线程应用程序是如何工作的，使用调试器并不是什么好主意。意识到这一点后，我不再使用调试器，转而按照自己的思路来修复测试和日志。在学习调试上浪费了太多时间，而且在意识到问题之后相关知识就被直接丢到九霄云外了，这是让人震惊的。

另一件值得一提的事情是，大多数的并发问题都能通过精心设计的测试用例触发。我和Mark经常因为无法重现彼此的问题而工作到深夜，但是只要我们愿意付诸行动，总会有办法确定测试用例。相对于一般的功能测试，这会花费更多的时间，你要有所准备，因为在紧要关头这可是会救你一命的。

InfoQ: EIP（企业级集成模式）的局限性是什么，换句话说集成架构师或开发人员在他们的应用程序中使用这些模式时要注意什么？

Iwein: 写在书中的事情有一个问题就是，你不必保证它们解析和编译成实际代码时是否严谨。在写这本书中，我们纠结过很多次，但是在实现SI的时候，我们也纠结于EIP这本书。当设计架构时，架构师需要记住的是将来的代码会看起来有所不同，而开发人员应当记得新兴的框架要像低层次的代码那样干净。EIP更大意义上是开始时的指南，实际工作的代码要胜于它，即使代码中的模式与书中的模式有所不同。

Mark: 另外，当涉及到设计模式时，通常语言是最重要的。语言使得开发人员能够将其所学转化为给定API。因此，当要确定某个属性的名字或配置特性的时候，我们会查看EIP这本书并希望从那里使用的单词上获取灵感。一致性也是很重要的，所以每当要将特定的模式映射到我们的API并遇到困难时，我们会尝试使用类似的技术和术语。

InfoQ: 你们能否介绍一下企业级应用集成领域的发展趋势吗？

Iwein: 主要的趋势（依然）是REST。因为JavaScript框架和浏览器已经规范化了，所以HTTP才刚开始发挥其全部潜力。另一个有意思的趋势就是通过远离既有的做事方式来优化效率，这个趋势我见过好几次了。这可能对移动设备、片状网络（flaky network）有所助益，但是对于那些看似不太可能的设备（如家庭能源测量装置）也是有所裨益的。Spring Integration的TCP/UDP适配器可能在这样的情况下派上用场。

Mark: 除了REST API，基于Web并使用Web Socket的消息系统以及诸如SockJS的高层次抽象也是越来越流行了。这种技术为应用集成打开了一个全新的世界，在这里客户端/服务器的关系戏剧性地发生了变化。在Spring Integration 3.0的路线图中这也是我们关注的一个焦点。

作者们还谈论了应用集成的通用知识和最佳实践。

Iwein: 我不赞成复杂的应用，尽管它可能是通过复用我的代码实现的。很多开发人员认为他们可能需要异步处理，所以他们使用了SI、Camel或Akka。最后，往往没有严格的评估来确认单线程的解决方案是否满足需求。不要因为你能使用一项很酷的技术就干这种傻事。不要误会我的意思，SI是很不错，但是如果你能远离并发的话，那你最好还是远离它。

Mark: 也就是说，当消息驱动的模式确实能够满足你需求的话，Spring Integration为你隐藏了大多数的复杂性。为了优化性能，你还是需要理解如何配置线程池和触发器，但是你不需要编写处理任务调度和异步调用的代码。而是像其他的Spring应用那样，你只需要关注业务域的POJO。这也意味着你的代码能够与基础设施解耦合进而便于测试，这也是我们可能都认可的“最佳实践”。

关于作者：

Mark Fisher是Spring Integration项目的创建者。目前他在VMware仍然领导着Spring Integration的开发，同时还探索大数据和消息系统的结合。他是许多Spring项目的提交者，包括Spring框架本身和他参与创建的Spring AMQP。Mark经常在一些会议和关于消息系统、数据、集成以及云计算的用户组发表演讲。

Iwein Fuld 是一个独立顾问，关注高质量开发以及团队培训。他是一个多面手，但是总能保持对服务端集成问题和算法的关注。Iwein从2008年初就是Spring Integration项目的提交者。除了是TDD和并发方面的专家，Iwein尤其喜欢组建敏捷团队和精益创业。

查看英文原文： Interview and Book Review: Spring Integration in Action

感谢 臧秀涛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至 [email protected]。也欢迎大家通过新浪微博（ @InfoQ）或者腾讯微博（ @InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。