Microservices are groupings of lightweight services, interconnected, although independent of each other, without direct coupling or dependency. As such, microservices allow flexibility in terms of infrastructure: Application traffic is routed to collections of services that may be distributed across CPU, disk, machine and network as opposed to a single monolithic platform designed to manage all traffic.

In its simplest form, a microservice consists of an event-listener and a message-dispatcher (see Figure 1). The event-listener polls a service-bus -- generally a durable message-queue -- and handles incoming messages. Messages consist of instructions bound in metadata and encoded in a data-interchange format such as JSON, or Protobuf.

A connection is established on application start-up, and is ideally maintained for the duration of the application's lifetime.

Consuming Messages
A single running instance (generally an *.exe) can connect to RabbitMQ and consume messages in a single-threaded, blocking manner. However, this is not the most scalable solution. Processes that read messages from RabbitMQ must subscribe to a Queue, or Exchange. Once subscribed, RabbitMQ manages message delivery, in terms of even-distribution through round-robin, or biased distribution, depending on your Quality of Service (QOS) configuration. Please refer to this post for a more detailed explanation as to how this works.

For now, consider that our microservice executable can generate multiple processes, each running on a dedicated thread, to consume messages from RabbitMQ in a parallel manner. The AMQPAdapter class shown in Listing 2 contains a method designed to invoke such processes.

Notice the input variable of type "AMQPConsumer." Let's take a look at that class in more detail. Essentially, the class contains Start and Stop methods, and an event-handler to handle message-delivery, as shown in Listing 3.

Notice the static declaration of the RabbitMQAdapter class. RabbitMQ connections in this library are thread-safe; a single connection will facilitate all requests to RabbitMQ.
RabbitMQ implements the concept of Channels, which are essentially subsets of a physical connection. Once a connection is established, Channels, which are logical segments of the underlying Connection, can be invoked in order to interface with RabbitMQ. A single RabbitMQ connection can support up to 65,535 Channels (although I would personally scale out client instances rather than establish such a high number of Channels). Let's look at publishing a message to RabbitMQ, as shown in Listing 5.

Notice the _connection.CreateModel() method call, which establishes a Channel to interface with RabbitMQ. The Channel is encapsulated within a using block; once we've completed our operation, the Channel may be disposed. Channels are relatively cheap to create, in terms of resources, and may be created and dropped liberally.

Messages are sent in UTF-8, byte-format. Here is how to publish a message to RabbitMQ:

var message = "Hello, World!";
adapter.Publish(message, "queueName");

This method also contains overloaded exchangeName and routingKey parameters. These are used to control the flow of messages through RabbitMQ resources. This concept is well documented here.
Now let's attempt to read our message back from RabbitMQ:

The TryGetNextMessage method reads the next message from the specified Queue, when available. The method will return false in the event that the Queue is empty, after the specified timeout period has elapsed.

Consistent Message Polling
Reading one message at a time may not be the most efficient means of consuming messages. I mentioned the AMQPConsumer class at the beginning of this post. This code outlines a means to continuously read messages from a RabbitMQ Queue:

Note the RabbitMQConsumerCatchAll class instantiation. This class is an implementation of RabbitMQConsumer. All potential exceptions that occur will be handled by this consumer and persisted back to the client along the same Channel as valid messages. As an alternative, the RabbitMQConsumerCatchOne instance can be leveraged instead. Both classes achieve the same purpose, with the exception of their error-handling logic. The RabbitMQConsumerCatchOne class will disconnect from RabbitMQ should an exception occur.

Now that we're at this point, it's time to put the app into production, which we'll do in Part 2. We do that as well as explore a number of issues that you need to deal with to ensure that messages reach their intended targets.

About the Author

Paul Mooney is a technology consultant proficient in C#, JavaScript, Java, and Golang, and a well-known software-development mentor. He also created the Encrypted Token Pattern and ARMOR, its .NET implementation. Contact Paul through his blog, http://insidethecpu.com/.

Featured

This week saw two third-party vendors of dev tools -- UX and UI toolkits and controls -- release new offerings that include support for two of Microsoft's main open source frameworks, the cross-platform .NET Core 3.1 and Blazor, which allows for creating browser-based web applications with C# instead of JavaScript.

Clustering non-numeric -- or categorial -- data is surprisingly difficult, but it's explained here by resident data scientist Dr. James McCaffrey of Microsoft Research, who provides all the code you need for a complete system using an algorithm based on a metric called category utility (CU), a measure how much information you gain by clustering.