一、AMQP & JMS（MQ前文Redis已讲）
JMS 即 Java Message Service，是 Java 平台上有关面向消息中间件（MOM）的技术规范，它不是一个真正的协议，而是提供了一组用于在不同的应用程序之间进行异步通信的 API 和规范。以下是关于 JMS 的详细介绍：
主要特点
- 异步通信：允许应用程序以异步方式发送和接收消息，发送方无需等待接收方处理完消息就可以继续执行其他操作，提高了系统的性能和响应能力，特别适用于处理耗时较长的任务或需要解耦的组件之间的通信。
- 松耦合：发送方和接收方不需要彼此了解对方的具体实现和位置，它们只需要遵循 JMS 规范来发送和接收消息。这种松耦合的特性使得系统具有更好的可扩展性和灵活性，易于进行维护和升级。
- 可靠性：JMS 提供了多种机制来确保消息的可靠传递，如消息持久化、事务处理、消息确认等。即使在发送方或接收方出现故障的情况下，也能保证消息不会丢失或重复处理。
消息模型
- 点对点（Point-to-Point，P2P）：基于队列实现，消息生产者将消息发送到特定的队列，每个消息只能被一个消费者接收。队列会按照先进先出（FIFO）的顺序将消息传递给消费者，常用于一对一的通信场景，如订单处理系统中，订单生成后发送到一个队列，由专门的订单处理服务从队列中获取订单进行处理。
- 发布 / 订阅（Publish/Subscribe，Pub/Sub）：基于主题实现，消息生产者将消息发布到特定的主题，多个消息消费者可以订阅该主题，从而接收主题上发布的所有消息。常用于一对多的通信场景，如新闻推送系统中，新闻发布者将新闻消息发布到一个主题，多个用户可以订阅该主题来获取新闻。
核心接口和类
- ConnectionFactory：用于创建连接到消息中间件的连接对象的工厂接口，通过它可以创建与不同消息中间件的连接。
- Connection：表示与消息中间件的连接，负责建立与消息中间件的物理连接，在连接建立后，可以创建会话、发送和接收消息等操作。
- Session：用于创建消息生产者、消费者和消息对象的上下文，在一个会话中可以进行消息的发送、接收、事务处理等操作。
- MessageProducer：用于将消息发送到目的地（队列或主题）的接口，消息生产者可以将各种类型的消息发送到指定的目的地。
- MessageConsumer：用于从目的地（队列或主题）接收消息的接口，消息消费者可以通过订阅或获取的方式从队列或主题中接收消息，并进行相应的处理。
- Message：消息的抽象接口，JMS 定义了多种类型的消息，如 TextMessage、ObjectMessage、BytesMessage 等，用于在不同的应用程序之间传递不同类型的数据。
定义与性质
- AMQP：是一个开放的、应用层的消息通信协议，它详细定义了客户端与消息中间件之间的通信规则和数据格式等，具有平台无关性，不仅限于 Java 平台，可以被多种编程语言实现和使用。
- JMS：是 Java 平台上的一套消息服务的规范和 API，主要是为 Java 开发者提供在 Java 应用中进行消息传递的功能，是基于 Java 语言的。
设计目标
- AMQP：侧重于提供高效、可靠、跨平台的消息通信，旨在满足企业级应用对消息传递的高性能、可扩展性和互操作性的需求，尤其适用于分布式系统中不同组件之间的通信。
- JMS：主要目标是为 Java 开发者提供一种统一的、与具体消息中间件实现无关的编程模型，方便 Java 应用进行消息的发送和接收，重点在于简化 Java 应用中的消息处理。
消息模型
- AMQP：具有更丰富和灵活的消息模型，包括交换器（Exchange）、队列（Queue）和绑定（Binding）等概念。消息通过交换器根据不同的路由规则将消息路由到不同的队列中，支持多种路由模式，如直接匹配、主题匹配、扇出等。
- JMS：主要有两种消息模型，即点对点（P2P）和发布 / 订阅（Pub/Sub）。在点对点模型中，消息发送到队列，只能被一个消费者接收；在发布 / 订阅模型中，消息发布到主题，多个订阅者可以接收消息。
协议规范与实现
规范（Specification）
- 定义：规范是对特定技术、产品、流程或系统等的详细描述和规定，它明确了应该遵循的要求、准则、标准和最佳实践等，通常是由相关的行业组织、标准制定机构或企业内部制定的，用于指导开发、设计、实施和评估等工作。
- 示例
- 在软件开发中，Java 语言规范定义了 Java 编程语言的语法、语义、数据类型、操作符等内容，开发者需要按照这个规范来编写 Java 代码，以确保代码的正确性和可移植性。
协议（Protocol）
- 定义：协议主要是指在网络通信、数据交换或系统交互等过程中，双方或多方为了实现特定的功能或完成特定的任务而约定的规则、约定和数据格式等，它侧重于规定通信或交互的过程、顺序、信号的含义等，以确保不同的系统或设备之间能够正确地进行信息传递和交互。
- 示例
- 在网络通信中，TCP/IP 协议是一组用于互联网通信的协议族，其中 TCP（传输控制协议）规定了如何在网络中建立可靠的连接、进行数据传输和错误处理等；IP（网际协议）则规定了网络地址的分配和数据包的路由规则等。
- 蓝牙协议规定了蓝牙设备之间如何进行配对、建立连接、传输数据等操作，使得不同厂商的蓝牙设备能够相互通信和协作。
- AMQP：有明确的协议规范，对消息的格式、通信的流程等都有详细的定义，不同的 AMQP 实现需要遵循统一的协议标准，这使得不同的 AMQP 消息中间件之间具有较好的互操作性。常见的 AMQP 实现有 RabbitMQ 等。
- JMS：是一种规范（并不是真正的协议），具体的实现由各个消息中间件厂商来完成，如 ActiveMQ、HornetQ 等。不同的 JMS 实现可能在一些细节上存在差异，虽然 JMS 提供了统一的 API，但在与不同的 JMS 消息中间件集成时，可能会有一些配置和使用上的区别。
事务支持
- AMQP：支持事务机制，通过事务可以确保消息的发送和接收操作的原子性，但 AMQP 的事务实现相对较为底层，需要开发者对 AMQP 协议有较深入的了解。
- JMS：也提供了事务支持，通过 Session 对象来管理事务，JMS 的事务支持在 Java 应用中使用起来相对更方便，与 Java 的事务处理机制结合得更紧密。
应用场景
- AMQP：由于其跨平台性和高性能，适用于多种不同技术栈的系统之间进行消息通信，特别是在大规模分布式系统、微服务架构中，不同语言编写的服务之间的消息交互常常用到 AMQP。
- JMS：主要适用于纯 Java 技术栈的企业级应用，在 Java 应用内部的不同模块之间进行消息传递，或者与其他支持 JMS 的系统进行集成时，JMS 是一个很好的选择。
二、REST
REST（Representational State Transfer）通常被称为一种架构风格，基于这种风格设计的软件架构和接口所遵循的相关规则和约束可被视为广义上的 “REST 协议”。以下是其详细介绍：
概念起源
- REST 概念由 Roy Fielding 在 2000 年他的博士论文中提出，旨在为万维网的架构设计提供一种简洁、可扩展且高效的风格，使网络应用能够更有效地利用网络资源，实现客户端和服务器之间的交互。
核心原则
- 客户端 - 服务器架构：将系统分为客户端和服务器两端，客户端负责向服务器发送请求，服务器处理请求并返回相应的数据或状态信息，这种架构使得客户端和服务器可以独立进行开发、维护和扩展。
- 无状态：服务器不会在不同请求之间记住客户端的状态信息，每个请求都是独立的，服务器仅根据当前请求所包含的信息来处理请求，这有助于提高系统的可扩展性和可靠性，降低服务器的复杂性和资源消耗。
- 缓存：允许客户端和中间节点（如代理服务器）对响应进行缓存，以减少重复请求对服务器的压力，提高系统性能和响应速度。如果后续请求所需要的数据已经在缓存中，且缓存数据未过期，则可以直接从缓存中获取数据，而无需再次向服务器发送请求。
- 统一接口：通过统一的接口来访问服务器上的资源，该接口通常基于 HTTP 协议，使用标准的 HTTP 方法（如 GET、POST、PUT、DELETE 等）来对资源进行操作，使得不同的客户端和服务器之间能够以一致的方式进行交互。
- 分层系统：可以将系统架构分为多个层次，如客户端、代理服务器、应用服务器、数据库服务器等，每个层次都有其特定的职责和功能，不同层次之间通过标准的接口进行通信，这种分层结构有助于提高系统的可维护性和可扩展性。
- 按需代码（可选）：在某些情况下，服务器可以向客户端发送可执行的代码或脚本，让客户端在本地执行，以增强客户端的功能或实现一些特定的业务逻辑，不过这一原则并不是 REST 架构的必需部分。
应用场景
- Web 应用程序：用于构建前后端分离的 Web 应用，前端通过 REST 接口与后端服务器进行数据交互，实现各种功能，如社交媒体网站、电商平台等的前端与后端之间的数据通信。
- 移动应用开发：移动应用与服务器端进行数据交互时，常采用 REST 协议，以便获取数据、提交用户操作等，如新闻类移动应用从服务器获取新闻内容、社交类移动应用上传用户动态等。
- 微服务架构：在微服务架构中，各个微服务之间通常使用 RESTful API 进行通信和协作，实现服务之间的功能调用和数据共享，使得整个微服务系统能够灵活、高效地运行。
三、RESTful API
RESTful API（Representational State Transfer API）是一种基于 REST 架构风格设计的 API，它具有简洁、高效、可扩展等优点。以下是 RESTful API 设计的主要原则：
资源识别
- 使用 URL 定位资源：每个资源都应该有一个唯一的 URL 作为其标识符，URL 应该具有清晰的语义，能够直观地反映出所代表的资源。例如，
https://api.example.com/users表示用户资源集合，https://api.example.com/users/123表示 ID 为 123 的特定用户资源。 - 采用名词而非动词：URL 中应该使用名词来表示资源，而不是使用动词来描述操作。因为 RESTful API 强调对资源的操作，而不是具体的动作。例如，使用
GET /users获取用户列表，而不是GET /getUsers。
统一接口
- 使用标准 HTTP 方法：利用 HTTP 协议提供的标准方法来对资源进行操作，常见的 HTTP 方法及其用途如下：
- GET：用于获取资源的表示形式，通常用于查询操作，不会对资源进行修改。
- POST：用于创建新的资源，将数据提交到服务器以创建新的实体。
- PUT：用于更新资源的全部内容，如果资源不存在则可能创建该资源。
- PATCH：用于部分更新资源，只修改资源的某些字段。
- DELETE：用于删除指定的资源。
- 使用 HTTP 状态码表示操作结果：通过 HTTP 状态码向客户端反馈请求的处理结果，常见的状态码及其含义如下：
- 2xx：表示成功，如
200 OK表示请求成功，201 Created表示资源创建成功。 - 4xx：表示客户端错误，如
400 Bad Request表示请求参数错误，404 Not Found表示请求的资源不存在。 - 5xx：表示服务器错误，如
500 Internal Server Error表示服务器内部出现错误。
- 2xx：表示成功，如
无状态
- 服务器不保存客户端状态：每个请求都应该包含足够的信息，使得服务器能够独立处理该请求，而不需要依赖之前的请求状态。这样可以提高系统的可扩展性和可靠性，降低服务器的复杂性。例如，客户端每次请求都要提供必要的身份验证信息，而不是依赖服务器端保存的会话状态。
可缓存性
- 对响应进行合理缓存：通过设置 HTTP 头部信息（如
Cache-Control、Expires等）来指示客户端和中间代理服务器对响应进行缓存，以减少重复请求对服务器的压力，提高系统性能。对于一些不经常变化的资源（如静态配置信息），可以设置较长的缓存时间；对于经常变化的资源，则可以设置较短的缓存时间或不缓存。
分层系统
- 将系统架构分层：RESTful API 可以采用分层架构，将不同的功能模块分离到不同的层次中，每个层次都有其特定的职责。例如，可以在客户端和服务器之间设置代理服务器、负载均衡器等中间层，以提高系统的可扩展性、安全性和性能。
可扩展性
- 使用 JSON 或 XML 等可扩展的数据格式：在数据传输方面，建议使用 JSON 或 XML 等可扩展的数据格式来表示资源的状态。这些格式具有良好的可读性和可扩展性，能够方便地处理复杂的数据结构，并且易于不同系统之间进行数据交互。
- 支持版本控制：随着业务的发展，API 可能需要进行更新和升级。为了保证向后兼容性，应该对 API 进行版本控制。常见的版本控制方式有在 URL 中包含版本号（如
https://api.example.com/v1/users）、使用请求头部信息指定版本等。
四、统一接口设计理念-HTTP方法操作
以下以一个简单的图书管理系统为例，详细说明统一接口设计理念在 RESTful API 中的具体体现：
资源的识别
- URL 定位资源：在这个图书管理系统中，图书资源可以通过 URL 来定位。
- 所有图书的集合可以用
https://library-api.example.com/books表示。 - 某一本特定的图书，比如 ID 为 5 的图书，可以用
https://library-api.example.com/books/5来定位。
- 所有图书的集合可以用
使用标准的 HTTP 方法操作资源
- GET 方法获取资源
- 获取所有图书列表：客户端向
https://library-api.example.com/books发送 GET 请求。
- 获取所有图书列表：客户端向
curl https://library-api.example.com/books
服务器返回所有图书的列表，以 JSON 格式为例：
[{"id": 1,"title": "Java Programming","author": "John Doe","publication_year": 2020},{"id": 2,"title": "Data Structures","author": "Jane Smith","publication_year": 2019}
]
- 获取单本图书信息：客户端向
https://library-api.example.com/books/1发送 GET 请求。
curl https://library-api.example.com/books/1
服务器返回 ID 为 1 的图书的详细信息：
{"id": 1,"title": "Java Programming","author": "John Doe","publication_year": 2020
}
- POST 方法创建资源：客户端想要创建一本新的图书，向
https://library-api.example.com/books发送 POST 请求，并在请求体中包含新图书的信息。
curl -X POST -H "Content-Type: application/json" -d '{"title": "Python Basics","author": "Alice Brown","publication_year": 2022
}' https://library-api.example.com/books
服务器接收到请求后，创建新的图书资源，并返回新创建图书的信息和 201 状态码：
{"id": 3,"title": "Python Basics","author": "Alice Brown","publication_year": 2022
}
- PUT 方法更新资源：客户端要更新 ID 为 2 的图书的全部信息，向
https://library-api.example.com/books/2发送 PUT 请求。
curl -X PUT -H "Content-Type: application/json" -d '{"title": "Advanced Data Structures","author": "Jane Smith","publication_year": 2021
}' https://library-api.example.com/books/2
服务器用请求体中的信息覆盖原有图书信息，并返回更新后的图书信息：
{"id": 2,"title": "Advanced Data Structures","author": "Jane Smith","publication_year": 2021
}
- PATCH 方法部分更新资源：客户端只更新 ID 为 2 的图书的出版年份，向
https://library-api.example.com/books/2发送 PATCH 请求。
curl -X PATCH -H "Content-Type: application/json" -d '{"publication_year": 2023
}' https://library-api.example.com/books/2
服务器只更新出版年份字段，并返回更新后的图书信息：
{"id": 2,"title": "Advanced Data Structures","author": "Jane Smith","publication_year": 2023
}
- DELETE 方法删除资源：客户端要删除 ID 为 3 的图书，向
https://library-api.example.com/books/3发送 DELETE 请求。
curl -X DELETE https://library-api.example.com/books/3
服务器删除该图书资源，并返回 204 状态码（表示请求处理成功，但没有内容返回）。
资源的表示
- 使用标准的数据格式：上述例子中，服务器和客户端之间的数据传输都采用了 JSON 格式，这种格式易于解析和处理，方便不同系统之间进行数据交换。
- 自描述性：在返回的图书信息中，可以包含一些额外的元数据和链接，使其更具自描述性。例如：
{"id": 1,"title": "Java Programming","author": "John Doe","publication_year": 2020,"links": [{"rel": "self","href": "https://library-api.example.com/books/1"},{"rel": "update","href": "https://library-api.example.com/books/1","method": "PUT"},{"rel": "delete","href": "https://library-api.example.com/books/1","method": "DELETE"}]
}
这些链接表明了可以对该图书资源执行的操作，客户端可以根据这些信息自动地发现和处理资源。
使用 HTTP 状态码表示操作结果
- 当客户端成功获取图书列表时，服务器返回 200 状态码。
- 当客户端成功创建新图书时，服务器返回 201 状态码。
- 如果客户端请求的图书 ID 不存在，服务器返回 404 状态码。
- 如果客户端发送的请求参数有误，服务器返回 400 状态码。
- 如果服务器内部出现错误，服务器返回 500 状态码。
五、web Socket协议
WebSocket 是一种在单个 TCP 连接上进行全双工通信的网络协议，在 2011 年被 IETF 定为标准 RFC 6455，并由 RFC7936 补充规范。以下为你详细介绍：
产生背景
传统的 HTTP 协议是无状态的，每次请求都需要客户端发起，服务器响应，这种请求 - 响应模式在一些需要实时通信的场景（如在线聊天、实时数据展示、游戏等）下效率较低，会带来大量的开销。WebSocket 协议的出现就是为了解决这些问题，它允许服务器主动向客户端推送数据，实现客户端和服务器之间的实时双向通信。
⭐工作原理
- 握手阶段：客户端通过发送一个 HTTP 请求到服务器，请求头中包含一些特殊的字段，如
Upgrade: websocket和Connection: Upgrade，表明客户端希望将当前的 HTTP 连接升级为 WebSocket 连接。服务器收到请求后，如果支持 WebSocket 协议，会返回一个状态码为 101 Switching Protocols 的响应，表示同意升级连接。一旦握手成功，HTTP 连接就会被升级为 WebSocket 连接，后续的数据传输将使用 WebSocket 协议。 - 数据传输阶段：在 WebSocket 连接建立后，客户端和服务器可以在这个连接上进行全双工通信，即双方可以同时发送和接收数据。数据以帧的形式进行传输，WebSocket 协议定义了不同类型的帧，如文本帧、二进制帧、控制帧等，用于传输不同类型的数据和进行连接的控制。
- 关闭连接阶段：当客户端或服务器需要关闭连接时，会发送一个关闭帧给对方。对方收到关闭帧后，会发送一个确认关闭帧进行响应，然后双方关闭 TCP 连接。
特点
- 全双工通信：客户端和服务器可以在任意时刻相互发送数据，无需等待对方的请求，实时性高，适用于对实时性要求较高的应用场景。
- 较少的开销：与传统的 HTTP 请求 - 响应模式相比，WebSocket 连接建立后，只需要在数据传输时消耗少量的带宽，避免了频繁的 HTTP 请求带来的额外开销。
- 支持二进制和文本数据：WebSocket 协议支持传输二进制数据和文本数据，可以满足不同类型数据的传输需求。
- 跨域支持：WebSocket 在处理跨域问题上比传统的 HTTP 更方便，很多浏览器都支持跨域的 WebSocket 连接。
应用场景
- 实时聊天应用：如在线客服系统、社交平台的聊天功能等，通过 WebSocket 可以实现消息的实时发送和接收，让用户之间的交流更加流畅。
- 实时数据展示：在金融领域的股票行情展示、体育赛事的实时比分更新等场景中，WebSocket 可以让客户端实时获取最新的数据，保证数据的及时性。
- 多人在线游戏：在多人在线游戏中，玩家的动作和状态需要实时同步，WebSocket 的低延迟和高实时性可以满足游戏的要求，提供更好的游戏体验。
- 监控系统：用于监控服务器性能、网络设备状态等，服务器可以通过 WebSocket 实时将监控数据推送给客户端，让管理员及时了解系统的运行情况。
六、WebSocket 通信协议与长轮询、SSE相比有什么优势？
WebSocket 协议与长轮询、服务器发送事件（SSE）都是用于实现实时通信的技术，但它们各有特点。下面详细对比 WebSocket 相对于长轮询和 SSE 的优势：
与长轮询对比
1. 通信效率
- 长轮询：长轮询是客户端向服务器发送请求，服务器如果没有新数据就保持连接不关闭，直到有新数据或者超时，然后客户端再重新发起请求。这种方式会频繁建立和断开 HTTP 连接，带来较大的开销，尤其是在高并发场景下，服务器需要处理大量的连接请求，会消耗较多的资源。
- WebSocket：WebSocket 只需要在连接建立时进行一次握手，之后就在同一个 TCP 连接上进行全双工通信。避免了频繁建立和断开连接的开销，数据传输更加高效，服务器和客户端的资源消耗也相对较少。
2. 实时性
- 长轮询：存在一定的延迟。因为即使服务器有新数据，也需要等待客户端发起下一次请求才能将数据返回给客户端。而且超时机制也会导致在超时时间内有新数据产生时不能及时推送。
- WebSocket：服务器可以在有新数据时立即将其推送给客户端，实现真正的实时通信，延迟极低，能满足对实时性要求极高的场景，如金融交易系统、在线游戏等。
3. 带宽占用
- 长轮询：每次请求和响应都包含大量的 HTTP 头信息，即使没有实际的数据传输，这些额外的信息也会占用一定的带宽，导致带宽利用率较低。
- WebSocket：在连接建立后，数据传输时只需要少量的协议头，大部分带宽都用于传输实际的数据，带宽利用率更高。
与服务器发送事件（SSE）对比
1. 通信方向
- SSE：是一种单向通信协议，只能由服务器向客户端发送数据，客户端不能主动向服务器发送数据。这限制了它在一些需要双向交互的场景中的应用，如在线聊天、实时协作等。
- WebSocket：支持全双工通信，客户端和服务器可以同时、独立地发送和接收数据，能够满足各种复杂的实时交互需求。
2. 数据类型支持
- SSE：主要用于传输文本数据，虽然也可以通过一些编码方式传输二进制数据，但处理起来相对复杂，且不是其主要的应用场景。
- WebSocket：既支持文本数据的传输，也支持二进制数据的传输，能够方便地处理各种类型的数据，如图片、音频、视频等。
3. 跨浏览器和跨平台兼容性
- SSE：在一些旧版本的浏览器中支持情况较差，需要进行额外的兼容性处理，而且在某些特定的网络环境或服务器配置下可能会出现问题。
- WebSocket：现代浏览器大多都对 WebSocket 提供了良好的支持，并且可以在不同的操作系统和设备上使用，跨浏览器和跨平台的兼容性更好。