Practical NATS: From Beginner to Pro

By Waldemar Quevedo

Learn to use NATS and messaging as a solution for communication between services. The NATS project has been around since 2010, but it has become more popular in recent years due to how well it fits into the paradigm of cloud native applications and microservices architectures. It’s fast becoming a very attractive option thanks to its great performance characteristics--a single server can push millions of messages per second--and overall simple design.

First you will learn the fundamentals of NATS, such as its design, protocol and the styles of communications it enables, internals of the NATS clients, and how to use the basic API provided by all the official clients. You will also understand how to setup and configure NATS servers using the configuration file. 

Next you'll work with real-world projects and see how to develop a production-ready cloud native application using NATS as the control plane over which clients communicate. Finally you’ll learn advanced usage of the NATS clients, such as implementing heartbeats based failure detectors, tracing or collecting multiple responses from a single request.

Perhaps you are familiar with REST-style APIs, and want to make the transition into a messaging-based approach instead. Practical NATS is the perfect place to start.

What You'll Learn

• Use NATS to build applications which use it as the control plane for communication among components
  
• Explore the fundamentals of NATS such as how the protocol works under the hood to more advanced communication styles which are possible with the basic building blocks provided by the client
  
• Setup, operate, and configure NATS servers, as well as how to troubleshoot common failure scenarios
  

Who This Book Is For

Anyone looking for a solution for some of the problems which come along with microservices and cloud native application development, such as service discovery, low latency requests, load balancing, tracing and monitoring for example. Also adopters of NATS who need further help getting started using it. Ideally you should have some familiarity with Go as that is the language of the code examples.

• Language: English
• Publisher: Apress
• Release date: Jun 7, 2018
• ISBN: 9781484235706

Book preview

© Waldemar Quevedo 2018

Waldemar QuevedoPractical NATShttps://doi.org/10.1007/978-1-4842-3570-6_1

1. Introduction to NATS

Waldemar Quevedo¹ 

(1)

San Francisco, California, USA

NATS is a high-performance messaging system created by Derek Collison in 2010. It was originally built to serve as the message bus for Cloud Foundry, handling internal communication among components of the system. With the rise of microservices and cloud native paradigms, NATS has increased in popularity, becoming a mainstream piece of modern cloud architectures. The nats-io/gnatsd repository in GitHub now has over 3K stars and there is a growing ecosystem of tools and projects that us NATS as part of their architecture, as many have found it useful to address concerns such as:

Service discovery

Low latency communication

Load balancing

Notifications and events handling

In this chapter, you will learn:

What NATS is and when to consider using messaging

NATS’ features and design

A brief history of the project

Using NATS for Messaging

NATS is at its core a Publish/Subscribe (PubSub) system. The PubSub messaging model allows clients in a system to communicate without having to deal with the precise endpoints of where the services are located in the network, delegating this responsibility instead to the messaging system (see Figure 1-1). Clients become subscribers (or consumers) by registering interest into a subject, then whenever a publisher (or producer) client emits a message on that subject, the messaging system will deliver it to the available subscribers that were interested in that topic.

../images/462783_1_En_1_Chapter/462783_1_En_1_Fig1_HTML.jpg

Figure 1-1

Publish/subscribe messaging

In NATS, this message delivery is brokered by the NATS Server (gnatsd). Clients establish a TCP connection to it and follow the NATS protocol, which was designed for simple and efficient PubSub messaging. Listing 1-1 provides a basic example of using telnet to interact with the NATS Server, using the demo.nats.io endpoint which publicly available for testing.

telnet demo.nats.io 4222

INFO {server_id:EiRJABZmVpWQDpriVqbbtw,...,max_payload:1048576}

SUB greetings 1

+OK

PUB greetings 12

Hello World!

+OK

MSG greetings 1 12

Hello World!

Listing 1-1

Hello World, NATS Style

The previous (albeit simple) example already shows quite a bit of the basic, yet powerful, feature set that NATS provides. We are making a subscription on the greetings subject (SUB), then publishing (PUB) and receiving a message (MSG) on that same subject. Here the message published is an opaque blob of data (in this case just an array of bytes with the Hello World! Characters, although we could have used any type of encoding as part of the payload). The NATS protocol is fairly straightforward with just a few number of commands, and this helps in making the implementation of the clients less complex.

Simplicity is a recurrent theme in NATS, as the project from its foundations had as a goal to be a lightweight messaging system and do less overall. Unlike other messaging systems, the NATS Server will only be keeping limited state for the client and only as as long as it has an established connection to the server. As soon as the client disconnects, the server will clear up any state related to the client, and it will not persist any messages and deliver them to the client in case it later reconnects, considering it a fresh new session with the server instead.

