REST消费者
对于 REST 消费者，Solace PubSub+ 事件代理将建立一个 HTTP 连接，并使用 HTTP POST 请求发送消息，如下图所示。
REST 应用程序通过向事件代理发送 200 OK HTTP 响应来确认收到消息。收到的 REST POST 请求的格式以及响应选项在 REST 消息传递协议、Solace REST HTTP 消息编码和 Solace REST 状态代码中有详细说明。
要从事件代理接收消息，需要进行一些配置，以便为事件代理提供有关如何传递消息的详细信息。此配置在下一部分中有详细说明。本节还提供了有关 REST 消费者的请求/回复处理以及一些用于扩展应用程序的集成模式的概述。
Saydo PubSub+事件代理配置对象
下图概述了在将 HTTP 消息传递给 REST 消费者时发挥作用的配置对象。REST 交付点封装了向一组一个或多个 REST 消费者客户端传递消息的过程。基于配置的队列绑定，从持久消息队列接收消息。配置的 REST 消费者对象封装了给定 REST 消费者应用程序的所有连接信息。然后，REST 交付点负责选择适当的 REST 消费者并传递消息。
REST交付点
为了让 REST 应用程序能够接收消息，事件代理必须建立到 REST 消费者应用程序的 HTTP 连接并传递消息。建立此连接以及管理消息传递所需的信息需要在事件代理上进行配置。REST 交付点是一个配置对象，它将吸引消息的队列和接收这些消息的 REST 消费者应用程序联系起来。
因此，REST 交付点对象执行以下角色：
- REST 交付点配置有与持久消息队列的绑定，这些队列吸引要传递给 REST 消费者的消息。
- REST 交付点安排新到达的消息通过 HTTP/REST 连接传递给 REST 消费者。REST 交付点执行的流量管理在以下部分中讨论。
- REST 消费者对象处理与 REST 消费者应用程序的连接。应用程序的 IP/DNS 名称和 TCP 端口号以及其他连接详细信息都设置在 REST 消费者对象中。
队列绑定
队列绑定对象存在于 REST 交付点的作用域内。REST 交付点可以有一个或 多个队列绑定。至少需要一个队列绑定才能使流量流动。队列绑定允许 REST 交付点绑定到事件代理上的物理持久消息队列，然后接收消息。
POST 请求目标也在队列绑定中配置。POST 请求目标用于所有来自物理队列的消息。可以使用 POST 请求目标向 REST 消费者应用程序指示消息的来源。
REST消费者
REST 消费者对象建立与希望从 Solace PubSub+ 事件代理接收消息的 REST 消费者应用程序的 HTTP 连接。每个消费者应用程序通过 IP/DNS 名称和 TCP 端口号来识别。事件代理通常会与每个 REST 消费者保持多个 TCP/HTTP 连接，以便并行传递多条消息。可以在 REST 交付点中配置许多 REST 消费者，以便实现更高的消息传递速率以及支持容错。
要理解的一个关键架构模式是，REST 交付点中的所有 REST 消费者都被视为消息的平等目标。因此，传入的消息可能会通过 REST 交付点中的任何 REST 消费者连接传出。
默认情况下，Solace PubSub+ 事件代理会自动选择用于 REST 消费者传出连接的 IP 接口。然而，如果您的环境需要固定的 IP 接口，则可以为 REST 消费者配置特定接口，以便所有与 REST 消费者相关的传出数据包中指定的源 IP 地址对于所有连接都相同。例如，如果在客户端应用程序和事件代理之间使用了防火墙，则可能需要固定 IP 接口。在这种情况下，必须配置防火墙以允许事件代理的源 IP 地址通过，因此自动选择的 IP 接口可能会有问题。
消息传递过程
下图展示了如何将消息传递给 REST 消费者应用程序。
- 消息到达持久消息队列。这些可以来自任何 Solace PubSub+ 事件代理客户端的消息。
- REST 交付点队列绑定将 REST 交付点连接到持久队列。随着每条消息通过队列绑定从持久消息队列接收，消息会增加 POST 请求目标。
- 然后，REST 交付点将消息从用于路由的 Solace 消息格式转换为格式正确的 REST 消息，具体在 REST 消息传递协议中有详细说明。
- REST 交付点选择适当的传出 REST 消费者和 HTTP 连接来发送消息。
- REST 交付点将消息发送到连接的 REST 消费者应用程序。
请求/回复
Solace PubSub+ 事件代理还支持与 REST 消费者应用程序的请求/回复消息交换模式。下图和步骤概述了其工作原理。
- 消息通过持久队列到达 REST 交付点。
- 当 REST 交付点创建要发送的 REST 消息时，它会在接收到的 Solace 消息中查找回复到目标。如果存在回复到目标，则 REST 交付点启用请求/回复处理。传出 REST 消费者连接的选择方式与之前相同。
- REST 消费者应用程序将响应作为 HTTP 200 OK POST 响应的正文发送回 Solace PubSub+ 事件代理。
- 当 REST 交付点收到响应时，它将 200 OK HTTP 响应中的响应转换为 Solace 消息以供内部路由。消息的目标将是原 始消息中的回复到目标。
- 消息在 Solace PubSub+ 事件代理中正常路由，并返回给发出请求的应用程序。
REST消费者连接选择
Solace PubSub+ 事件代理中的 REST 交付点尝试使用以下两个标准跨传出 REST 消费者连接分配流量：
- 从至少有一个可用 HTTP 连接的 REST 消费者组中以轮询方式选择 REST 消费者。
- 再次从该 REST 消费者内的可用 HTTP 连接组中以轮询方式选择传出 HTTP 连接。
这种 REST 消费者 HTTP 连接选择过程用于提供更好的整体性能，而不会将流量集中在任何特定的 REST 消费者上。当连接已建立且没有待处理的 HTTP 消息时，REST 消费者连接被视为可用。因此，它可以发送新的 HTTP POST 消息。
例如，如果需要通过 REST 交付点同时传递五条消息，并且有五个 REST 消费者，那么最好将每条消息发送到不同的 REST 消费者，而不是将所有五条消息发送到同一个 REST 消费者，即使该消费者有五个可用的 HTTP 连接。
消息排序和重新传递
当 REST 消费者应用程序以 HTTP 错误响应（例如，不是 200 OK 的内容）响应消息时，REST 交付点会将此消息以负确认的方式返回到持久消息队列。根据持久消息队列的设置，可能会再次将消息重新传递到 REST 交付点进行处理。重新传递的消息遵循与新消息相同的消息处理过程。
消息将被重新传递的次数由持久消息队列的“最大重新传递次数”属性控制。默认情况下，此参数设置为无限重试，以避免消息丢失。然而，可以根据特定应用程序的需求调整此持久队列属性。
如果所有消息重新传递尝试都已用尽，消息将遵循正常的死信队列（DMQ）处理。为了使应用程序能够使用 DMQ，必须为持久队列的最大重新传递次数属性设置适当的值。
消息排序
通常，对于 REST 消费者，消息排序没有保证。不同 HTTP 连接上的消息可以以任何顺序到达消费的 REST 应用程序。此外，消息的重新传递可能导致重新传递的消息顺序错乱。
一般来说，对于 REST 消费应用程序，消息排序并不是一个要求。对于有此严格要求的应用程序，具有单个 REST 消费者和单个传出 REST HTTP 连接的 REST 交付点将以牺牲消息吞吐量为代价来保持消息顺序。
错误发生时的连接处理
大多数情况下，当 REST 消费应用程序未能处理消息时，立即将此消息重新传递给同一应用程序将导致类似的处理失败。因此，REST 交付点为收到非 200 OK HTTP 响应的连接实现了一个抑制定时器。在这些情况下，发送 POST 请求的连接在“重试延迟”期间（默认值为三秒）不会被重用。
当 REST 消费者连接处于抑制状态时，它不会被安排接收任何传出的 POST 请求。这有两个有益的效果：
- 首先，它大大减少了网络中所有内容的错误处理负载。
- 其次，如果有其他 REST 消费者连接可用并且成功接收 POST 响应，则 REST 交付点会将大部分传出消息导向这些连接。
性能考虑
由于 HTTP 传递到 REST 消费者的阻塞性质，Solace PubSub+ 事件代理必须等待响应才能发送下一条消息。因此，单个 HTTP 连接的性能始终受到一条消息往返时间的限制。此时间取决于事件代理和 REST 消费者之间的网络质量以及 REST 消费者处理消息的速度。
如下所示，提高整体系统性能主要有两个选项。
-
增加每个 REST 消费者的连接数量。
-
增加使用的 REST 消费者数量。
按REST消费者扩展连接
当 REST 消费者应用程序有足够的处理开销，性能仅受到网络往返时间的限制时，可以添加额外的传出 HTTP 连接，如下图所示。这可以消除网络作为性能限制因素。
按REST消费者扩展
性能的下一个最常见限制因素是 REST 消费者应用程序本身。通常这些应用程序可以水平扩展，以便并行处理更多传入消息。Solace PubSub+ 事件代理通过允许 REST 交付点包含许多 REST 消费者来支持这一点。如下图所示，消息传递然后在 REST 消费者之间共享。
REST消费者对消息内容的动态路由
通常，REST 消费者应用程序被配置为在少量输入端口上侦听传入流量。根据与消息相关的 HTTP POST 请求目标或 URI，将传入的 HTTP 流量路由到正确的内部服务。如下图所示，这是 REST 交付点中多个队列绑定的最常见用例。
服务 A 的消息可以路由到单个持久队列。REST 交付点中的队列绑定可以关联正确的 POST 请求目标，以便 REST 消费者应用程序可以将消息内部路由到 服务 A。对于 服务 B 和 C 可以使用类似的设置。
这是一种常见的集成模式，如后文所示，通常用于 DataPower 集成。