Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (8)
Similaire à Devit - forget about http requests
Similaire à Devit - forget about http requests (20)
Dernier
Dernier (20)
Devit - forget about http requests
- 1. Forget about HTTP Requests Irina Scurtu
- 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
- 12. 2 1 5 3
- 15. Do you know? ▪ Amazon calls 150 APIs to Build a Page ▪ Netflix services about 5 billions API calls/day ▪ 99.7% are internal
- 16. HTTP API CALLS
- 18. HTTP CALLS S H
- 19. HTTP CALLS
- 20. “It’s perfectly fine to use sync HTTP Calls” ▪ Timeouts ▪ Availability ▪ Going back to coupling? ▪ You can loose requests ▪ Retries?
- 21. “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
- 23. HTTP General Notes ▪ Sync by nature ▪ Make a TCP connection for each request ▪ No retry out of the box ▪ No delivery guarantees ▪ Location transparency ▪ Good for public facing APIs ▪ Familiar ▪ Easy to debug
- 24. Challenges ▪Service Discovery ▪Retry policies ▪Circuit breakers ▪Timeouts ▪Routing ▪Tracing
- 25. RPC
- 26. RPC ▪ A kind of API call ▪Done through a message broker ▪ Ties systems together but preserves their encapsulations
- 31. 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
- 33. Messaging ▪Gives you loosely coupled integration ▪Doesn’t require both systems to be up ▪Messages ca be transformed in transit - Enrichers ▪Messaging systems trade consistency for availability ▪You don’t lose messages ▪Involves a Producer and a consumer
- 34. Messaging
- 40. 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
- 41. Gain vs Loss ▪ Connection is scarce ▪ Batch process the message ▪ Use a semaphore to process them in batches
- 42. WHY USE a messaging system with MSA ?
- 43. Agility ▪Faster development ▪No integration process ▪Teams have ownership and full understanding of the codebase ▪You can switch technologies if needed
- 45. Increased Throughput 38 267 vs 3500
- 46. ElasticityScale down to reduce costs
- 47. A lot of ‘ilities’ ▪Reliability ▪Flexibility ▪Distribution ▪Increased Throughput ▪Scalability ▪Elasticity ▪Performance ▪Agility ▪Fault Tolerance
- 49. Data Types Queues Actor Model Message Brokers
- 50. What options do I have? plenty Many more
- 51. Queues ▪Useful for point to point communication ▪Messages are ordered and timestamped ▪Pull-mode
- 52. Actor model ▪Born from Reactive Programming ▪Actors are processes that encapsulate behavior ▪Actors are more than message consumers ▪Can delegate and create new actors ▪Can supervise children ▪At most once delivery
- 53. Reactive Manifesto Message Driven ResilientElastic Responsive Async message Loose coupling Location transparency Scalable React to workload changes Failures are self contained Recovery Isolation
- 54. Message Brokers
- 55. Message Brokers ▪One process sends a message to a named queue or topic ▪One or many consumers ▪Handles connections and disconnections very well ▪Dead-letter queue concept ▪Message Guarantees ( 3 types)
- 56. Message Brokers ▪Lightweight ▪Queues are FIFO ▪Supports AMPQ protocol ▪Easy to use, fast ▪At-least-once delivery
- 57. 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”
- 60. Topic Exchange
- 61. References
- 63. Messages are great show them some
- 65. Q&A