Microservices design patterns
•Transferir como PPTX, PDF•
8 gostaram•1,256 visualizações
The document discusses various microservices design patterns for a shipping logistics system. It describes patterns like circuit breaker, bulkhead, load leveling, throttling, ambassador, and event sourcing that are used to make the microservices resilient, scalable and reliable. It also discusses patterns like scheduler-agent-supervisor, compensating transactions, and strangler that help manage the workflow and recover from failures across multiple services.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Microservices design patterns
Semelhante a Microservices design patterns (20)
Mais de Masashi Narumoto
Último
Último (20)
Microservices design patterns
- 1. Design patterns for microservices Masashi Narumoto Principal Lead PM AzureCAT patterns & practices
- 2. Scheduler Package Drone Delivery Mobile app Query Delivery History RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service Microservices in Shipping BC AAD Auth Service 3rd party transportation Account Ingestion Delivery Analysis Archive Supervisor Drone events Load levelingGW- routing Throttling Circuit breaker Bulkhead Sidecar GW- offloading Event sourcing Ambassador Materialized View Scheduler-agent-Supervisor
- 4. Sidecar Pod Ingestion Monitoring Proxy Analytics Monitoring Proxy Pod HTTP/REST Shared file Other language neutral I/F
- 5. Ambassador Service A Service B Proxy Proxy • Retry • Circuit breaking • Authentication • Load balancing • Routing • Trace
- 6. Ambassador Delivery Envoy Scheduler Package Account Drone 3rd party Envoy Envoy Envoy Envoy • Trace • Retry • Circuit breaking • Authorization • Load balancing • Routing Envoy Ingestion Envoy
- 10. Gateway routing Package Drone Scheduler Delivery Fabrikam.com/api/deliveries User Ingestion Event HubAPI GW Delivery V2
- 11. Scheduler-agent-Supervisor PackageEvent Hub Drone Scheduler Delivery Supervisor Detect and restore failed operations Manage the workflow
- 12. Scheduler-agent-Supervisor PackageEvent Hub Drone Scheduler Delivery QueueO Step1 O Step2 X Step3 Supervisor How to recover from inconsistent state?
- 13. Compensating transactions PackageEvent Hub Drone Scheduler Delivery Package created for ID XYZ Drone was allocated for ID XYZ New request with ID XYZ Cancel partially succeeded operations D T C QueueID=XYZ O Step1 O Step2 X Step3 Supervisor
- 14. Event sourcing Delivery Drone events Update delivery status - Drone was scheduled - Package was picked up - On route - Completed Drone was scheduledPackage was picked upOn routeCompleted History?
- 15. Event sourcing Delivery Drone events - Drone was scheduled - Package was picked up - On route - Completed Drone was scheduled On route Completed Package was picked up Current status? Replay
- 16. Materialized view Function as a Service (Azure Functions) Azure Data lake Event Hub Event Hub Capture Full schema • Analytics • Audit • Reporting • Status inquiry History (Query) Delivery history service Http binding Delivery Status inquiry
- 17. Materialized view Function as a Service (Azure Functions) Azure Data lake History (Archive)Event Hub Event Hub Capture Full schema Subset Of schema • Analytics • Audit • Reporting • Status inquiry History (Query) CosmosDB Delivery history service Http binding Event Hub binding Cosmos DB binding Delivery Status inquiry Materialized View
- 20. Load leveling Azure Redis Scheduler CosmosDB Ingestion Package Delivery 100K rps 100K rps 100K rps 100K rps Delivery 100K 10K
- 21. 100K rps Load leveling Azure Redis SchedulerEvent Hub CosmosDB Ingestion Package Delivery 100K rps 10K rps 10K rps 10K rps IoT Hub React 10K rps
- 22. Throttling SchedulerEvent HubGateway Package Delivery100K rps 10K rps IoT Hub React 10K rps Ingestion
- 23. Anticorruption layer (ACL) Your context Other context Anti-corruption layer Adapter Translator facade Façade: Alternative interface to other context Adapter: Make requests to other context Translator: Translate the semantics Existing system Infrastructure Protocol Data model API signature Other semantics
- 25. User Interface Business Logic Data Access Database Client Strangler facade
- 26. Health endpoint monitoring Scheduler Kubernetes cluster management Package Drone Delivery Readiness probe
- 28. DeliveryScheduler Package Drone Delivery CosmosDB Redis Mobile app CosmosDB Delivery History DeliveryEvents RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service Storages in Shipping BC AAD Account Service Auth Service 3rd party transportation Account RequestHandler Delivery Analysis Supervisor Batch events into a single message to reduce #trx, #execution ADLS Drone events Failed ops
- 29. Eventual consistency Delivery Redis CosmosDB Delivery History DeliveryEvents ADLS GW User profile Order process Delivery status inquiry Order history inquiry CosmosDB Delivery XYZ accepted Delivery XYZ accepted >7 days completed completed
Notas do Editor
- So far we discussed benefits and challenges of MSA. Those benefits wouldn’t come for free. You need to design your app in a way that you get most out of it. Same as challenges, you can design your app to deal with them. Let’s talk about how we can design your application. You can copy&paste code or script but not design.
- How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment
- Augmenting core functions with sidecar, configuring NGINX etc.
- Ambassador = Forward proxy collocated with comsumer
- Envoy works with control plane to provide these features.
- ADLS is not designed for random read
- Connection pool to DB Thread pool
- 1 CPU= 1 Azure vCore These numbers should be based on perf/stress/soak testing Similarly you can configure resource quotas at namespace (Test vs Prod)
- If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
- If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
- If it’s constant load, there’s no choice other than provision the enough resources But if it’s peak load, we can buffer them and process them at your own pace.
- Semantics between two context are often different, especially with old system. New model would corrupt by dealing with lots of old models in ad hoc fashion. 3 logical components in implementing ACL. Façade is normally given as framework/platform
- Strangler is the stuff that covers the tree, so you don’t see what’s inside.
- The problem that this pattern solve is this. Users used to access this feature in the old app but now it’s moved in to the new app. We use it as analogy here. From outside the system, users don’t see what’s going on inside the system.
- How delivery service know its status? Is it coming from delivery mgmt service? (pull or push) Do we want to merge requestHandler and GW? GW does only token checking, delegate auth to auth service in account BC Why it has Package, Drone, Delivery as service but no service for account and 3rd party? Do we need them? Why doesn’t delivery service contain drone and package aggregate? Does drone need persistent storage or cache? What is the best API style? Depending on the responsibility and latency req of the drone service in this context, it can be just caching status Every event from drone come via EventHub to only DroneMgmt or + Delivery service? Scheduler does validation and return 501 (bad request) if it fails Account service subscribes delivery events and do the following once it’s completed Collect ratings, send emails, schedule payment