Once you have decided that you want to have asynchronous and event-driven communication, as explained in the current section, you should choose the service bus product that best fits your needs for production. To reiterate: the sample event bus abstractions and implementation showcased in the eShopOnContainers sample are intended to be used only as a proof of concept. Of course, you could always build your own service bus features on top of lower-level technologies like RabbitMQ and Docker, but the work needed to "reinvent the wheel" might be too costly for a custom enterprise application. For that matter, you can research the forked eShopOnContainers using NServiceBus (additional derived sample implemented by Particular Software). In this case, the abstractions and API to use would usually be directly the ones provided by those high-level service buses instead of your own abstractions (like the simple event bus abstractions provided at eShopOnContainers). If you require high-level abstractions and richer features like Sagas for long-running processes that make distributed development easier, other commercial and open-source service buses like NServiceBus, MassTransit, and Brighter are worth evaluating. But for mission-critical and production systems that need high scalability, you might want to evaluate and use Azure Service Bus. Your choice of product depends on how many features and how much out-of-the-box scalability you need for your application.įor implementing just an event bus proof-of-concept for your development environment, as in the eShopOnContainers sample, a simple implementation on top of RabbitMQ running as a container might be enough. Most of these products can work on top of either RabbitMQ or Azure Service Bus.
For instance, RabbitMQ, a messaging broker transport, is at a lower level than commercial products like Azure Service Bus, NServiceBus, MassTransit, or Brighter. But these technologies are at different levels.
Using message brokers and services buses for production systemsĪs noted in the architecture section, you can choose from multiple messaging technologies for implementing your abstract event bus. There are multiple potential implementations, each using a different technology or infrastructure such as RabbitMQ, Azure Service Bus, or any other third-party open-source or commercial service bus. NET by using a generic event bus interface, as shown in Figure 6-18. This section describes how you can implement this type of communication with. Event-driven communication based on an event bus
#MASSTRANSIT LISTENER UPDATE#
Figure 6-18 below, shows a PriceUpdated event published through an event bus, so the price update is propagated to the Basket and other microservices.įigure 6-18. At each action, the microservice updates a business entity and publishes an event that triggers the next action.
#MASSTRANSIT LISTENER SERIES#
An eventually consistent transaction consists of a series of distributed actions. You can use events to implement business transactions that span multiple services, which give you eventual consistency between those services. It can also have one or more implementations based on any inter-process or messaging communication, such as a messaging queue or a service bus that supports asynchronous communication and a publish/subscribe model. The event bus can be designed as an interface with the API needed to subscribe and unsubscribe to events and to publish events. This publish/subscribe system is usually performed by using an implementation of an event bus.
This is the essence of the eventual consistency concept. When a microservice receives an event, it can update its own business entities, which might lead to more events being published.
Other microservices subscribe to those events. As described earlier, when you use event-based communication, a microservice publishes an event when something notable happens, such as when it updates a business entity.
0 kommentar(er)
