Traffic Management to Microservices Example

The following sections provide an example of how to use a Microgateway to configure basic traffic management to microservices with the Solace CLI. In the example, two queues are created and bound to a REST delivery point (RDP) to provide prioritized processing of POST requests to a single remote microservice instance.

Before you begin

The example provided in the following sections assumes that the following parameters are already configured on the Solace PubSub+ event broker:

  • System level parameters for incoming and outgoing REST connections.
  • The incoming REST service for the Message VPN, including the dedicated REST listen port and encryption method.

Step 1: Enable REST Gateway Mode

Before the event broker can act as a Microgateway, you must enable gateway mode on the Message VPN you want to use for the service. In this example, an existing Message VPN is used to enable the Microgateway deployment. Omitted from the example are the steps required to set up authentication or use ACLs to control client access to specific URIs and HTTP methods. For more information, refer to Configuring Client Authentication and ACL Configuration .

solace(configure)# message-vpn microgateway
solace(configure/message-vpn)# service rest
solace(configure/message-vpn/service/rest)# mode gateway
solace(configure/message-vpn/service/rest)# exit
solace(configure/message-vpn/service)# exit
solace(configure/message-vpn)# exit

Step 2: Create the Appropriate Queues

Once gateway mode is enabled on a Message VPN, the event broker encodes the HTTP method and path of incoming requests into a message topic for internal transportation. This process enables the event broker to deliver requests to specific queues. You can use this functionality to load balance requests by method or path, set up prioritized processing, and add eavesdropping applications to the service.

In this example, two queues (Queue A and Queue B) are created to enable prioritized processing of POST requests.

solace(configure)# message-spool message-vpn microgateway
solace(configure/message-spool)# create queue A
solace(configure/message-spool/queue)# exit
solace(configure/message-spool)# create queue B

Step 3: Configure the Queues to Respect TTLs

To prevent wasted message exchanges and stop stale messages from persisting on each queue, Solace recommends that you configure queues used in Microgateway deployments to respect messages Time-to-Live (TTL) expiration values.

When you configure queues for eavesdropping applications, be sure to ignore this configuration so that all messages persist and are available for collection.

In this example, both queues are configured to respect TTLs.

solace(configure/message-spool/queue)# respect-ttl
solace(configure/message-spool/queue)# exit
solace(configure/message-spool)# queue A
solace(configure/message-spool/queue)# respect-ttl

Step 4: Add Topic Subscriptions to Each Queue

Topic subscriptions provide the necessary information for queues to receive incoming requests from REST clients. You can use topic subscriptions to route requests to specific queues for prioritized processing, or to route requests from associated queues to specific microservice instances. In addition, if you want to add eavesdropping applications to the service, you can add a matching topic subscription for the eavesdropping application (refer to Eavesdropping Application Example).

In this example, topic subscriptions are added to each queue in the service for prioritized processing of POST requests. On Queue A, a subscription is added to attract all POST requests. On Queue B, subscriptions are added to attract all other request methods. Although each queue is serviced equally, adding a separate dedicated queue for POST requests ensures these requests receive faster treatment, especially during periods of overload.

solace(configure/message-spool/queue)# subscription topic POST/>
solace(configure/message-spool/queue)# exit
solace(configure/message-spool)# queue B
solace(configure/message-spool/queue)# subscription topic GET/>
solace(configure/message-spool/queue)# subscription topic DELETE/>
solace(configure/message-spool/queue)# subscription topic PATCH/>
solace(configure/message-spool/queue)# subscription topic HEAD/>
solace(configure/message-spool/queue)# subscription topic OPTIONS/>
solace(configure/message-spool/queue)# subscription topic PUT/>

Step 5: Enable the Queues

Before any of the queues in the service can process requests, you must enable them.

solace(configure/message-spool/queue)# no shutdown
solace(configure/message-spool/queue)# exit
solace(configure/message-spool)# queue A
solace(configure/message-spool/queue)# no shutdown
solace(configure/message-spool/queue)# exit
solace(configure/message-spool)# exit

Step 6: Create REST Delivery Points

RDPs facilitate message delivery to REST consumers. For more information about this process, refer to Solace PubSub+ Event Broker Configuration Objects.

In this example, a single RDP is created to provide connectivity to a corresponding REST consumer.

solace(configure)# message-vpn microgateway
solace(configure/message-vpn)# rest
solace(configure/message-vpn/rest)# create rest-delivery-point RDP

Step 7: Create Queue Bindings

