应用系统集成-Spring Integration

应用系统集成-Spring Integration

图1 EIP 消息系统模式全景图。

Spring Integration 是系统集成的一个实现框架，提供了对EIP核心概念：Endpoint、Message、Channel、Router、Translator的抽象及相关框架实现，使得基于Spring Integration进行应用系统集成的应用开发专注于业务服务的实现，而能够轻便的使用集成相关的模式实现。

先提出结论：个人看法，Spring Integration 在非集成领域，业务领域模型内部的设计和实现上才有意义。

Spring Integration 编程模型

图2 Spring Integration 系统集成编程模型

Spring Integration编程模型说明：

1. Channel（通道）:以字符串形式的通道命进行标识。通道指MessageChannel的具体实现类型，如DirectChannel，其他所有的组件都是关联到特定通道上。通道在Spring Integration中是统一的逻辑，单可以从理解上将通道划分为集成技术通道和逻辑通道两部分。

图3 通道简图（集成技术通道和逻辑通道）

1. MessagingGateway（消息网关）: 面向业务领域层提供的集成层接口，接口以业务领域模型的知识提出， 不揭示集成层的任何集成技术细节。

如：以下的接口定义了下单的集成接口，而不展示任何关于集成技术的知识。

1. ServiceActivator（服务激活器）：处理通道上消息的服务

如：以下表示一个业务逻辑通道处理服务，接收输入通道：tickers上的输入，并返回一个quote对象到输出通道quotes上。

对于负责具体集成技术的通道，ServiceActivator返回一个MessageHandler的实现了，具体实现类由Spring Integration各类协议实现提供。如以下是Http发送通道的处理服务，表示将通道httpOutRequest上的消息通过Http协议发送至目标地址。

1. InboundAdaptor/OutboundAdator 和 InBoundGateway/OutBoundGateway：通道输入输出适配器或则通道输入输出路由,由具体集成技术来实现，用于接收从外部传入应用的消息或从将消息从应用发送出去， Adaptor是指单向通讯（发送后不管），而gateway指双向通讯（发送后通常等待响应）

以http协议实现为例：

关于Spring Integration支持的集成技术文档见：

https://docs.spring.io/spring-integration/docs/current/reference/html/endpoint-summary.html#spring-integration-endpoints

1. Bridge：桥接，将通道消息桥接到目标通道；
2. Router: 路由器，负责将来源通道上的消息路由到不同的目标通道
3. Tranformer： 转换器，将来源通道上的消息转化后发往目标通道
4. Splitter： 分流器，只将一个消息分流为多个小消息发往目标通道。如，下面例子中将订单转换为订单行信息发往目标通道。

1. Aggregator：聚合器，和Splitter相反，将来源通道上的多个消息转换为一个消息发往目标通道。
2. Filter：过滤器，对通道上的消息进行过滤。

Spring Integration 真正内核

Spring Integration将应用和数据库、消息中间件、邮件服务器、缓存（Redis）、其他应用系统等任何系统的交互都纳入一个统一的消息集成模型中进行抽象设计。

以缓存的场景描述如下：

   

Spring Integration框架的是领域驱动设计理念的产物，将应用集成和业务领域模型划分为不同的上下文。和传统设计的差异在于将应用集成作为一个专门的领域去进行抽象设计（消息集成模型）。传统的设计中功能组件通常以工具的角度出现，不同的功能组件，如缓存、消息中间件等都以独立的目的使用。

简单的说： Spring Integration期望大家以统一的方式去处理所有系统的集成。任何系统之间的集成都可以认为是消息在系统间按照特定的模式进行传递。

Spring Integration 是一个设计理念的产物，对于开发人员来说可以说并不产生新的功能性作用。

Spring Integration 还有意义吗？

Spring Integration对于产品实施还有意义吗？首先：应用集成模型并不是核心业务模型。是否需要独立抽象存在争议；其次:在特定系统的集成领域，都存在成熟和稳定的使用实践， 比如微服务网关、Http协议的Feign组件、 数据库的ORM模式、多级缓存等。这些功能组件由于目的和习惯的差异，有着各自的集成方式，全部以消息集成的思维去理解和使用反而带来歧义。

    比如： 数据库操作的Service-Dao-ORM框架mapper层的三层结构已根深蒂固，并有着优秀的框架，如mybatis。 而期望以Spring Integration的设计理念来重新实现可以说是完全不可行的。

    区别稳定点和变化点是系统设计永远的第一准则。从这个角度分析，我们发现应用和技术组件的通讯是稳定的，比如和数据库，消息中间件，缓存等系统的交互方式在系统的生命周期中并不会或很少发生变化，即使由于业务带来的技术需求的变化也会在迅速的技术调整后保存稳定。因而针对这部分实现进行抽象、过多考虑所谓扩展性对于应用系统来说就是过度设计了。

   

    而对于业务系统来说，业务规则的是变化点。 因此在业务领域模型内部的业务逻辑实现中采用Spring Integration或使用其设计理念来才是有意义的。

    结论：个人看法，Spring Integration 在非集成领域，业务领域模型内部的设计和实现上才有意义。

    比如对于采购招标的业务从原来流程化设计理念转换为消息集成设计理念可以带来灵活的扩展性面对复杂多边的规则。如抽取未定的消息： 招标消息、报价消息、定标消息。将灵活多变的业务规则适配到领过的通道编排和消息处理上。

如下是供应商报价消息处理的示例。