NATS for Modern Messaging and Microservices
-
Upload
apcera -
Category
Technology
-
view
1.135 -
download
8
Transcript of NATS for Modern Messaging and Microservices
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
•Principal Engineer at Apcera•Previously with
-TIBCO > 15 years-Informatica
•Building messaging based systems > 20 years
Alberto Ricart
- 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!