Each RDP must be bound to one or more queues to enable requests to flow from REST clients to remote microservices. When you create queue bindings for Microgateway deployments, you can optionally configure how the event broker handles the authority value in outbound URIs. For more information refer to Managing REST Delivery Points

In this example, each queue is bound to a single RDP.

solace(.../message-vpn/rest/rest-delivery-point)# create queue-binding A
solace(...est/rest-delivery-point/queue-binding)# exit
solace(.../message-vpn/rest/rest-delivery-point)# create queue-binding B
solace(...est/rest-delivery-point/queue-binding)# exit

Step 8: Create REST Consumers

REST consumers provide connectivity between RDPs and remote microservices. More specifically, you must configure at least one REST consumer for each DNS name that you want to receive requests. For more information, refer to REST Consumer.

RDPs can contain multiple REST consumers, however, in this example the RDP contains a single REST consumer for final delivery to one microservice instance.

solace(.../message-vpn/rest/rest-delivery-point)# create rest-consumer RC

Step 9: Specify Remote Microservice Destinations

To ensure delivery of requests to the appropriate remote microservice, you must configure the hostname and optionally the port of each destination.

In this example, a single microservice instance is configured as a remote destination for incoming requests.

solace(...est/rest-delivery-point/rest-consumer)# remote
solace(...t-delivery-point/rest-consumer/remote)# host www.mystore.com/storefront/
solace(...t-delivery-point/rest-consumer/remote)# port 8080
solace(...t-delivery-point/rest-consumer/remote)# exit

Step 10: Enable REST Consumers

Before each REST consumer can process requests, you must enable it.

solace(...est/rest-delivery-point/rest-consumer)# no shutdown
solace(...est/rest-delivery-point/rest-consumer)# exit

Step 11: Enable REST Delivery Points

Before each RDP can process requests, you must enable it.

solace(.../message-vpn/rest/rest-delivery-point)# no shutdown

Step 12: Verify All Connections are Up

After all components in the service are configured and enabled, you can issue the following show commands to verify that each component is operational and ready to process requests (both the Admin State and Operational State flag is Up).

Be aware that all components in the service do not receive an Operational State of Up, until connectivity is established to the corresponding remote destinations.

solace(.../message-vpn/rest/rest-delivery-point/)# show message-vpn <message-vpn> rest rest-delivery-point <rdp-name>

Total REST Delivery Points (up):                       1
Total REST Delivery Points (configured):               1
Total REST Consumers (up):                             1
Total REST Consumers (configured):                     1
Total REST Consumer Outgoing Connections (up):         3
Total REST Consumer Outgoing Connections (configured): 3
Total Queue Bindings (up):                             1
Total Queue Bindings (configured):                     1

Flags Legend:
A - Admin State (U=Up, D=Down)
O - Oper State (U=Up, D=Down)

                                                  REST
                                                 Consumer
                                                 Outgoing     Queue       Conns
                                        Status    Conns      Bindings    Blocked
RDP Name             Message VPN         A O    (up/conf)    (up/conf)     (%)
-------------------- ------------------ ------ ----------- ------------- -------
RDP                  microgateway        U U   3 / 3       1 / 1              0

solace(.../message-vpn/rest/rest-delivery-point/)# show message-vpn <message-vpn> rest rest-consumer <rest-consumer-name>

Total REST Consumer Outgoing Connections (up):         3
Total REST Consumer Outgoing Connections (configured): 3

Flags Legend:
A - Admin State (U=Up, D=Down)
O - Oper State (U=Up, D=Down)

                                                                  REST Consumer
REST                                                       Status  Connections
Consumer             RDP Name           Message VPN        A O      (up/conf)
-------------------- ------------------ ------------------ ------ -------------
RC                   RDP                microgateway       U U    3 / 3

solace(configure/message-vpn/rest/rest-delivery-point/)# show message-vpn <message-vpn> rest rest-delivery-point <rdp-name> queue-binding *

REST Delivery Point:                                RDP
  Message VPN:                                      microgateway
  Admin State:                                      Up
  Operational State:                                Up
  Last Failure Reason:                              No REST Consumers Up
  Last Failure Time:                                Feb 27 2018 17:18:17 UTC
  Client Profile:                                   default
  Client Name:                                      #rdp/RDP
  REST Consumers (up):                              1
  REST Consumers (configured):                      1
  REST Consumers Outgoing Connections (up):         3
  REST Consumers Outgoing Connections (configured): 3
  Queue Bindings (up):                              1
  Queue Bindings (configured):                      1
  Blocked Connections %:                            0

  Queue Name               Status     Uptime
  ------------------------ ------ --------------
  A                        Up     0d 0h 6m 30s