采访与书评：Spring Integration in Action-InfoQ

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

作者对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 经常在一些会议和关于消息系统、数据、集成以及云计算的用户组发表演讲。