Scenario:
Currently, we have multi-tier architecture in this pattern
DBLayer => Tasks to DB
SouthBound => Talks to other devices like router/controller
SrvcLayer => Talks to both SouthBound and DBLayer
UILayer => Talks to UI and SrvcLayer
The application is built on Spring 4.2, Java 8, MongoDB.
Requirement:
We need to decouple SouthBound as a separate App or can say Micro Service.
Issue:
We are thinking of 2 ways
Exposing services in SouthBound as REST API and use them in SrvcLayer.
It will add some latency issue and need to figure out the security part as well.
Use Message queue like RabbitMQ. But these calls have to be synchronous. So I am not sure RabbitMQ will help us.
Which approach will be suitable.
Any other suggestion on how to build this usecase.
In our application we have REST API to communicate UI <-> Backend parts of which are in its own turn connected via AMQP.
Btw RabbitMQ seems to have async supoport RabbitMQ asynchronous support so this may be enough.
Sync work of RabbitMQ is still possible (Is it appropriate to use message queues for synchronous rpc calls via ajax, https://www.rabbitmq.com/tutorials/tutorial-six-java.html) but anyway if you're using AMQP synchronously this will end with having latency so I'd say better use REST
Related
I have a small stock-market application with Spring boot and if any product updated I want to serve an updated product to the clients in realtime
does it make sense to use message queues like RabbitMQ and Sse(Server Sent Events) for this, or is there a more sensible solution?
Solution
Publish your updated data to some channel
Your clients should subscribe to that channel to get updated feed in real-time.
Tools
Use in-house setup for RabbitMQ, ActiveMQ, Kafka or other open-source tools and implement WebSocket (For Front end applications)
Use commercial service like Google Cloud PubSub
Readymade and fully packaged solution with supported SDK for backend and frontend, https://www.pubnub.com/.
For this you can use either of
Spring Integration
Web Sockets
JMS
Spring Integration is an implementation of Enterprise Integration Patterns and is ideal for asynchronous processing data at realtime.
However, looking at your scope, it is only about publisher-subscriber pattern. Hence can be solved with JMS.
With JMS the subscribers/consumers can register/de-register dynamically. Also it provides ways to have fall-backs and tracking.
I'm trying to design a system in an event-driven architecture style, trying also to expose REST API to send commands/queries. I decided to use Kafka as a message broker.
The choreography I'm trying to design is the following:
The part that is very obscure to me is how to implement event joins:
billing-service should start creating the user only when it receives the user creation event (1) and the account has been created (2)
api-gateway should return the result to the client only when both account and billing service have finished their processing (2 and 3)
I know I could use other protocols on the client side (e.g. WebSockets) but I prefer not doing that because I will need to expose such API to 3rd party. I could also do an async client call and poll to check if the request has been completed but it appears very complex to manage.
What is the suggested way of implementing such an interaction?
p.s. I'm using Spring Boot and Spring Cloud Stream.
Request/reply messaging on the client side is possible with spring-cloud-stream, but it's a bit involved because it wasn't designed for that, it's intended for unidirectional stream processing.
You would be better off using spring-kafka (ReplyingKafkaTemplate) or spring-integration-kafka (Outbound Gateway) for request/reply on the client side.
On the service side you can use a #StreamListener (spring-cloud-stream) or a #KafkaListener or a spring-integration inbound-gateway.
There are a lot of tutorials and articles (including official site) promoting spring boot as a good tool for building microservices.
Let's say we have some rest api endpoint (User profile) which aggregates data from multiple services (User service, Stat service, Friends service).
To achieve this, user profile endpoint makes 3 http calls to those services.
But in Spring, requests are blocking and as I see, the server will quickly run out of available resources (threads) to serve request in such system.
So to me, it as quite inefficient way to build such systems (compared to non-blocking frameworks, like play! framework or node.js)
Do I miss something?
P.S.: I do not mean here spring 5 with its new webflux framework.
No one prevents you from building an asynchronous microservice architecture with Spring Boot :).
Something along these lines:
Instead of one service calling another synchronously, a service can put events to a queue (e.g. RabbitMQ). The events are delivered to services that subscribe to those events.
Using RabbitMQ and its "exchange" concept, the event producing service doesn't even need to the consumers of its events.
A blog post detailing this with Spring Boot code can be found here: https://reflectoring.io/event-messaging-with-spring-boot-and-rabbitmq/
This is not a limitation of Spring rather it is more to do with the Application Architecture.
For instance, the scenario that you have is commonly solved using Aggregate Design Pattern
While this solution is quite prevalent,it has the limitation of being synchronous, and thus blocking. Asynchronous behaviour in such scenarios should be implemented in an application specific way.
Having said that if you have to call other services in order to be able to serve a response to a request from a client(outside), this is typically an architectural problem. It really doesn’t matter if you are using HTTP or asynchronous message passing (with a request-reply pattern), the overall response time for the outside client will be bad
Also, I have seen quite a few applications which uses synchronous REST calls for external clients, but when communication is needed between internal MicroServices, it should always be asynchronous. You can read an interesting paper on this topic here MicroServices Messaging Patterns
I'm looking for the azure alternative for the Data flow model of Data Source-processor-sink.
I want the three entities to be separate microservices. I want to use messaging as a link between these three.
Basically, Source app takes the data from another service and sends it to processor while processor app acts on it and sends relevant notification/alert to sink.
I'm aware I can use rabbitmq for the messaging but I need to know which one will be better in azure - service bus topics or eventhub? and how can I use them?
At the moment, there isn't a Spring Cloud Stream binder implementation for Azure Event Hubs.
Unless we have this, the out-of-the-box or the custom apps cannot be built as a messaging-microservice app, where Spring Cloud Stream provides the programming model and Spring Cloud Data Flow lets you orchestrate the individual microserivces in to a data pipeline (i.e., source-processor-sink) via the DSL/Drag-and-Drop GUI.
Microsoft was exploring the binder implementation in the past; possibly it would end up in Azure Spring Boot project. Feel free to drop an issue on their backlog.
I have requirement something like this:
once the request is received by my service, i need to send it 2-3 third party servers at a time and get the response from all server and return the response.
How can I achieve that?.
My thought : I can create separate threads for different servers and send the request to all servers parallely, but here the issue is, how I will come to know the threads are finished and consolidate the response from all servers and return to caller.
Is there any other way to do in spring boot(micro service)?.
You can leverage asyn feature supported by Spring Framework. Let's see the folllowing example which issue multiple calls in Async style from Spring's official guides:Async Method
Another possible solution for internal communications between Microserives is to use the message queue.
You didn't specify what type of services are you consuming. If they are HTTP, you may want to use some Enterprise Integrations abstractions (most popular are Spring Integration and Apache Camel).
If you don't want to introduce message bus solution into your microservice, you may want to take a look at AsyncRestTemplate