Service communication made easy

Using NATS to facilicate communication between services in a SOA.

Transcript

1. Service communication made easy
2. About me Brian de Heus - Lead Engineer @ Adgorithmics Twitter: @briandotjp Website: brian.jp
3. Microservices are cool (but nothing new)
4. What are microservices? • A service that handles a small part of a problem domain • Everything else (including the above) is still debated
5. Who does microservices • We’ve all heard of it • Most of us have thought about it • Very few are practicing it • Less than 10% of last Kubernetes JP meet-up
6. Netflix
7. Twitter and Amazon
8. Uber Hailo Ebay Groupon
9. Netflixs’ Microservice Shopping List • Eureka (service discovery) • Archaius (service configuration) • Ribbon (IPC) • Hystrix (Provides fault tolerance) • Karyon (JVM service provider) • Governator (JVM service provider) • Ribbon (service provider) • Zuul (Edge proxy) • Fenzo (Scheduler)
10. You are (probably) not one of these companies
11. Our experience with microservices • Increased our developer velocity • Decreased our deployment time • Added some management overhead • Allows us to say “Yeah we do microservices” • Was difficult to get started with
12. Let’s keep it simple
13. We now have services running. How do they know how to find each other?
14. Good ‘ol Service Discovery Model Service A Some Queue Name: service_a IP: 10.0.0.1 Port: 8001 Service B Service C Service D
15. Service A THE MESSAGE Service B Service C A SECOND MESSAGE
16. Pros • Least amount of communication over network ◦ Only communicate when services goes up or down • Tried and true
17. Cons • Relies heavily on client-side implementation ◦ Each service will need to implement a registry ◦ Each service will need to perform round-robin • If service crashes unexpectedly registry is out of sync ◦ Can mitigate by pinging a health end-point every N seconds ◦ Which increases network traffic
18. PubSub Model Service A Queue Service B Service C Service D
19. Pros • Automatic round robin • Won’t reach crashed services • Little client-side implementation • Service discovery not (really) necessary
20. Cons • Single Point of Failure (but we’ll get back to that) • More network traffic
21. Don’t hate -- Facilitate
22. NATS • Messaging system written in Go • Developed by Apcera, maintained by Synadia • PUBSUB on crack • At-most-once delivery guarantee • Simple text protocol • NATS can easily handle 10,000k messages a second on single core machine • Persistent messaging through NATS Streaming
23. NATS Protocol in a nutshell subject PUB reply-to # bytes payload subject SUB group sub id
24. Talking using JSONRPC Service A Some Queue NATS Topic: Service Name (e.g “analytics”) JSONRPC method: campaigns/all params: {“userId”: 1234} id: “aaaa-bbbb-cccc-dddd” Service B Service C Service D
25. Talking to the services from outside Gateway (just another microservice) Service NATS https://hostname/api/:namespace/:method JSONRPC method: service_name/:method params: {“userId”: 1234} id: “aaaa-bbbb-cccc-dddd”
26. In reality Gateway (just another microservice) Service Consul KV store • Path mapping (e.g api/campaign/12345/ads => campaign/get) • Service Health Checks • Schema checking • Automatic Authentication and API tooling NATS
27. Last points • Don’t know how long this will work. But real-world simulations are promising • What works for us may not work for you. • Always try to keep it simple.