Downloaded 84 times
Uploaded byMasashi Narumoto
Microservices design patterns
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.
More Related Content
Similar to Microservices design patterns
Microservices design patterns
- 1. Design patterns formicroservices 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 ShippingBC 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
- 3.
- 4.
- 5. Ambassador Service A ServiceB 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
- 7.
- 8.
- 9.
- 10.
- 11. Scheduler-agent-Supervisor PackageEvent Hub Drone Scheduler Delivery Supervisor Detect andrestore failed operations Manage the workflow
- 12. Scheduler-agent-Supervisor PackageEvent Hub Drone Scheduler Delivery QueueO Step1 OStep2 X Step3 Supervisor How to recover from inconsistent state?
- 13. Compensating transactions PackageEvent Hub Drone Scheduler Delivery Packagecreated 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 deliverystatus - 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 asa 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 asa 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
- 18.
- 19.
- 20. Load leveling Azure Redis Scheduler CosmosDB Ingestion Package Delivery 100Krps 100K rps 100K rps 100K rps Delivery 100K 10K
- 21. 100K rps Load leveling AzureRedis 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 10Krps IoT Hub React 10K rps Ingestion
- 23. Anticorruption layer (ACL) Yourcontext 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
- 24.
- 25. User Interface Business Logic DataAccess Database Client Strangler facade
- 26. Health endpoint monitoring Scheduler Kubernetescluster 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 inShipping 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 GWUser profile Order process Delivery status inquiry Order history inquiry CosmosDB Delivery XYZ accepted Delivery XYZ accepted >7 days completed completed
Editor's Notes
- #2 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.
- #3 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
- #5 Augmenting core functions with sidecar, configuring NGINX etc.
- #6 Ambassador = Forward proxy collocated with comsumer
- #7 Envoy works with control plane to provide these features.
- #17 ADLS is not designed for random read
- #19 Connection pool to DB Thread pool
- #20 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)
- #21 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.
- #22 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.
- #23 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.
- #24 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
- #25 Strangler is the stuff that covers the tree, so you don’t see what’s inside.
- #26 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.
- #30 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