Waldemar Quevedo on the NATS team covers why NATS is a great fit as a microservices control plane, and how to build simple, resilient, highly scalable microservices using NATS with the flexible integration patterns it provides.

1. Simplified Messaging for Microservices with NATS
Waldemar Quevedo /
SF Microservices Meetup / August 2017
@wallyqs
1 . 1

2. About this talk
What is NATS
Design from NATS
Building systems with NATS
2 . 1

3. What is NATS?
High Performance Messaging System
Created by
First written in in 2010
Originally built for Cloud Foundry
Rewritten in in 2012
Much better performance
Open Source, MIT License
Derek Collison
Ruby
Go
https://github.com/nats-io
3 . 1

4. NATS v1.0.0 milestone reached
4 . 1

5. What is NATS useful for?
Used in production by thousands of users for…
Building Microservices Control Planes
Internal communication among components
Service Discovery
Low Latency Request Response RPC
Fire and Forget PubSub
5 . 1

6. Acts as an always available dial-tone
6 . 1

7. Performance
7 . 1

8. single byte message
Around 10M messages/second
8 . 1

9. Better benchmarks
From 's awesome blog
(he is now part of the NATS team too )
(2014)
@tyler_treat
http://bravenewgeek.com/dissecting-message-queues/
9 . 1

10. 10 . 1

11. NATS = Performance +
Simplicity
11 . 1

12. Design from NATS
Design constrained to keep it as operationally simple and reliable as possible while still
being both performant and scalable.
12 . 1

13. Simple & Lightweight Design
TCP/IP based
Plain Text protocol with few commands
Easy to use API
Small binary of ~7MB
Little config
Clustering for HA (full mesh topology)
Just fire and forget, no built-in persistence
At-most-once delivery guarantees
13 . 1

14. NATS Streaming
For at-least-once delivery check (also OSS, MIT License).
It is a layer on top of NATS core which enhances it with message redelivery features and persistence.
NATS Streaming
https://github.com/nats-io/nats-streaming-server
14 . 1

15. The NATS Protocol
Client -> Server
| PUB | SUB | UNSUB | CONNECT |
Client <- Server
| INFO | MSG | -ERR | +OK |
Client <-> Server
| PING | PONG |
15 . 1

16. Simple Protocol == Simple Clients
16 . 1

17. Given the protocol is simple, NATS clients libraries tend to have a very small footprint as
well.
17 . 1

18. Clients
18 . 1

19. Go (canonical implementation)
nc, err := nats.Connect()
// ...
nc.Subscribe("hello", func(m *nats.Msg){
fmt.Printf("[Received] %s", m.Data)
})
nc.Publish("hello", []byte("world"))
19 . 1

20. Ruby (Eventmachine & Pure Ruby)
require 'nats/client'
NATS.start do |nc|
nc.subscribe("hello") do |msg|
puts "[Received] #{msg}"
end
nc.publish("hello", "world")
end
20 . 1

21. Python (Asyncio)
yield from nc.connect()
@asyncio.coroutine
def handler(msg):
print("[Received] {data}".format(
data=msg.data.decode()))
# Coroutine based subscriber
yield from nc.subscribe("foo", cb=handler)
yield from nc.publish("foo", "bar")
21 . 1

22. Node.js
var nats = require('nats').connect();
// Simple Publisher
nats.publish('foo', 'Hello World!');
// Simple Subscriber
nats.subscribe('foo', function(msg) {
console.log('[Received] ' + msg);
});
22 . 1

23. C
natsConnection_Publish(nc,"foo",data,5);
natsConnection_Subscribe(&sub,nc,"foo",onMsg, NULL);
void
onMsg(natsConnection *nc, natsSubscription *sub,
natsMsg *msg, void *closure)
{
printf("[Received] %.*sn",
natsMsg_GetData(msg));
// ...
}
23 . 1

24. C#
using (ISyncSubscription s = c.SubscribeSync("foo"))
{
for (int i = 0; i < 10; i++)
{
Msg m = s.NextMessage();
System.Console.WriteLine("[Received] " + m);
}
}
24 . 1

25. Java
// Simple Publisher
nc.publish("foo", "Hello World".getBytes());
// Simple Async Subscriber
nc.subscribe("foo", m -> {
System.out.println("[Received] %sn",
new String(m.getData()));
});
25 . 1

