跳到主要内容

Microgateway用例

以下部分描述了通过 Microgateway 功能实现的几种场景。

微服务的流量管理​

在这种情况下，REST 客户端向 Solace PubSub+ 事件代理发出 HTTP 请求。事件代理使用基本身份验证或 TLS 客户端证书对客户端进行身份验证。一旦客户端身份验证成功，URI 的方法和路径部分将被编码为一个主题，并根据客户端的发布 ACL 规则进行评估，以确定客户端是否有权使用客户端请求的方法访问该 URI。一旦客户端获得授权，请求将路由到订阅该主题的目的地或目的地。通常，然后将消息放置在由 REST 交付点（RDP）服务的队列上，以便传递给远程微服务。微服务处理请求并生成适当的响应。然后，微服务的响应通过事件代理返回给 REST 客户端。

标准 Microgateway 部署

img

有关如何配置提供微服务流量管理的标准 Microgateway 部署的示例，请参阅微服务流量管理示例。

与窃听应用程序的集成​

使用 Solace PubSub+ 事件代理传输 HTTP 请求和响应，允许其他服务或事件监听器在不更改 REST 客户端或 REST 服务提供商的情况下接收消息。这使您能够在不重写客户端应用程序的情况下引入响应时间分析、使用真实数据进行测试的数据捕获、故障分析等。

为了让额外的监听器接收请求和响应，您只需添加与服务提供商订阅的主题相同的订阅，并添加一个与事件代理生成的回复主题相对应的订阅。

与窃听应用程序集成的 Microgateway

img

有关如何将窃听应用程序添加到现有 Microgateway 部署的示例，请参阅窃听应用程序示例。

多协议消息传递​

Microgateway 功能还使得非 HTTP 客户端（如 JMS 或 JEE 应用程序）可以充当服务提供商成为可能。这是因为从 URI 导出的主题可以将消息路由到由任何类型的客户端使用我们的 PubSub+ 消息 API 或开放 API 和协议服务的队列或端点。HTTP 头以单个文本块的形式提供给使用这些 API 的客户端，换句话说，头选项没有被解析为单独的名称-值对。

与使用 JMS 连接的服务提供商的 Microgateway

img

在此解决方案中，MQTT 客户端不能用作服务提供商，因为 MQTT 中没有机制将元数据（如回复主题和 HTTP 头属性）传递给 MQTT 客户端。

混合事件驱动架构​

由于 Solace PubSub+ 事件代理支持发布/订阅架构，您可以使用 Microgateway 构建混合请求/回复和发布/订阅事件驱动架构。结果比传统的请求/回复架构更灵活、更可扩展。

以下图表提供了一个混合事件驱动架构的示例。在此示例中，前端移动应用程序和多个后端微服务（包括实时分析应用程序）都连接到 Solace 消息总线。根据每个微服务的目标，使用请求/回复和发布/订阅传递方法。

混合请求/回复和发布/订阅事件驱动架构

img

从请求/回复架构迁移到事件驱动架构​

您可以在现有的请求/回复环境中添加 Microgateway，以协助迁移到事件驱动架构。

在传统的请求/回复架构下，添加一个新的事件驱动服务意味着需要对每个现有的微服务进行额外的负担，以支持至少两种消息交换模式（事件和请求/回复）。使用 Solace Microgateway，您可以扩展架构而无需干扰现有服务。此外，您可以同时运行两种环境，直到您准备好移除旧服务为止。

以下图表展示了使用 Solace Microgateway 将现有请求/回复架构演变为事件驱动架构的过程，随着新应用程序的添加。

使用 Microgateway 从请求/回复架构迁移到事件驱动架构——阶段 1

img

使用 Microgateway 从请求/回复架构迁移到事件驱动架构——阶段 2

img

使用 Microgateway 从请求/回复架构迁移到事件驱动架构——阶段 3

有关如何将事件驱动应用程序添加到现有请求/回复端点的示例，请参阅迁移到事件驱动架构示例。