Download as PDF, PPTX
More Related Content
Similar to Rigadevdays - Communication in a microservice architecture
Rigadevdays - Communication in a microservice architecture
- 1. Communication in amicroservice architecture
- 2. Irina Scurtu • RomaniaBased • 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.
- 5. MONOLITH ▪ Self-contained ▪ Singlecodebase ▪ Single deploy unit ▪ Easy life for developers ▪ Dependencies are in your code ▪ Single technology stack
- 6. MONOLITH ▪ All ornothing deploys ▪ Downtimes ▪ Long build times ▪ ~ 0 continuous delivery ▪ Hard to test
- 7.
- 8.
- 9. MICROSERVICE? ▪ it’s thatthing 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
- 12.
- 13. Now we have ▪Loosely coupled components ▪ Small codebases ▪ Easy to deploy and scale ▪ Reusable components ▪ Multiple databases
- 14.
- 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.
- 19.
- 20.
- 21.
- 22. “It’s perfectly fine touse sync HTTP Calls” •Timeouts •Availability •Going back to coupling? •You can loose requests •Need to have a retry mechanism
- 23. “It’s perfectly fineto 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 ▪Circuitbreakers ▪Timeouts ▪Routing ▪Tracing
- 27.
- 28. RPC ▪A kind ofAPI call ▪Done through a message broker ▪Ties systems together but preserves their encapsulations
- 29.
- 30.
- 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.
- 35. Messaging ▪Gives you looselycoupled 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.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42. Gains • Is areaction 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 AMESSAGE BROKER with MSA ?
- 45. Agility ❑Faster development ❑No integrationprocess ❑Teams have ownership and full understanding of the codebase ❑You can switch technologies if needed
- 46. Resiliency ❑You don’t havea single point of failure
- 47.
- 48.
- 49. Increased Throughput 38 267vs 3500
- 50.
- 51. A lot of‘ilities’ ❑Reliability ❑Flexibility ❑Distribution ❑Increased Throughput ❑Scalability ❑Elasticity ❑Performance ❑Agility
- 52.
- 53.
- 54. What options doI have? plenty Many more
- 55. Queues • Useful forpoint to point communication • Messages are ordered and timestamped • Pull-mode
- 56. Actor model ▪Actors areprocesses 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 processsends 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 areFIFO ▪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.
- 63.
- 64.
- 65. Messages are great showthem some
- 66.
- 67.