26. Community contributing as well
C C# Java
Python NGINX Go
Node.js Elixir Ruby
PHP Erlang Rust
Haskell Scala Perl
( italics → community contributed)
26 . 1

27. Asynchronous IO
Note: Most clients have asynchronous behavior
nc, err := nats.Connect()
// ...
nc.Subscribe("hello", func(m *nats.Msg){
fmt.Printf("[Received] %s", m.Data)
})
for i := 0; i < 1000; i ++ {
nc.Publish("hello", []byte("world"))
}
// No guarantees of having sent the bytes yet!
// They may still just be in the flushing queue.
27 . 1

28. Asynchronous IO
In order to guarantee that the published messages have been processed by the server, we can do an extra
ping/pong to confirm they were consumed:
Then flush the buffer and wait for PONG from server
nc.Subscribe("hello", func(m *nats.Msg){
fmt.Printf("[Received] %s", m.Data)
})
for i := 0; i < 1000; i ++ {
nc.Publish("hello", []byte("world"))
}
// Do a PING/PONG roundtrip with the server.
nc.Flush()
SUB hello 1rnPUB hello 5rnworldrn..PINGrn
28 . 1

29. Asynchronous IO
Worst way of measuring NATS performance
nc, _ := nats.Connect(nats.DefaultURL)
msg := []byte("hi")
nc.Subscribe("hello", func(_ *nats.Msg) {})
for i := 0; i < 100000000; i++ {
nc.Publish("hello", msg)
}
29 . 1

30. 30 . 1

31. The client is a slow consumer since it is not consuming the messages which the server is sending fast
enough.
Whenever the server cannot flush bytes to a client fast enough, it will disconnect the client from the
system as this consuming pace could affect the whole service and rest of the clients.
NATS Server is protecting itself
31 . 1

32. NATS = Performance +
Simplicity + Resiliency
32 . 1

33. Also included
Subject routing with wildcards
Authorization
Distribution queue groups for balancing
Cluster mode for high availability
Auto discovery of topology
Secure TLS connections with certificates
/varz monitoring endpoint
used by
Configuration reload (New in v1.0.0)
Send signal to reload settings in conf file
nats-top
33 . 1

34. Subjects Routing
Wildcards: *
e.g. subscribe to all NATS requests being made on the demo site:
SUB foo.*.bar 90
PUB foo.hello.bar 2
hi
MSG foo.hello.bar 90 2
hi
telnet demo.nats.io 4222
INFO {"auth_required":false,"version":"0.9.4",...}
SUB _INBOX.* 99
MSG _INBOX.ioL1Ws5aZZf5fyeF6sAdjw 99 11
I can help!
34 . 1

35. Subjects Routing
Full wildcard: >
Subscribe to all subjects and see whole traffic going through the server:
SUB hello.> 90
PUB hello.world.again 2
hi
MSG hello.world.again 90 2
hi
telnet demo.nats.io 4222
INFO {"auth_required":false,"version":"0.9.4",...}
sub > 1
+OK
35 . 1

36. Subjects Authorization
Clients are not allowed to publish on _SYS for example:
PUB _SYS.foo 2
hi
-ERR 'Permissions Violation for Publish to "_SYS.foo"'
36 . 1

37. Subjects Authorization
Can customize disallowing pub/sub on certain subjects via server config too:
authorization {
admin = { publish = ">", subscribe = ">" }
requestor = {
publish = ["req.foo", "req.bar"]
subscribe = "_INBOX.*"
}
users = [
{user: alice, password: foo, permissions: $admin}
{user: bob, password: bar, permissions: $requestor}
]
}
37 . 1

38. Building systems with NATS
38 . 1

39. Scenario
Service A needs to talk to services B and C
39 . 1

40. Familiar scenario
Horizontally scaled…
40 . 1

41. Communicating within a distributed system
Just use HTTP everywhere?
Use some form of point to point RPC?
What about service discovery and load balancing?
What if sub ms latency performance is required?
41 . 1

42. Communicating through NATS
Using NATS for internal communication
42 . 1

43. HA with NATS cluster
Avoid SPOF on NATS by assembling a full mesh cluster
43 . 1

44. HA with NATS cluster
Clients reconnect logic is triggered
44 . 1

