Event driven Kubernetes service

1/13/2020

Im looking for an inter-service communication solution.

I have 1 service and multiple pods with an incoming gRPC stream. The initial request calls out to an external resource which eventually triggers a request back to this service with a status message. This is on a separate thread and for this example ends up going to Pod B. I would like PodA to respond with this status message. I have tried to demonstraite this with the workflow below.

service workflow

The obvious solution here is to add some sort of messaging pattern but I would am looking for help in determining which is the best approach. The example below introduces a service mesh sidecar which would route external requests to a queue which Pod A would then subscribe to. If using AMQP, I would probably look to use direct exchange.

servicemesg-solution

Any further information needed, please let me know.

-- Christo
design-patterns
grpc
kubernetes
message-queue
messaging

1 Answer

1/13/2020

Pub-Sub communication between two microservices is a good communication pattern. The book Cloud Native Patterns describes exactly this, and the advantage using this pattern over request-response in some cases. See chapter 12.

12.2 Moving from request/response to event driven

12.3 The event log

12.4 Event sourcing

This can be implemented with multiple technologies, but using Kafka with microservices is a good fit. Kafka is also a distributed system, designed for cloud, similar to the principles used in Kubernetes.

Your example

To apply this to your example, the queue is the Kafka broker (or RabbitMQ?) and you need a way to post data from the External Resource to the broker. If the External Resource always reply to the pod that the request was from, a sidecar may be a solution. If the "reply address" can be configured, this could be an independent "adapter service" like e.g. Kafka REST proxy if Kafka is used as broker. There is probably corresponding proxies for e.g. RabbitMQ.

-- Jonas
Source: StackOverflow