Recommandé
Recommandé
Contenu connexe
Similaire à Forget about HTTP: Explore Async Messaging and RPC for Microservices
Similaire à Forget about HTTP: Explore Async Messaging and RPC for Microservices (20)
Dernier
Dernier (20)
Forget about HTTP: Explore Async Messaging and RPC for Microservices
- 1. Тема доклада Тема доклада Тема доклада KYIV 2019 Irina Scurtu Forget about HTTP .NET CONFERENCE #1 IN UKRAINE
- 2. Irina Scurtu ▪ Romania Based ▪ Software Architect @Endava ▪ Organizer of DotNetIasi user group ▪ I teach .Net @irina_scurtu
- 3. Agenda ▪ Monoliths& Microservices ▪ HTTP calls – sync & async ▪ RPC ▪ Messaging ▪ Queues ▪ Message Brokers ▪ Actor Model
- 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. Dou you know?
- 16. 150 Amazoncalls APIs to Build a Page
- 17. 5 billions /day Netflix ▪ services about 5 billions API calls/day ▪ 97.7 % are internal
- 18. Sync Calls HTTP
- 21. HTTP CALLS
- 23. “It’s perfectly fine to use sync HTTP Calls” ▪ Timeouts ▪ Availability ▪ Going back to coupling? ▪ You can loose requests ▪ Retries?
- 24. async Calls HTTP
- 25. “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
- 27. 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
- 29. gRPC
- 30. gRPC ▪ No-code references ▪ Contract based ▪ Uses HTTP/2 => faster ▪ Efficient ProtoBuf serialization => smaller payload ▪ Available in many languages ▪ Code generation
- 31. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 32. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 33. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 34. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 35. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 36. syntax = "proto3"; option csharp_namespace = "MyFirstGrpc"; package Fibonacci; // The service definition. service Fibo { rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){} } //the request message format message RequestedNumber { int32 number = 1; } //the response message format message FibonacciResult { int32 result = 1; }
- 38. RPC ▪ A kind of API call ▪Done through a message broker ▪ Ties systems together but preserves their encapsulations ▪Makes an external system look ‘local’ ▪No direct code dependencies
- 42. 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 ▪ Is still sync
- 44. 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
- 45. Messaging
- 51. Gains • Is a reaction to the problems of distributed systems • 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
- 52. Solutions to eventual problems ▪ Connection is scarce ▪ Batch process the message ▪ Use a semaphore to process them in batches
- 53. WHY USE a messaging system with MSA ?
- 54. Agility ▪Faster development ▪No integration process ▪You depend only on a response ▪Teams have ownership and full understanding of the codebase ▪You can switch technologies if needed
- 56. Increased Throughput 38 267 vs 3500
- 57. ElasticityScale down to reduce costs
- 58. A lot of ‘ilities’ ▪Reliability ▪Flexibility ▪Distribution ▪Increased Throughput ▪Scalability ▪Elasticity ▪Performance ▪Agility ▪Fault Tolerance
- 60. What options do I have? plenty Many more
- 61. Data Types Queues Actor Model Message Brokers
- 62. Queues ▪Useful for point to point communication ▪Messages are ordered and timestamped ▪Pull-mode
- 63. 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
- 64. Reactive Manifesto Message Driven ResilientElastic Responsive Async message Loose coupling Location transparency Scalable React to workload changes Failures are self contained Recovery Isolation
- 65. Message Brokers
- 66. Message Brokers ▪One process sends a message to a named queue/topic ▪One or many consumers ▪Handles connections and disconnections ▪Dead-letter queue concept ▪Message Guarantees ( 3 types) ▪Different Protocols
- 67. Guarantees
- 68. RabbitMQ
- 69. Message Brokers ▪Lightweight ▪Queues are FIFO ▪Supports AMQP protocol ▪Easy to use, fast ▪At-least-once delivery
- 70. AMQP 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 ▪ Has the “channel” concept
- 71. AMQP General Notes ▪ Has the “channel” concept
- 74. Topic Exchange
- 75. References
- 76. Distributed systems are all about tradeoffs
- 77. Http is not the only option!
- 79. Q&A