45. HA with NATS cluster
Connecting to a NATS cluster of 2 nodes explicitly
Bonus: Cluster topology can be discovered dynamically too!
srvs := "nats://10.240.0.11:4222,nats://10.240.0.21:4223"
nc, _ := nats.Connect(srvs)
45 . 1

46. We can start with a single node…
46 . 1

47. Then have new nodes join the cluster…
47 . 1

48. As new nodes join, server announces INFO to clients.
48 . 1

49. Clients auto reconfigure to be aware of new nodes.
49 . 1

50. Clients auto reconfigure to be aware of new nodes.
50 . 1

51. Now fully connected!
51 . 1

52. On failure, clients reconnect to an available node.
52 . 1

53. We can start with a single node…
53 . 1

54. Then have new nodes join the cluster…
54 . 1

55. As new nodes join, server announces INFO to clients.
55 . 1

56. Clients auto reconfigure to be aware of new nodes.
56 . 1

57. Clients auto reconfigure to be aware of new nodes.
57 . 1

58. Now fully connected!
58 . 1

59. On failure, clients reconnect to an available node.
59 . 1

60. Communicating using NATS
60 . 1

61. Heartbeats
For announcing liveness, services could publish heartbeats
61 . 1

62. Heartbeats → Discovery
Heartbeats can help too for discovering services via wildcard subscriptions.
nc, _ := nats.Connect(nats.DefaultURL)
// SUB service.*.heartbeats 1rn
nc.Subscribe("service.*.heartbeats", func(m *nats.Msg) {
// Heartbeat from service received
})
62 . 1

63. Distribution Queues
Balance work among nodes randomly
63 . 1

64. Distribution Queues
Balance work among nodes randomly
64 . 1

65. Distribution Queues
Balance work among nodes randomly
65 . 1

66. Distribution Queues
Service A workers subscribe to service.A and create workers distribution queue group for balancing
the work.
nc, _ := nats.Connect(nats.DefaultURL)
// SUB service.A workers 1rn
nc.QueueSubscribe("service.A", "workers",
func(m *nats.Msg) {
nc.Publish(m.Reply, []byte("hi!"))
})
66 . 1

67. Distribution Queues
Note: NATS does not assume the audience!
67 . 1

68. Distribution Queues
All interested subscribers receive the message
68 . 1

69. Lowest latency response
Service A communicating with fastest node from Service B
69 . 1

70. Lowest latency response
Service A communicating with fastest node from Service B
70 . 1

71. Lowest latency response
NATS requests were designed exactly for this
nc, _ := nats.Connect(nats.DefaultURL)
ctx, cancel := context.WithTimeout(context.Background(), 250*time.Millisecond)
defer cancel()
msg, err := nc.RequestWithContext(ctx, "service.B", []byte("help"))
if err == nil {
fmt.Println(string(msg.Data))
// => sure!
}
nc, _ := nats.Connect(nats.DefaultURL)
nc.Subscribe("service.B", func(m *nats.Msg) {
nc.Publish(m.Reply, []byte("sure!"))
})
71 . 1

72. Handling a NATS timeout
Note: Making a request involves establishing a client timeout.
This needs special handling!
ctx, cancel := context.WithTimeout(context.Background(), 250*time.Millisecond)
defer cancel()
_, err := nc.RequestWithContext(ctx, "service.A", []byte("help"))
fmt.Println(err)
// => context deadline exceeded
72 . 1

73. Handling a NATS timeout
NATS is fire and forget, reason for which a client times out could be many things:
No one was connected at that time
service unavailable
Service is actually still processing the request
service took too long
Service was processing the request but crashed
service error
73 . 1

74. Confirm availability of service node with request
Each service node could have its own inbox
A request is sent to service.B to get a single response, which will then reply with its own inbox, (no
payload needed).
If there is not a fast reply before client times out, then most likely the service is unavailable for us at that
time.
If there is a response, then use that inbox in a request
SUB _INBOX.123available 90
PUB _INBOX.123available _INBOX.456helpplease...
74 . 1

75. Wrapping up
75 . 1

76. NATS is a simple, fast and reliable solution for the internal communication of a distributed system.
It chooses simplicity and reliability over anything else.
76 . 1

77. NATS Streaming FAQ
Clustering is coming…
77 . 1

78. NATS Office Hours
Active discussion in the newly launched community meetings.
78 . 1

79. Questions?
/
Play with the demo site!
telnet demo.nats.io 4222
github.com/nats-io @nats_io
79 . 1