Microservices and SOA using messaging

Question

I've been very interested in trying out microservices/SOA as an architecture and am having a hard time conceptualizing how the integration between services would actually be done.

I like the idea of using messaging to decouple the clients from the services, but don't understand how a system could utilize it exclusively. The typical async operations and pub/sub stuff obviously makes sense - scenarios like creating a new order, broadcasting data for reporting, etc. What I don't understand is whether people typically try to use messaging for common request/reply scenarios - for example, a user hits their "profile" page and part of the data that needs to get rendered on the page is from a user service.

I know common messaging implementations provide REST-like reply/request functionality but is that often used for simple data requests? It seems more likely that microservices would both expose REST endpoints and also register with a message broker for different types of communication it will participate in, but all these presentations I watch of SOA and microservice architecture seem to suggest they only use one or the other..

Thanks for any elaboration/experiences!

Answer 1

I have posted about this before - but generally speaking, synchronous operations (for example, a user clicking a button and expecting some data back) are synchronous for a reason.

That is to say, synchronous - not because of the technology used to process their call - but because of a built-in and generally inflexible expectation on the part of the user that things should happen in real time and not "offline" (even if there is no material difference most of the time).

So, it's generally unwise to put any kind of offline or asynchronous technology stack in between a user and their expected response.

As with all things, exceptions abound (and could spawn a whole new conversation), but certain types of user calls can and should be handled "off-line" depending on the situation.

However, I do feel that the focus of your assertion:

I like the idea of using messaging to decouple the clients from the services

misses the point somewhat. We don't actually want to decouple clients (or consumers) and services.

We would expect a client for, say, the Accounts Payable business capability to be highly coupled to the accounts payable microservice.

Similarly we would expect a high degree of coupling between a service endpoint signature bool ProcessTransaction(Transaction transaction) and the consumer of such an operation.

Where decoupling becomes really important is decoupling between services which support different business capabilities.

And it's here that the benefits of messaging really make a difference. Let me know what you think and if this has helped you at all.

Answer 2

I think when you ask how often "messaging" is used in request/response, you probably mean asynchronous communication.

I'll take a different (opposite) perspective than some of the answers here, and say that you should almost always use async, even in request/response. This is because async means you're not blocking your program waiting for a response, and your program can keep on doing some other processing while waiting for a response.

For example, imagine you are implementing Twitter's homepage. You fire off a bunch of requests to different microservices ("get me recommended followers", "get me latest timeline", etc."). You don't want to block and serialize all of these requests. You want to fire them off async and that creates a much better user experience, because as the responses come back in, they update the UI in realtime.

Twitter uses Finagle (http://twitter.github.io/finagle/guide/index.html) for exactly this (async RPC). It doesn't do some of the things a messaging system would do (in particular, it's really tied to the JVM, and it doesn't implement flow control or queues), but it does implement async request/response.

Answer 3

I just started learning microservices so this is by no means a perfect answer. It is my opinion based on my current understanding though.

If you are creating microservices based on events then a message broker will play a huge role. Lets say you have a service called CreateUserService which is only responsible for gathering the data required to create a user not persisting the data. This data is then published to a queue.

Subscribers to the createUser queue DuplicateUserService, UserDataStore etc... Can then react accordingly to the data within each service.

In the end the client receives data back from another service with relevant information about the attempted event.

Answer 4

What I don't understand is whether people typically try to use messaging for common request/reply scenarios - for example, a user hits their "profile" page and part of the data that needs to get rendered on the page is from a user service.

The key is to avoid request/reply altogether. Technically this is possible if your whole stack allows async messaging, including for web front-end by using something like a WebSocket in a Single Page Application (SPA). For a practical example you can look into Typesafe's Reactive Maps template (https://www.typesafe.com/activator/template/reactive-maps-java).

Answer 5

I have not used REST but I use WSDL to allow the communication between the layers. Integration between services is very simple they talk to each other like nested functions at the back end or simply used XMLs and JSONs if the requests hop from server to server.

Here server is the host of internal web-services. And based on requirement queuing can be provided to individual services. But at the end, only one response is sent to the caller from backend.