A point‑to‑point communication delivers a message to exactly one of the consumers that is reading from the channel, so it will be processed just once. A publish‑subscribe channel delivers each message to all the attached or subscribed consumers. Services use publish‑subscribe channels for the
one‑to‑many interaction styles described before.
Message-based asynchronous communication is especially well suited to propagate data updates across a microservice architecture. For example, if one microservice’s data is updated but that same data needs to be propagated to a different microservice, that kind of inter-microservice
communication should be based on asynchronous communication by using integration events between microservices, as in image X-XX.
32 Microsoft Platform and Tools for Docker Multiple protocols for the asynchronous message communications can be used. You could use
message queues for this communication, or you could also use HTTP asynchronously.
One-to-Many Asynchronous message communication
Additionally, you might want to use a Publish/Subscribe mechanism so your communication from the sender will be available to additional subscriber microservices or even external applications in the future.
When using a Publish/Subscribe communication you might be using an Event-Bus interface to publish events to any subscriber. Another possibility (usually for different purposes) is a real-time and one-to- many communication with protocols such as WebSockets and higher level frameworks such as
ASP.NET SignalR.
Asynchronous Real-Time communication
As shown in image X-XX, real-time asynchronous communication means that you can have server code push content to connected clients instantly as it becomes available, rather than having the server wait for a client to request new data.
Figure X-XX. One-to-One async message communication
33 Microsoft Platform and Tools for Docker Since it is real-time, client apps will show the changes almost instantly. This is usually handled by a protocol such as WebSockets. A typical example is when a service communicates a change in the score of a sports game to many client web apps, simultaneously.
Asynchronous Event-Driven communication
When using this type of communication and architectural approach, a microservice publishes an event when something notable happens, such as when it updates a business entity. Other microservices subscribe to those events. When a microservice receives an event, it can update its own business entities, which might lead to more events being published. This subscription/publication system is usually performed by using any implementation of an Event Bus. The Event Bus will be designed as an abstraction/interface with the API needed to subscribe/unsubscribe to events and to publish events plus one or multiple implementations based on any inter-process and messaging communication like a messaging queue or Service Bus supporting asynchronous communication and a subs/pubs model. As introduced in the previous section “Challenges and solutions for Distributed Data Management”, you can use events to implement business transactions that span multiple services, and you will have eventual consistency between those services. An Eventual-Consistent transaction consists of a series of distributed steps. Each step consists of a microservice updating a business entity and publishing an event that triggers the next step.
A very important point is that you might want to communicate the same event to multiple destination microservices that are subscribed to the same event. For that, you can use the Publish/Subscribe messaging based on event-driven communication, as shown in image X-XX. This Pub/Subs
mechanism is not exclusive to the microservice architecture, it is similar to the way Bounded-Contexts
in Domain-Driven Design should communicate or the way you propagate updates from the “writes-
database” to the “reads-database” in CQRS (Command and Query Responsibility Segregation)
architectural approach so you can have eventual consistency between multiple data sources across your distributed system.
34 Microsoft Platform and Tools for Docker In regards to the protocol communication to use for event-driven message-based communications, it depends on your implementation. A reliable queued communication could be achieved by using
AMQP, but using HTTP asynchronously could also be a choice, although less reliable.
What you will probably need is some kind of abstraction level (like an Event-Bus interface) based on a related implementation in classes with code using the API from a service bus like Azure Service Bus with Topics or a queue-based system as RabbitMQ, or even higher level Service Buses like
NServiceBus or MassTranssit, so you can articulate the mentioned Publish/Subscribe system. Note on messaging technologies for production systems: Notice that among the multiple
messaging technologies you can choose for implementing your abstract Event Bus, some of them can be at a different level than others. For instance, RabbitMQ (messaging broker transport) sits on a lower level than other commercial products like Azure Service Bus, NServiceBus (which can work on top of either RabbitMQ and even on top of Azure Service Bus), or MassTranssit (which can work on top of RabbitMQ). It really depends on how many features and out-of-the-box scalability you need for your application. For implementing just an Event Bus proof of concept for your development
environment like in the eShopOnContainers sample, a simple implementation on top of “RabbitMQ
running as a container” might be enough. But for mission critical and production systems needing
hyper-scalability you might want to evaluate and use Azure Service Bus. Or for having high level abstractions and features that make distributed development easier, other commercial and Open Source service buses like NServiceBus, MassTransit or any other like Rebus and Rhino ESB are pretty much recommended for you to evaluate. Of course, you could always build more “service bus features” on top of lower level technologies like RabbitMQ and Docker, but that “plumbing work” might cost you too much for a custom enterprise application.
Challenge: Atomic transactional operation when publishing message based events
One challenge with implementing an event-driven architecture across multiple microservices is how to atomically update state in the original microservice while publishing its related event, in a single transaction. There are a few ways to accomplish this:
1. Using a transactional database table as a message queue that will be the base for an event- creator component that would create the event and publish it.
2. Using transaction log mining. 3. Using the event sourcing pattern.
Resilient publish to the event bus
A challenge when implementing an event-driven architecture across multiple microservices is how to atomically update state in the original microservice while resiliently publishing its related integration event into the event bus, somehow based on transactions. The following are a few ways to accomplish this, although there could be additional approaches, as well:
1. Using a transactional (DTC based) queue as MSMQ (However, this is a legacy approach) 2. Using transaction log mining
3. Using full event sourcing pattern
4. Using a transactional database table as a message queue that will be the base for an event- creator component that would create the event and publish it.
These approaches are discussed in further details in the implementation sections of this documentation.
35 Microsoft Platform and Tools for Docker References – Publish/subscribe, eventual consistency and other DDD patterns
Event Driven Messaging
http://soapatterns.org/design_patterns/event_driven_messaging Publish/Subscribe channel
http://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html CQRS (Command and Query Responsibility Segregation)
http://microservices.io/patterns/data/cqrs.html
https://msdn.microsoft.com/en-us/library/dn568103.aspx Communicating Between Bounded-Contexts https://msdn.microsoft.com/en-us/library/jj591572.aspx Eventual Consistency
https://en.wikipedia.org/wiki/Eventual_consistency Strategies for Integrating Bounded Contexts
http://culttt.com/2014/11/26/strategies-integrating-bounded-contexts/