Download to read offline
![[OSC2016] マイクロサービスを支える MQ を考える](https://cdn.slidesharecdn.com/ss_thumbnails/event-161105054759-thumbnail.jpg?width=640&height=640&fit=bounds)
Devit - forget about http requests
- 1. Forget about HTTPRequests Irina Scurtu
- 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.
- 12.
- 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.
- 17.
- 18.
- 19.
- 20. “It’s perfectly fine touse sync HTTP Calls” ▪ Timeouts ▪ Availability ▪ Going back to coupling? ▪ You can loose requests ▪ Retries?
- 21. “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
- 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 ▪Circuitbreakers ▪Timeouts ▪Routing ▪Tracing
- 25.
- 26. RPC ▪ A kindof API call ▪Done through a message broker ▪ Ties systems together but preserves their encapsulations
- 27.
- 28.
- 31. Gain vs Loss ▪Youdon’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
- 32.
- 33. Messaging ▪Gives you looselycoupled 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.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. 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
- 41. Gain vs Loss ▪Connection is scarce ▪ Batch process the message ▪ Use a semaphore to process them in batches
- 42. WHY USE amessaging system with MSA ?
- 43. Agility ▪Faster development ▪No integrationprocess ▪Teams have ownership and full understanding of the codebase ▪You can switch technologies if needed
- 44.
- 45. Increased Throughput 38 267vs 3500
- 46.
- 47. A lot of‘ilities’ ▪Reliability ▪Flexibility ▪Distribution ▪Increased Throughput ▪Scalability ▪Elasticity ▪Performance ▪Agility ▪Fault Tolerance
- 48.
- 49.
- 50. What options doI have? plenty Many more
- 51. Queues ▪Useful for pointto point communication ▪Messages are ordered and timestamped ▪Pull-mode
- 52. Actor model ▪Born fromReactive 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 Asyncmessage Loose coupling Location transparency Scalable React to workload changes Failures are self contained Recovery Isolation
- 54.
- 55. Message Brokers ▪One processsends 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 areFIFO ▪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.
- 61.
- 62.
- 63. Messages are great showthem some
- 64.
- 65.