Fabric8 Messaging provides a scalable and elastic Messaging as a Service built on top of Kubernetes.
Fabric8 Messaging comprises of the following Microservices:
For more background see the Architecture.
The Message Gateway implements a service, activemq
on port 61616 so any messaging application can just connect to tcp://activemq:61616
and use any of the messaging protocols supported.
If you are using JMS then if you use the mq-client library the io.fabric8.mq.core.MQConnectionFactory class will automatically default to using the activemq
message service for scalable messaging.
If you use the camel-amq library and amq:
component it will automatically default to using the activemq
message service for scalable messaging.
If your application wishes to avoid a network hop between your container and the Message Gateway you can just add the Message Gateway container into your Pod; then your container can connect on tcp://localhost:61616
to perform messaging with the gateway taking care of communicating with the correct broker pods based on the destinations you use.
If you wish to connect to a different messaging service other than activemq
then use the $ACTIVEMQ_SERVICE_NAME
environment variable.
Its best explained by following what happens to messages as they flow through Fabric8 Messaging:
Protocol Conversion — by moving MQTT,STOMP,AMQP protocol conversion outside of the ActiveMQ broker reduces the amount of work the broker needs to do: As ActiveMQ isn’t well designed for modern, asynchronous tasks, the less work the broker does, the better.
Camel Routing is built right into the router — so we can easily convert on the fly between, say Topics (Publish/Subscribe) and Queues (point-2-point).
API Management — utlizing API Man, so you can apply security and rate limiting policies to destinations
Multiplexer — reducing the amount of physical connections an ActiveMQ broker has, increases the throughput of the overall system.
Destination Sharding — this is where a lot of the magic pixie dust is used, to shard connections across many different backend ActiveMQ brokers. Its also where messages and clients are moved between brokers, as brokers are spun up and down, depending on load
Broker Control — this monitors the brokers under Fabric8 Messaging’s control and monitors load — and it decides if more ActiveMQ brokers are needed, or less — depending on load. An embedded rules engine is used to make the decisions.
Fabric8 Messaging utilises Fabric8 and Kubernetes and its individual components are all independently scalable: