1

I am thinking of building an application using a Service Oriented Architecture (SOA).

This architecture is not as complex and messy as a microservices solution (I think), but I am facing similar design problems. Imagine I have services of type ServiceA that send work to services of type ServiceB. I guess, if I use a queue, then load balancing will not be a problem (since consumers will take what they can handle from the queue). But queues tend to generate some bad asynchrony in the code that requires extra effort to fix. So, I was more inclined to use HTTP calls between services, using the efficient and amazing async/await feature of C#. But this generates issues on sharing the workload and detecting services that are saturated or dead.

So my questions are:

  1. Is there a queue that supports some sort of async/await feature and that functions like an HTTP call that returns the result where you need it and not in some callback where you cannot continue your original execution flow?
  2. How do I load-balance the traffic between services and detect nodes that are not suitable for new assignments when using HTTP? I mean, I can probably design something by myself from scratch, but there ought to be some standard way or library or framework to do that by now. The best I found online was this, but it is built for microservices, so I am not sure if I can use it without problems or overkills.

Update: I have now discovered this question, that also asks for awaitable queues: awaitable Task based queue ...and also discovered Kubernetes, Marathon, and the like.

user2173353
  • 4,316
  • 4
  • 47
  • 79
  • All queues and calls can be async. It's just network IO. The question is whether the library supports it but likely it does. Another question is if you are actually limited on threads. If not, async IO has zero advantages but development and perf costs. – usr Oct 15 '18 at 08:07
  • 1
    If you put each service behind a load balancer you can just call the LB endpoint. If each service denies additional client requests if the service is overloaded then callers can easily detect unavailable services. Short timeouts can be useful, too. – usr Oct 15 '18 at 08:09
  • I have no experience with implementing request/reply on top of a queue, but you can write your own async code that hides the mechanic and makes it as easy as `await CallServiceByQueueAsync(...)`. That said, a queue seems mostly pointless if you need the result synchronously. An HTTP call to a load balancer seems easier to do. – usr Oct 15 '18 at 08:11
  • @usr Yes. I was mostly looking for a request/reply feature for queues. One advantage there is that with the load balancer you will have to fallback to other services on a deny-reply, while with a queue it is the service that picks up the work when it can handle it. I feel that this can save time by reducing the number of calls or reduce the complexity, since you don't have a load balancer that tracks the state of each service so often. But it seems that existing solutions like Kubernetes can solve the problem. Although, designing an awaitable queue would be quite interesting. – user2173353 Oct 15 '18 at 09:53

1 Answers1

1

Regarding your first question, NServiceBus, which is a commercial framework for .NET that abstracts message transports and adds many features on top of them, has the exact feature that you are looking for. They actually call it "callbacks" and the usage is as follows:

Assuming you have a Message to send to a backend service and a Response that you expect back, you would do, in ServiceA:

var message = new Message();
var response = await endpoint.Request<ResponseMessage>(message);
log.Info($"Callback received with response:{response.Result}");

Where endpoint is an NServiceBus artifact that allows you to send messages and receive messages.

What this simple syntax will do is put Message in a queue and wait (asynchronously) until the message has been handled by a backend service and it has replied to it. The response is a message of type Response in a queue.

In ServiceB, you would do:

public class Handler : IHandleMessages<Message>
{
  public Task Handle(Message message, IMessageHandlerContext context)
  {
    var responseMessage = new ResponseMessage
    {
        Result = "TheResult"
    };
    return context.Reply(responseMessage);
  }
}

This allows you to have multiple ServiceA nodes sending messages to multiple ServiceB nodes (competing consumers on a single queueu). NServiceBus takes care of routing the response to the right ServerA for every given message.

Note that this has the disadvantage that if ServerA goes down while waiting a response, you'll never receive the response. For this reason, this pattern is not recommended for most scenarios.

Regarding your question number 2, I would say a load balancer would do the job. For more complex scenarios, you could look at Service Fabric.

Francesc Castells
  • 2,692
  • 21
  • 25