We are using microservice architecture in our project. We deploy each service to a cluster by using Kubernetes. Services are developed by using Java programming language and Spring Boot framework.Three replicas exist for each service. Services communicate with each other using only events. RabbitMQ is used as a message queue. One of the services is used to send an email. The details of an email are provided by another service with an event. When a SendingEmail event is published by a service, three replicas of email service consume the event and the same email is sent three times.
How can I prevent that sending emails by other two services?
I think it depends on how you work with Rabbit MQ.
You can configure the rabbit mq with one queue for these events and make spring boot applications that represent the sending servers to be "Competing" Consumers.
If you configure it like this, only one replica will get an event at a time and only if it fails to process it the message will return to the queue and will become available to other consumers.
From what you've described all of them are getting the message, so it works like a pub-sub (which is also a possible way of work with rabbit mq, its just not good in this case).
Related
I have 2 spring boot applications
On-premise teller application
Cloud based multi-tenant application that aggregates data from all teller applications
The teller application has to work offline(if connectivity is down) as well. What is the best approach to broadcast events from the teller application to the cloud. I would not prefer to implement code to persist events.
What is the best approach? ReST/message broker or some other approach. If using a message broker, will the spring cloud stream abstraction queue events when the connection to the broker is down and retry.
I would go with the message broker (rabbit, kafka) and spring-cloud-stream, since your use case was exactly what/how it was designed.
The microservcice (your app) is a consumer of the broker, that is: it can publish to and/or consume events from the broker. If the app is down the broker is up and potentially collecting events destined to the down app. Once app is up it consumes queued up events and so on.
I'll stop here given the general nature of your question but feel free to follow up with more details.
I am using rabbitmq in spring boot application. I am using aws ecs for deployment. Now suppose multiple instance is running of my service. and rabbitmq listening for order create is registered with direct exchange.. So what happen when order is placed? will my both the instance of service will get same message? If yes, How to prevent duplicate message on those 2 listeners?
If the service creates multiple Listeners/Consumers for same queue on a direct exchange below mechanism is applicable:
By default, RabbitMQ will send each message to the next consumer, in sequence. On average every consumer will get the same number of messages. This way of distributing messages is called round-robin.
Best Tutorial for this topic: https://www.rabbitmq.com/tutorials/tutorial-two-java.html
I want to know the major difference between VM and JMS component of Mule ESB. Can someone help me to know it.
As per Mule documentation, VM transport is for intra-JVM communication between Mule flows. So, that means when you use a VM in your flow, you can communicate between different flows in the application.
A flow containing VM inbound cannot be called externally from external application as thus the flow is equivalent to a private flow used within the application. By default uses in-memory queues.
Please go through the documentation :- https://docs.mulesoft.com/mule-user-guide/v/3.8/vm-transport-reference
On the other hand as per Mule documentation, JMS is an external host, allows communication between different components of a distributed application and JMS transport lets you easily send and receive messages to queues and topics for any message service which implements the JMS specification.
A flow, which has JMS inbound can be called from externally unlike VM. Documentation is here :- https://docs.mulesoft.com/mule-user-guide/v/3.8/jms-transport-reference
Within the application, if you send the control from one flow to another flow we use VM.VM can be used as both inbound and outbound.
Outside the application, for example, A application want to send something to B application(external application) there we use JMS.
I would like to know if using a JMS in the below scenario is feasible or not.
I am adding a feature of calling an API service which will dispatch the emails to the customer.
So i thought of implementing a JMS in my application where i would put the events or messages in the queue and write a listener in the same application which will process the message and call the rest API service call which will dispatch the message to the customers.
My question was is it good to have a JMS in between the rest call and our application ?
Or should i directly call the rest api to dispatch the messages to the customer ?
I think that depends on the availability and overhead of your rest service.
If you know there will be times that your service will be down, but don't want to impact the process using the API, then JMS queues make since.
Or if you feel the rest service is causing a bottle neck from the API service side and want to queue up the messages somewhere where they can survive an outage of your own, JMS with a provider that supports persistent messages makes since in this case.
Using JMS would also open the door for completely decoupling the two. Whatever application hosts the rest service could just as easily be converted to pull messages from the JMS queue without a need to make a rest call if that seemed more efficient.
Just a few examples of how you could justify using JMS in this scenario.
How does RabbitMQ compare to Mule, I am going to build an application using message oriented architecture and AMQP (RabbitMQ) provides everything i want, but i am perplexed with so many related technology choice and similar concepts like ESB. I am having a doubt if i am making a choice without considering other alternatives.
I am mostly clear that RabbitMQ is a message broker and it helps me in mediating message between producer and consumer (all forms or publish subscribe and i could understand how its used from real examples like twitter , or Facebook updates, etc)
What is Mule, if i could achieve what i do in RabbitMQ using mule, should i consider mule similar to RabbitMQ?
Does mule has a different objective than that of a message broker?
Does mule assumes that underlying it there is a message broker that delivers message to the appropriate mule listeners (i could easily write a listener in RabbitMQ)
Is mule a complete Java bases system ( The current experiment i did with RabbitMQ took me less than 30 Min to write a simple RPC Client Server with client as C# and Server as Java , will such things be done in Mule easily).
Mule is an ESB (Enterprise Service Bus). RabbitMQ is a message broker.
An ESB provides added layers atop of a message broker such as routing, transformations and business process management. It is a mediator between applications, integrating Web Services, REST endpoints, database connections, email and ftp servers - you name it. It is a high-level integration backbone which orchestrates interoperability within a network of applications that speak different protocols.
A message broker is a lower level component which enables you as a developer to relay raw messages between publishers and subscribers, typically between components of the same system but not always. It is used to enable asynchronous processing to keep response times low. Some tasks take longer to process and you don't want them to hold things up if they're not time-sensitive. Instead, post a message to a queue (as a publisher) and have a subscriber pick it up and process it "later".
Mule is a "higher level" service implemented with message broker. From the docs
The messaging backbone of the ESB is
usually implemented using JMS, but any
other message server implementation
could be used
You can build an ESB with rabbit; however, you're going to be limited to sending byte[] packages, and you'll have to build your system out of messaging primitives like topics and queues. It might be a bit faster (based on absolutely no benchmarking, testing or data) because there are fewer layers of translation. Mule provides an abstraction on top of this, speaks a variety of transports, and can handle some routing logic.
Mule is a Enterprise service bus providing end to end integration solution where as Rabbit is message broker for queueing messages between subscriber and receiver.
RabbitMQ, a open source message broker software is written in Erlang programming language and is built on Open Telecom Platform for clustering and failover. It is easy to use, supports a huge number of developer platforms and runs on all major operating systems. It works on a concept called Exchange.
Mule connects RabbitMQ with AMQP connector.