Azure Service Bus
Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics.
Service Bus is used to decouple applications and services from each other, which help us to balance workload.
The message size limit for Service Bus is 1 MB (premium tier).
This video (GERMAN) demonstrates how to expose Azure Service Bus as REST service by using of Azure API Management.
Source: Exposing ServiceBus via Azure API Management | Microsoft Docs
Video: https://docs.microsoft.com/video/media/1de8e6a2-c0ae-4565-902a-be1534538bff/apimsb_mid.mp4
Message Bus Queues and Topics provide
- Temporal decoupling as message producers and consumers do not have to be online at the same time
- Load leveling to smooth out peaks in load by allowing the consuming application to be provisioned for average load rather than peak load
- Load balancing to have multiple consumers listening on a single subscription with each message being handed off to only one of the consumers, thereby balancing load
- Loose coupling to evolve the messaging network without imcating existing endpoints, e.g. adding subscriptions or changing filters to a topic to accommodate new consumers
With Queues, you can have multiple senders, but only one message-consumer receives and process each message.
Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components.
With Queues, there are two different modes available to process messages.
Received & Delete
This mode is suitable where the system can tolerate not processing messages in case of failure. In this mode, once the consumer service reads the message, it will be deleted from the Queue irrespective of the status of the message process.
Peek
This mode is suitable where the system cannot tolerate ignoring messages in case of failure. So here, messages are processed in two stages, as below.
- Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then return the message to the application.
- After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receiving process. Then, the service marks the message as being consumed.
Senders send messages to a topic in the same way that they send messages to a queue, but it varies on a slight factor where 'Topics' can have multiple, independent 'Subscriptions'. Subscriptions are durable by default but can be configured to expire and then be automatically deleted.
We can define rules on a subscription. A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata.
Enable higher throughput levels for Azure Service Bus premium via two new features in public preview today.
First, we are releasing scaling partitions, allowing the use of partitioning for the premium messaging tier. Service Bus partitions enable messaging entities to be partitioned across multiple message brokers. This means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker. Additionally, a temporary outage of a message broker, for example during an upgrade, does not render a partitioned queue or topic unavailable, as messages will be retried on a different partition.
Second, we are making a change to our infrastructure, which will result in more consistent low latency. This is accomplished by switching our storage to a different implementation called local store. During public preview we will create partitioned namespaces using this new feature, but in the future all new namespaces will be created on local store.
Source: Public preview: Performance improving features for Azure Service Bus premium
Comments