Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NATS for Modern Messaging and Microservices

2,183 views

Published on

There is a renaissance underway in the messaging space. Due to the demands of IoT networks, cloud native apps, and microservices developers are looking for simple, fast, messaging systems. This is a sharp contrast to how traditional messaging was done.

This webinar will cover:
- The basics of messaging patterns
- What makes NATS unique
- Using a demo inspired by Pokemon Go as an example

Published in: Technology

NATS for Modern Messaging and Microservices

  1. 1. NATS for Modern Messaging and Microservices Presented by Alberto Ricart, Principal Engineer, NATS
  2. 2. •Community and Ecosystem Manager, NATS.io • Ways to get involved in NATS Community: - http://nats.io/community/ Brian Flannery @brianflannery brian.flannery@apcera.com
  3. 3. •Principal Engineer at Apcera •Previously with - TIBCO > 15 years - Informatica •Building messaging based systems > 20 years Alberto Ricart @alberto.ricart alberto.ricart@apcera.com
  4. 4. - 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
  5. 5. Part 1: Messaging Basics
  6. 6. ๏ 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
  7. 7. ๏Have a subject that describes the message contents ๏A payload {location: {lat: 45.678, lng: 123.456}} Messages
  8. 8. ๏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?
  9. 9. ๏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
  10. 10. ๏ 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
  11. 11. ๏ Subscribers can specify wildcards pokenats.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
  12. 12. ๏ 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/
  13. 13. ๏ 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.)
  14. 14. ๏ 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
  15. 15. Part 2: Messaging Patterns
  16. 16. - Publish-Subscribe - Queueing - Request-Reply Three simple patterns
  17. 17. ๏ 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
  18. 18. ๏ 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)
  19. 19. ๏ 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
  20. 20. ๏ 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
  21. 21. ๏ 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
  22. 22. ๏ 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
  23. 23. Case Study: PokéNATS Presented by Alberto Ricart, Principal Engineer, NATS Small study describing how to a create simple and highly scalable service with NATS messaging
  24. 24. 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?
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. PokéNATS Architecture pokenats.s_type.id.event.grid event: update | data | spawn | new pokenats_admin.cmd.s_type.id cmd: discover | kill | conf pokenats_monitor.s_type.id.hb pokenats_monitor.s_type.id.log.type type: info | error | invalid
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. Load-balancing •Queue groups again, help here •HTTP/REST endpoints use a redirector or scaling strategy
  33. 33. 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
  34. 34. Management •Control messages make services do something - Update a configuration setting - Exit - Show itself
  35. 35. 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!
  36. 36. 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
  37. 37. @nats_io http://www.nats.io Learn More at Thank You!

×