As your enterprise grows, you may find that your individual event brokers are not sufficient to handle the demands of your business. At some point even the largest, most generously provisioned event broker has its limits, but these can be overcome by networking several event brokers together and spreading the load among the participants. In this way, multiple event brokers can be connected together to service loads far in excess of that possible by a single one.
Enterprise applications also become distributed across multiple sites—which can include multiple public and private clouds as well as legacy data centers—driving the need for an easy way to intelligently share information between all these locations and interfaces. For example, your organization may have on-premises applications using PubSub+ brokers that need to connect to cloud services such as AWS Lambda, Azure Event Hubs, or Google Functions.
Dynamic Message Routing (DMR) is a mechanism that allows connected event brokers to automatically determine how to forward event messages. You use DMR to create a network, or event mesh, that connects individual brokers together within the same site (horizontal scaling) or between sites (multi-site scaling) to exchange subscription information. With an event mesh, clients don't need to know about other sites in the network. Once the relationships between event brokers are established by the administrator, the event brokers dynamically discover how to route messages. Client applications don't have to take any special action to publish or consume messages across the mesh. They simply go about their business of exchanging messages without considering how to get those messages where they need to go. With DMR, you can move any applications within the mesh, or change the interests of those applications, and the mesh automatically updates the routing—without any intervention.
DMR supports two basic use cases: horizontal scaling and multi-site scaling. More complicated topologies are possible. If the use cases discussed here don’t address your needs, contact Solace for assistance with designing and implementing your DMR mesh.
For horizontal scaling, you connect brokers together to create a DMR cluster. Each broker in the cluster has a connection to every other broker. These connections within the same cluster are called internal links; collectively, we refer to this as a "full mesh" of links. Within this fully-meshed cluster, each event broker is aware of all the others so that every event published in the network is seamlessly routed to the consuming application(s).
In multi-site scaling, you connect two or more clusters together. Connections between clusters are called external links. It is not necessary for each cluster to be connected to every other cluster; however, messages only propagate between directly-connected clusters. In the following diagram, messages do not pass between Cluster A and Cluster C.
Let's take a look at how DMR works in a scenario. The diagram below shows a horizontally-scaled cluster on-premises, which is connected to a cluster in the public cloud (AWS in the example) and another cluster in a platform-as-a-service (PaaS) (Kubernetes in the example).
A publishing application (A) comes online and publishes to a topic, let's say
tools/orders. A consuming application (B) in the same cluster comes online, binds to its queue, and subscribes to topic
tools/orders. Events flow from application A to application B.
In addition, all subscriptions are shared between connected clusters. This means that event messages published by an application in one cluster are seamlessly routed to consuming application in other clusters.
In the example below, another consumer (C) comes online and subscribes to the same topic,
tools/orders. Any event with topic
tools/orders is now routed to the new consumer. As more publishers and consumers connect and disconnect, the routing is dynamically updated in the mesh.
DMR and VPN bridges are two alternate technologies that can be used to interconnect brokers. Both support guaranteed (persistent) and direct (non-persistent) messages. The advantage of DMR over VPN bridges is that with DMR you don’t need to statically configure topic subscriptions to define which events flow over the inter-broker links. DMR automatically routes your guaranteed and direct messages through your event mesh to all interested subscribers.
The Solace PubSub+ Broker Manager includes a click-to-connect wizard that can easily create a DMR mesh in a few mouse clicks. Click-to-connect is also provided for VPN bridges, but you must then configure the topics that the bridges subscribe to.
When you want to strictly control which events go over an inter-broker link, you should use VPN bridges. When you want to build a large event mesh with minimal configuration effort and dynamic propagation of subscriptions throughout the mesh, DMR is the recommended choice.
- Disaster Recovery (Replication)
- You can take advantage of disaster recovery (using replication and Config-Sync) within your DMR network (or event mesh). Replication provides business continuity and allows mission‑critical applications to continue to function during a major service outage to a data center. For more information, see Replication Overview and Configuring Replication with a DMR Network.
- Message VPN Bridging
- Bridging and DMR are compatible, and can be used at the same time. However, we recommend that you don't configure VPN bridge links and DMR links between the same event brokers because this configuration causes duplicate message delivery.
- Multi-Node Routing
- Multi-Node Routing (MNR) and DMR cannot be used at the same time. They are mutually exclusive.
If you want to migrate from MNR to DMR, contact Solace for assistance.
- To delve deeper into the specifics of how DMR works, see DMR Subscription Propagation and Data Forwarding.
- For a high-level view of how to set up an event mesh, see Setting up an Event Mesh Using DMR.
- Take a look at the examples to see how to configure Horizontal Scaling and Multi-Site Connectivity.