本次梳理的相关知识点包括jms，amqp(rabbitmq)，sping-messaging，spring-integration，springcloud-stream，这些都是与消息message相关的内容，它们有什么区别与联系呢？

      相关的要点与相互关系都整理在如下图中，如有不对欢迎指正：

一、关系图：

        左边是jms与amqp(rabbitmq)，以及spring的使用，下面是所基于的spring-messaging的消息规范。右边是spring的消息集成integration架构，重点展示了与jms/amqp的集成，以及显示出对左边的特定目标下的使用方法，同时也是基于并扩展了spring-messaging规范。

        右上边是springcloud-stream，展示出公共机制使用了spring-messaing与integration中的扩展。因为不涉及外部，必须统一用spring自己的规范了。另外的binder部分，使用了与amqp集成时，已有的一些类，比如endpoint/container...。

二、梳理的目标

        从这个图上，显示出spring自己定义的规范是基础。以及基于已有的实现，开发进一步功能时应该基于哪部分，比如message定义应该基于spring-message。这样不至于重复开发，不至于自创不规范内容，不至于乱了这套spring的统一定义/扩展/整合/转换的理念。

三、几部分的细述：

1、常见的jms与amqp：

1.  左边有两部分，分别是jms与amqp。jms API代表了消息接口规范，而amqp代表了一个与消息中间件的通讯协议。这就是差别，不过也可以实现一个jms的客户端，通过amqp与中间件通讯。而实现jms的客户端，其实可以通过其它协议与消息中间件通讯。可以参考jdbc规范，很多db提供了jdbc的实现，但客户端与db的通讯协议是什么，可以不去关注。但为什么要关注amqp呢？因为提供了更高级的功能，不一样的使用方式。那么也可以搞一个amqp的api出来吧。后面spring-amqp中就有了。
2. 在spring中，对jms与amqp都实现了支持，分别是spring-jms与spring-amqp(spring-rabbit)以方便使用。如同使用jdbc时，spring提供了jdbcTemplate，spring-jms与spring-amqp也提供了对应的template，不过各提供了两个。比如spring-jms中有JmsTemplate与JmsMessagingTemplate。这就与spring-messaging中，统一规范message有关了。JmsMessagingTemplate可以发送spring的message，内部转换成jms的msg了，再用JmsTemplate发出去。另外，还有相似的@EnableJms与@EnableRabbit这样的注解。
3. 对于spring-jms的细节，可以看以前写的这个博文：

  spring-jms的接收消息功能的设计思考_spring cloud jms-CSDN博客文章浏览阅读467次。1、前言JMS即Java消息服务，面向消息中间件的API。本文研究过源码，试着分析一下如何从基本的使用方式，到整合进spring的方式的思考，来提高自己的系统设计能力。只分析消息接收处理过程，话说spring-jms是整合jms的使用，而springcloud-stream是自己实现了一个发送接收过程，通过设计binding对接消息中间件上。2、jms接收消息jsm是标准接口，具体的产品..._spring cloud jmshttps://blog.csdn.net/herriman/article/details/105205614

2、spring的基础消息定义：spring-messaging

1. Spring Framework 4 包含了一个新的spring-messging模块。spring-messging就是spring自己的消息规范，定义了message的格式，还定义了一些相关的channel。其中base定义了消息Message(MessageHeader和body)、消息处理MessageHandler、发送消息MessageChannel。上面的spring-jms与spring-amqp中，就使用了这些spring规范作为支持。所以spring-messging就是spring的消息底座，基础规范，统一格式。
2. 另外还有STOMP协议的简单消息协议的通用支持。STOMP是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理(Broker)进行交互，类似于OpenWire(一种二进制协议)。由于其设计简单，很容易开发客户端，因此在多种语言和多种平台上得到广泛应用。其中最流行的STOMP消息代理是Apache ActiveMQ。
3. 一方面提供了通过TcpOperations建立tcp connection、通过TcpConnectionHandler处理消息和通过TcpConnectionf发送消息的抽象及实现；另一方面包含了对基于Reactor的tcp 消息支持。

3、springboot-*-starter自动配置

1. 针对jms与amqp，在springboot自动配置框架下，都有对应的starter。图中左下的两个黑色框。

4、spring-integration消息集成

        右边主要是spring-integration的内容，典型的与jms以及amqp的集成，当然也可以与消息中间件没有关系。既然是spring自己的方案，公共部分必然基于spring-messaging中的消息规范，不同的地方要进行convert转换，此外还要扩展一些spring公共的实现，比如多种channel实现。当然还要使用已经有的spring-jms与spring-amqp中的template/listener/containner等，不至于重复开发，再补充上集成特有的gateway/adapter等。这样组合出完整的集成目的的架构。

1. integrating与消息中间件没有关系，它只是集成系统时，设计了一套channel/inbound/gateway/adatper（单向/双向）的架构。比如web系统也可以用消息机制集成。Spring Integration将应用和数据库、消息中间件、邮件服务器、缓存（Redis）、其他应用系统等任何系统的交互都纳入一个统一的消息集成模型中进行抽象设计

2. 消息传递和事件驱动架构不一定需要使用消息中间件系统。Spring Integration可以独立作为构建消息传递解决方案的框架。在没有外部集成要求的简单应用程序中，生产者和消费者组件可以通过消息通道解耦，这样它们就只与消息通信，而不是直接调用带参数的方法。消息传递实际上是一种范式；无论消息传递发生在同一进程内运行的组件之间，还是发生在不同系统上不同进程下运行的组件间，都适用相同的基本原则。

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

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

5、springcloud-stream

1. 它是springcloud微服务体系中的消息机制。使用分布式中间件rabbitmq为例。首先它不直接绑定各消息中间件，而是通过binder。binder一方面关联着通用的channel，另一方面关联着特定消息中间件的endpoint。通用框架的功能部分肯定使用spring-messaging以及已经在spring-integration中扩展的类。
2. 而特定的绑定消息中间件的部分，已经有了spring-amqp(spring-rabbit)了，在这基础上，在spring-integration-amqp中，还有更进一点实现的AmqpOutboundEndpoint等内容。当然依赖这些已有的去实现特定的功能。还有特定的消息handler，基于抽象类AbstractMessageHandler来实现，所以工程的包依赖就是这样。再补上连接参数以及自动配置。就差不多了。