I am developing a series of microservices using Spring Boot and Kafka. For asynchronous communication, I am using Kafka which is working well.
I have a use case where I require synchronous communication between two microservices (a user registers a profile via the user profile service which needs to create an auth account in the auth microservice).
Should I just call the auth service directly (service to service communication) or should I use Kafka?
Any examples or best practise advice would be appreciated.
There are multiple factors that can drive your decision:
Required any acknowledgement from your Auth Service?
if yes:
For Immediate acknowledgement, use http
For not so immediate acknowledgement, Callback pattern can be implemented.
In your case, user profile sends request via Kafka to auth service and it calls
endpoint of user-profile to report status of the job.
if no:
Use queue one for better resiliency.
Error Handling
Think of auth service failure? What should be the reaction of user service ?
if on auth-service failure, user-service should also fail
Use http
if on auth-service failure, user service should not fails.
Use queue
Ideally in user creation and authentication realtime response is given to the client side but if it involves complex process or tasks post user creation queue should be preferred.
For multiple microservices synchronous interaction and to work on their API responses you can build a aggregator service which could serve as a communication medium between different services and work alongside your kafka queue consumer service.
Related
We are architecting a new system where ESB is the centerline channel for service communication. as we don't want our HTML/js client to interact with a bus directly, so we decided to introduce Api (ReST-API) layer where the client will post request to Api than API will put a message in ESB and respective service will subscribe for that particular message and will process it.
so it will be like
UI -> Rest -> ESB -> Service
As I knew no other services will not be interested in this particular message. so just wondering cant we do below??
UI->Rest-> Service and keep ESB used for only inter-service communications not from UI to service path. considering there will be 1000's of UI to service communication.
It all depends on how many subscribers(services) would need this message that is coming from UI. As of now you have identified just one service that needs this data. Introducing an ESB layer would decouple the "Rest" and "Service" layers and in the future if there are more services needing this message, a little change in ESB layer would be sufficient to meet your future needs without disturbing the "Rest" and "Service". Without ESB, you end-up in a tightly coupled pattern. Also, if the service is enhanced in the future, ESB could play a role in data transformation.
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.
I've a Spring boot Application for Web sockets. I'm not using Stomp Web socket.
Is there way we can share web socket sessions across multiple instance of micro service.
Is there a way we can save websocket session in Redis or cassandra?
My use case is, i've multiple instance of my micro service is running, which is listening a kafka queue, so when a message received, i need to send it to the client using web socket session.I'm saving the session in the micro service as a MAP. My problem is any one of my micro service is getting the message, if the session is not available with that micro service the message is not going to the client.
If i'm able to save the websocket sesssion in REDIS or Cassandra, i can query the session and sent to the client.
I can't use Stomp web socket as per the requirement, it has to be normal websocket.
You can't. You have to implement some sort of routing from whatever receives the kafka message, to your micro service.
One simple way to do it would be to store in any datastore (mongo, redis, etc) the IP of the service instance for a given client. That way when you get the message from kafka, an you know who is it for, you lookup which machine has the websocket session for that client. Then you call some http endpoint on that IP that you implement to relay a message for a session it's handling.
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.
Can i use a proxy service without a business service while configuring message flows in Oracle service bus? If so is what scenarios would we use it?
You can create a proxy service that does not use a business service.
Some reasons for such an approach is to create a common proxy module that is used by other proxy services that may do some common message processing before forwarding to a business service.
I think you cannot create a proxy service without a business service call in OSB, but you can call dummy business services that publish on a JMS topic that nobody listens on. This kind of proxy service could implement data transformation (e.g. XSLT) between the request and response, or enrich the response with data retrieved from a lookup table (fn-bea:execute-sql()).
A service bus, like OSB is meant to provide a façade to back-end (business) services: route to and compose existing services. What you are asking for is to create new back-end services which is more suited for Java EE servers or Oracle BPEL.
Update: You can create stand-alone proxy service, if you use pipeline pair and stage, but no route steps.
You can create a proxy service without a business service. A simple scenario is suppose you want to fetch the data from the queue, could be jms or mq, and you don't want to do anything with that data. You just simply want to empty the queue and do not want to store the message. In this case, your purpose can be fulfilled by simply creating a proxy service.