KubeMQ Bridges
Last updated
Last updated
KubeMQ Bridges bridge, replicate, aggregate, and transform messages between KubeMQ clusters no matter where they are, allowing to build a true cloud-native messaging single network running globally.
Key Features:
Runs anywhere - Kubernetes, Cloud, on-prem, anywhere
Stand-alone - small docker container/binary
Build Any Topology - connects KubeMQ clusters in 1:1, 1:n , n:1, n:n
Middleware Supports - Logs, Metrics, Retries, and Rate Limiters
Easy Configuration - simple yaml file builds your topology
An example of a use case:
KubeMQ Bridges' concept is bridging between sources and targets, thus Bindings.
Binding can be any source kinds to any target kinds, as shown below:
KubeMQ Bridges can support any binding topology :
Topology | Description | Sources-Targets |
Bridge | a 1:1 connectivity mainly for sync type of messages | one source to 1 target |
Replicate | a 1:n connectivity allowing replicating messages between clusters | one source to n targets |
Aggregate | an n:1 connectivity allowing aggregating streams fo messages from clusters to a single target | n source to 1 target |
Transform | an n:n mix and match sources and targets in many to many topology | n sources to n targets |
In bindings configuration, KubeMQ Bridges supports middleware setting for each pair of source and target bindings.
These properties contain middleware information settings as follows:
KubeMQ Bridges supports level based logging to console according to as follows:
Property | Description | Possible Values |
log_level | log level setting | "debug","info","error" |
"" - indicate no logging on this binding |
An example for only error level log to console:
KubeMQ Bridges supports Retries' target execution before reporting of error back to the source on failed execution.
Retry middleware settings values:
Property | Description | Possible Values |
retry_attempts | how many retries before giving up on target execution | default - 1, or any int number |
retry_delay_milliseconds | how long to wait between retries in milliseconds | default - 100ms or any int number |
retry_max_jitter_milliseconds | max delay jitter between retries | default - 100ms or any int number |
retry_delay_type | type of retry delay | "back-off" - delay increase on each attempt |
"fixed" - fixed time delay | ||
"random" - random time delay |
An example of 3 retries with back-off strategy:
KubeMQ Sources support a Rate Limiting of target executions.
Rate Limiter middleware settings values:
Property | Description | Possible Values |
rate_per_second | how many executions per second will be allowed | 0 - no limitation |
1 - n integer times per second |
An example for 100 executions per second: