NATS for Modern Messaging and Microservices

Presented by Alberto Ricart, Principal Engineer, NATS

•Community and Ecosystem Manager, NATS.io

• Ways to get involved in NATS Community:-http://nats.io/community/

Brian Flannery

@brianflannerybrian.flannery@apcera.com

•Principal Engineer at Apcera•Previously with

-TIBCO > 15 years-Informatica

•Building messaging based systems > 20 years

Alberto Ricart

@alberto.ricartalberto.ricart@apcera.com

- Learn/review messaging basics- Use messaging patterns

- Describe a sample microservices application‣See how NATS and messaging features help us make our

services better

What this webinar will cover

Part 1: Messaging Basics

๏ Messages - are the unit of data exchange๏ Producers - send messages to the server๏ Consumers - receive messages from the server๏ Messaging Server - distributes messages from producers to

consumers

Messaging architecture

๏Have a subject that describes the message contents๏A payload{location: {lat: 45.678, lng: 123.456}}

Messages

๏Subject names are extremely important‣They specify the destination of the message

Pokenats.eden-service.12.hb.1234๏They consist of one or more elements (tokens) separated by dots

‣The elements can be used to create a subject name hierarchies

‣Individual elements can be thought of as metadata which a service could use while processing the message

What’s in a subject?

๏Send messages to the server under a specific subject - ‘publishers’

๏Don’t assume the audience of the message‣Don’t care who consumes the message

๏A publisher may specify an optional “reply” subject to change the meaning of the message

Producers

๏ Subscribe to receive messages matching a subscription๏ Can specify a queue group name

‣Single member of a queue group is chosen randomly to receive the message

๏ Can specify how many messages to receive before auto-canceling

•This is a big deal

Consumers

๏ Subscribers can specify wildcardspokenats.eden-service.>pokenats.*.*.hb.100

๏ ‘*’ matches any value in that element๏ ‘>’ matches all elements that follow

‣‘>’ is only valid at the end of the subject

Subscription wildcards

๏ Highly performant, extremely light-weight๏ Clustered servers/cluster-aware clients

‣Built-in resiliency and high availability๏ Text-based protocol (payload is an array of bytes)

‣Use telnet to explore๏ Monitorable on a dedicated port - returning JSON data describing

the state of the server

NATS server features

Chart source: http://bravenewgeek.com/dissecting-message-queues/

๏ Server protects itself first‣Auto-pruning of slow/non-responsive clients ‣Disconnects clients that send bad protocol messages

๏ At most once delivery๏ Client APIs for many languages

‣Community contributed: Spring, Lua, PHP, Python, Scala, Haskel, C# MyNatsClient

‣Easy to develop a client. Get involved!

NATS server features (Cont.)

๏ Provides additional features, built on top of NATS‣Clients publish to a streaming server‣Messages stored until number or size limits are reached‣Subscribers can request messages sent earlier

•Start with first/last/n-th/etc message‣Durable subscriptions

•Resume previous session‣At least once delivery

NATS streaming

Part 2: Messaging Patterns

- Publish-Subscribe- Queueing- Request-Reply

Three simple patterns

๏ Basic messaging pattern‣A producer publishes a

message with a specific subject‣All active consumers with

subscriptions matching the subject receive it

Publish-Subscribe 1-N

๏ It’s a publish-subscribe operation‣ Consumers subscribe using a shared

queue group name‣A publisher sends a message‣The messaging server forwards to

single subscriber ‣Non members of the queue group will

get message as standard pub-sub‣Multiple queue group names

subscribers on the same subject are possible

Queueing 1-1(Subscribers using a shared queue group name)

๏ Producer creates a subscription to an unique subject name (a.k.a. reply subject)

‣Sets max number of messages to receive

๏ The producer publishes a message with the reply subject

๏ Subscribers receive the message and publish a response to the reply subject

๏ Very efficient 1:1 of very large N

Request Reply 1-N

๏ Similar as before, but this time subscribers are part of a queue group name

‣Only one subscriber will get the request

Request Reply 1:1

๏ You can build massively scalable services, and achieve many features which would require a lot effort otherwise

‣Addressing‣Discovery‣Control plane‣Load balancing‣Fault-tolerance‣Location transparency

With these simple messaging patterns

๏ Use messaging for inter-service communication‣pub/sub, queuing, request/reply

๏ Broadcast heartbeats and health information๏ Use control plane services to listen to service heartbeats

‣Add, grow, shrink service queues based on health๏ Adapt data exchanged by services

‣Reduce integration points from 1 to N-1 to N

Microservices + messaging

Case Study: PokéNATSPresented by Alberto Ricart, Principal Engineer, NATS

Small study describing how to a create simple and highly scalable service with NATS messaging

Let’s put to work what we have learned...

•Design a small service oriented application•Could have millions of users?•Will release as a minimum viable product (many features tbd)•How would you develop it?

- If you made it with HTTP and REST services would it scale?-How would you manage it?-How would you scale it?-How would you cope with new features, changes and their deployment?

Take something seemingly simple like, Pokémon Go!•Hugely popular augmented reality phone

game that launched in July 2016 based on Pokémon

•Players walk around and: - Find Pokéstops near them- Collect Pokémon pets found in the wild- Level and evolve the pets to make them more

powerful- Battle their pets against other player’s

At its core

• It’s a massive sensor collector- Operates in a very large playground

‣Every few seconds new location information sent to one or more servers‣Every once in awhile, some game event happens

• One million players contributing sensor data every 5 seconds means:

‣12 million/min interactions just for the sensor information functionality

Being successful sometimes creates nightmares

•Imagine 130+ million downloads (Wikipedia number)- A little times a lot in cloud scale is huge- Any application is non-trivial at 1/1000 the success

‣Performance•Authentication•Data persistence

• Business logic‣Monitoring & Management

PokéNATS Architecture

pokenats.s_type.id.event.gridevent: update | data | spawn | new

pokenats_admin.cmd.s_type.idcmd: discover | kill | conf

pokenats_monitor.s_type.id.hb

pokenats_monitor.s_type.id.log.typetype: info | error | invalid

Scalability

•Queue group names allow load balancing of services•Filtering on the subject name enables services to divide work (perhaps with locality)

•Subscriptions from trainers filter updates and notifications from clients that are not geographically near

•Request reply services could delay responding based on memory/cpu presure

Service Discovery

•Control service uses pokenats_admin.cmd.s_type.sid.discover required sevices

•Missing services are spawned by the control service•Filtering enables limiting the impact of a request based on a subject name

Fault-tolerance

• If more than one service, it is fault tolerant‣Auto-heals when new services are added

• NATS can be configured in cluster mode-Clients randomly connect to servers in the cluster to distribute connections

- Clients switch to a different server if their current connection fails

•Control service reacts to current information by adding and pruning

Load-balancing

•Queue groups again, help here•HTTP/REST endpoints use a redirector or scaling strategy

Monitoring

•Log messages are sent under info/error monikers•Heartbeats tell if services are alive and quantify their health•Misbehaving clients (or attacks) are logged by re-publishing invalid requests

Management

•Control messages make services do something-Update a configuration setting-Exit-Show itself

Future Changes

• Loosely coupled makes it easier-Adding new services doesn’t affect the existing-Easy to hot test new revs

‣Start a new service alongside the old•If the new service is observed to work as desired, start more, stop the old

•If the new service misbehaves, send a control command to kill it

‣By using queue subscriptions only 1/N clients are affected‣Incremental deployments prevent embarrassing issues

•Integrating a new system?-If data needs adapting, add a service to do translation!

Take-away

• Message-driven micro-services are: - Better- Smaller- Highly scalable-More manageable-Able to cope with change and innovation

•More importantly, with careful patterns and design -Code is usually simpler-Robust - more resilient

@nats_iohttp://www.nats.io

Learn More at

Thank You!