Another distinguishing factor of NATS is its great performance. NATS excels at enabling low-latency communication among services, and the way that the request response mechanism works in the clients was designed to address this specific use case in mind. Derek originally came up with the idea from a lesson learned during his time at Google, where making a request would involve a large number of machines responding back, but the client making the request would care only about a single response, namely the fastest one.

Thorough benchmarks done by Tyler Treat, who has spent significant time documenting the trade-offs taken by multiple messaging systems on his blog at bravenewgeek.com, demonstrate that NATS shows predictable, tighter tail latencies¹ in request/response round-trip benchmarks, especially when dealing with smaller messages. By default, the maximum payload size for a single NATS message is 1MB (although this can be tuned in the server).

Messaging Over the REST

Although these days HTTP-based REST APIs are very popular and best practices are well known, using messaging-based approaches instead for communicating offer a number of benefits when dealing with complex distributed systems. As previously mentioned, the PubSub model helps us decouple the services and instead just focus on communicating and sending the messages.

Consider for example what is involved in making an HTTP request. First, it is needed to look up an available endpoint (e.g., via DNS) of the service to which the client can connect and make the request. At this point it may still be possible that the endpoint is actually unhealthy, so it would be needed to retry and attempt to connect to another endpoint of the service. After successfully establishing a connection, the client will make the request and wait for the response back synchronously, then finally close the connection. In many programming languages, developers need to carefully manage the resources involved throughout. In Go, for example, it is a common programming error to leak sockets when using the net/http package, thus requiring careful code review or help via static analysis methods.

In comparison, a NATS-based request involves much less overhead, both in terms of the protocol and what is needed to keep in mind when making it. There is no need to have an established point-to-point connection against the service to which we are making the request; instead, the client ought to be connected to an available NATS Server already and just publish the message, then wait for the message containing the reply to be delivered asynchronously.

Do Not Assume the Audience

When using NATS, we are advised to never assume the audience of who is going to be consuming the message, as there can be multiple consumers for the same message for various independent reasons. NATS has support for wildcard subscriptions on a subject, and with enough permissions, it is possible to audit or trace every single message being sent through the wire without affecting how other parts of the systems are communicating. In Figure 1-2, there can be a number of worker clients subscribed to a subject that can reply to published requests, but all these requests are being logged by an audit client that does not reply.

../images/462783_1_En_1_Chapter/462783_1_En_1_Fig2_HTML.jpg

Figure 1-2

Example NATS request/response flow

NATS subscriptions by default have fan-out behavior and all the clients that have registered interested onto a subject will be receiving the message, but there is another type of subscriptions that make it possible to have a group of subscribers form a distributed queue with no server-side configuration so that messages sent are load balanced randomly to the multiple consumers (see Figure 1-3).

../images/462783_1_En_1_Chapter/462783_1_En_1_Fig3_HTML.jpg

Figure 1-3

Load balancing using NATS distributed queues

It should be noted that the term queue is often misinterpreted by users new to NATS. That is, there is no queuing per se in the NATS Server. Instead, queue in NATS simply means that a message is randomly delivered to only one of the subscribers belonging to the same queue group (a name is specified when creating the queue subscription), unlike for regular subscriptions where a message is sent to all subscriptions subscribing to the same (or matching) subject. But for both pub/sub and queues, NATS subscriptions must be connected to a server in order to receive messages.

NATS As an Always Available Dial Tone

It could be said that the main design constraints that define the style of the NATS project are simplicity, performance, and reliability. Having these traits as core values of the project have resulted in a system that does much less in comparison to other messaging systems, notably it does not offer any persistence or buffering. It is true fire and forget.

A metaphor often used when talking about NATS is that it is intended to act as an always available dial tone. According to Derek Collison, one of his goals with NATS is to have a system that chooses to be available rather than locking up around one client and one action to the detriment of everyone else; imagine if one person able to connect to the electric company could turn off the power for a whole city!. So NATS is the opposite in this regard in comparison to other enterprise messaging systems, and it will try instead to protect itself at all costs to be available for all users.

When using one of the available NATS client libraries, internally they will try to have an always established connection to one of the available NATS Servers, then in case a server fails, NATS will reconnect to another available server in the pool. NATS supports high-availability via a clustering mode that is set up as a full-mesh of the servers. As long as a client is connected to any of the server nodes in the cluster, it will be able to communicate with other clients (see Figure 1-4).

../images/462783_1_En_1_Chapter/462783_1_En_1_Fig4_HTML.jpg

Figure 1-4

Highly available NATS clustering full-mesh topology

In case there is a connection that’s accumulating too much data without draining it from the server, the NATS Server will protect itself and disconnect the client from the system, reporting a slow consumer error (see Figure 1-5). By default, if a client fails to drain the pending data that the server is holding for the client for over two seconds, the server will disconnect the client (this too can be tuned in the server). You can find more information on how to handle slow consumer conditions in Chapter 9, in the troubleshooting slow consumers section.