Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Similar to Rigadevdays - Communication in a microservice architecture
Similar to Rigadevdays - Communication in a microservice architecture (20)
Recently uploaded
Recently uploaded (20)
Rigadevdays - Communication in a microservice architecture
- 1. Communication in a microservice architecture
- 2. Irina Scurtu • Romania Based • Software Architect @Endava • Organizer of DotNet Iasi user group • I teach .Net @irina_scurtu
- 3. Agenda ▪ Monoliths& Microservices ▪ HTTP calls – sync & async ▪ RPC ▪ Messaging ▪ Queues ▪ Message Brokers ▪ Actor Model
- 4. MONOLITH
- 5. MONOLITH ▪ Self-contained ▪ Single codebase ▪ Single deploy unit ▪ Easy life for developers ▪ Dependencies are in your code ▪ Single technology stack
- 6. MONOLITH ▪ All or nothing deploys ▪ Downtimes ▪ Long build times ▪ ~ 0 continuous delivery ▪ Hard to test
- 9. MICROSERVICE? ▪ it’s that thing that is not a monolith ▪ With it’s own database ▪ Easy to deploy ▪ Standalone ▪ Easy to maintain Is it?
- 10. MICROSERVICES? ▪ Introduces complexity ▪ Cascading effects in case of failure ▪ Need to monitor them closely
- 11. Principles of microservices ▪ Modeled around business concepts ▪ Culture of automation ▪ Independently deployable ▪ Isolate failure
- 13. Now we have ▪ Loosely coupled components ▪ Small codebases ▪ Easy to deploy and scale ▪ Reusable components ▪ Multiple databases
- 14. 2 1 5 3
- 17. Do you know? ▪ Amazon calls 150 APIs to Build a Page ▪ Netflix services about 5 billions API calls/day ▪ 99.7% are internal
- 18. HTTP API CALLS
- 20. HTTP CALLS S H
- 21. HTTP CALLS
- 22. “It’s perfectly fine to use sync HTTP Calls” •Timeouts •Availability •Going back to coupling? •You can loose requests •Need to have a retry mechanism
- 23. “It’s perfectly fine to use async HTTP Calls” ▪ You’ll have exactly the same issues as with sync calls ▪ Distribute load?! ▪ You can serve more request ▪ You can serve the requests faster
- 25. HTTP General Notes ▪ Sync by nature ▪ Make a TCP connection for each request ▪ No retry out of the box ▪ No delivery guarantees ▪ No routing without a Service Discovery or configuration ▪ Good for public facing APIs ▪ Familiar ▪ Easy to debug
- 26. Challenges ▪Service Discovery ▪Retry policies ▪Circuit breakers ▪Timeouts ▪Routing ▪Tracing
- 27. RPC
- 28. RPC ▪A kind of API call ▪Done through a message broker ▪Ties systems together but preserves their encapsulations
- 33. Gain vs Loss • You don’t lose the requests • You can add more handler instances • You can ‘apparently’ spread the load • You can process more requests ▪ Need to match the request to the response ▪ You wait for a response => sync
- 34. Messaging
- 35. Messaging ▪Gives you loosely coupled integration ▪Doesn’t require both systems to be up ▪Messages ca be transformed in transit ▪Messaging systems trade consistency for availability ▪You don’t loose messages
- 36. Messaging
- 42. Gains • Is a reaction to the problems of distributed sys • Process more requests • Process request faster • Don’t lose requests ▪ You move the potential issues to another subsystem (DB in our case) ▪ Eventual consistency remains a problem Loss
- 43. Gain vs Loss ▪ Connection is scarce ▪ Batch process the message ▪ Use a semaphore to process them in batches
- 44. WHY USE A MESSAGE BROKER with MSA ?
- 45. Agility ❑Faster development ❑No integration process ❑Teams have ownership and full understanding of the codebase ❑You can switch technologies if needed
- 46. Resiliency ❑You don’t have a single point of failure
- 48. Performance
- 49. Increased Throughput 38 267 vs 3500
- 50. ElasticityScale down to reduce costs
- 51. A lot of ‘ilities’ ❑Reliability ❑Flexibility ❑Distribution ❑Increased Throughput ❑Scalability ❑Elasticity ❑Performance ❑Agility
- 53. Data Types Queues Actor Model Message Brokers
- 54. What options do I have? plenty Many more
- 55. Queues • Useful for point to point communication • Messages are ordered and timestamped • Pull-mode
- 56. Actor model ▪Actors are processes that encapsulate behaviour ▪Actors are more than message consumers ▪Can delegate and create new actors ▪Can supervise children ▪At most once delivery
- 57. Message Brokers ▪One process sends a message to a named queue or topic ▪One or many consumers ▪Handles connections and disconnections very well ▪One-way data flow or request/response model –”ReplyTo” ▪Dead-letter queue concept
- 58. Message Brokers ▪Lightweight ▪Queues are FIFO ▪Supports AMPQ protocol ▪Easy to use, fast ▪At-least-once delivery
- 59. AMPQ General Notes ▪ Async by nature ▪ Guaranteed message delivery ▪ At-least once, exactly once, at most once delivery ▪ No DNS resolve ▪ Programmatic routing ▪ Retries out-of-the box ▪ Ack, Nack out of the box ▪ Concept of “channel”
- 62. Topic Exchange
- 63. References
- 64. In Summary
- 65. Messages are great show them some
- 67. Q&A