Microservices patterns
0 likes102 views
This document discusses various patterns for microservices architectures. It begins by defining microservices and their key characteristics. It then covers patterns for decomposing a monolithic system into microservices by domain. Communication patterns like synchronous, asynchronous and circuit breaker are presented. Other patterns discussed include strangler, database per service, orchestrator, choreography, saga and various approaches to service discovery. Overall the document provides an overview of best practices and patterns for designing, developing and deploying microservices applications.
Microservices patterns
- 1. Patterns in Microservices - Vikram Kuruguntla https://www.linkedin.com/in/vikramkuruguntla
- 2. Patterns In MicroServices ● Patterns in Identifying the micro services ● Communication Patterns ● Integration Patterns ● Deployment Patterns ● Caching Patterns ● Testing Patterns ● Observability Patterns ● Service Discovery Patterns ● UI patterns
- 3. What defines Microservices ? ● Particular style of architecture ● Organized around business domains ● Independently ○ Deployable ○ Scalable ○ Testable ○ Manageable ○ ................. ● Decentralized ○ Different teams works on different parts of the system ○ Polyglot technical environment ● Smart endpoints and dumb pipes
- 6. Monolithic System - Ecommerce System Ecommerce Backend Server Ecommerce User Interface
- 7. Monolithic System - Ecommerce System Ecommerce Backend Server Ecommerce User Interface Ecommerce Backend Server Ecommerce Backend Server API Gateway / Router / Load Balancer Router / Load Balancer
- 9. Pattern: Decompose By Domain ● Context ○ You are building large and complex system using microservices architecture ● Problem ○ How to breakdown the services? ● Solution ○ Understand the business domain and Identify the domains and their boundaries ○ Break down the system into multiple business domains mapping to each service ○ Keep the communication between services as like business domains ● Objective ○ The architecture of the system to evolve with the business changes or new business opportunities ● Issues ○ Lack of knowledge on domain and organization structure makes the process difficult
- 10. Pattern: Decompose By Domain Catalogue Service Recommen dation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 12. Pattern : Strangler ● Context ○ You are rewriting or redesigning a old complex system ● Problem ○ How to make the transition from legacy to new system smooth? ● Solution ○ Incrementally build the new services and integrate with the legacy system until the legacy system is completely replaced ○ Run the old and new functionality in parallel to make sure new system is not breaking the functionality ● Issues ○ Considerable effort is required for the legacy and new system integrations. ○ Considerable effort is required for the parallel run of the same functionality
- 13. Pattern: Strangler Monolithic System Monolithic System ● Extract micro services step by step until the entire monolithic is dead ● Extract the often changing, reusable, beneficial services first
- 14. Strangler Pattern Monolithic API layer Monolithic System Monolithic System ● Run both monolithic and new services in parallel ● Add automations to make sure the new system functionality is same as older one.
- 16. ● Context ○ You are building a new microservices application which deals with the data ● Problem ○ How to model the database architecture in microservices? ● Solution ○ Keep the separate database per each service ○ Change of database design or schema should not impact any other services except the service which managing the database ● Avoid ○ Sharing of database between multiple services. It impacts the primary goal of micro services which is isolation. Pattern : Database Per Service
- 17. Pattern : Database per Service Cart Service Catalogue Service Checkout Service Shared Database ● Schema change can impact all three services. ● Breaks the isolation principle of microservices. ● All the load shifts to database layer. ● Single point of failure Cart Service Catalogue Service Checkout Service Database Per Service
- 18. Patterns Applied Decompose By Functionality Database Per Service Strangler
- 19. Patterns Applied Checkout Service Dispatch Service Inventory Service Payment Service Order Service Ecommerce Backend Server Ecommerce User Interface Ecommerc e Backend Server Ecommerce Backend Server API Gateway / Router / Load Balancer Router / Load Balancer
- 21. Synchronous Communication Inventory Service Order Service Dispatch Service Inventory Service Order Service Dispatch Service Inventory Service Order Service Dispatch Service 1. All requests are successful. 2.1 Dispatch service is out temporarily 2.1 All requests fail in the request chain
- 23. Asynchronous Communication Inventory Service Order Service Dispatch Service Inventory Service Order Service Dispatch Service Inventory Service Order Service Dispatch Service 1. All requests are successful. 2.1 Dispatch service is out temporarily 2.2 Shipping, Inventory keep adding messages to queue 3.0 Dispatch service is online. It will catch up sometime soon
- 24. Circuit Breaker Pattern A B A B Circuit Open Circuit Closed
- 25. Pattern : Circuit Breaker ( Context and Problem ) ● Due to some issue Dispatch Service is processing the requests slowly ● Will this issue impact any other part of the system? Catalogue Service Recommend ation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 26. Pattern : Circuit Breaker ( Context and Problem ) ● In synchronous communication, Inventory Service threads waits(until timeout) for the response from Dispatch Service ● Inventory Service will become unresponsive after some time Catalogue Service Recommend ation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 27. Pattern : Circuit Breaker ( Context and Problem ) ● Catalogue Service and Order Service becomes unresponsive due to Inventory Service Catalogue Service Recommend ation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 28. Pattern : Circuit Breaker ( Context and Problem ) ● Recommendation Service, Cart Service becomes unresponsive due to Catalogue Service ● Checkout service becomes unresponsive due to Order Service and Cart Service Catalogue Service Recommend ation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 29. Pattern : Circuit Breaker Inventory Service Dispatch Service Inventory Service Dispatch Service Inventory Service Dispatch Service Time Out Circuit Closed Circuit Opened Drop Requests Response Ok Circuit Closed ● Circuit closed. Inventory service makes requests to Dispatch Service. Dispatch Service is unresponsive ● Circuit breaker at Inventory Service detects the issue and open the circuit. ● Inventory Service fails the requests which are dependent on Dispatch Service. ● Periodically Circuit Breaker at Inventory Service close the circuit to identify the state of Dispatch Service. ● If the requests are failed, it will again open the circuit. ● If the requests are successful, it will close the circuit
- 30. Pattern : Circuit Breaker ● Overall impact on system is reduced ● The only flow paths which are dependent on Dispatch Service are unavailable ● Checkout, Order, Shipping and Inventory services can serve other requests Catalogue Service Recommend ation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 31. Sidecar Pattern
- 32. Pattern : Sidecar Pattern ( Problem ) Order Service 1 2 3 Inventory Service 1 2 3 Checkout Service 1 2 3 ● Each service needs common things like ○ Log collection ○ Metric collection ○ Auto configuration ● Different services can be in different languages ● For each common task, need to maintain different libraries based on the language ● These unrelated tasks are overhead for the service
- 33. Pattern : Sidecar Pattern Inventory ServiceCheckout Service Order Service ● Sidecar is another container sits along with the main service ● Sidecar extend the functionality of main service ● The incoming requests reach main service via sidecar. Due to this advantage, it can handle all the common functionalities needed by majority of the services. ● Most times, main service does not even know the existence of sidecar ● Main service container and sidecar container grouped under POD. They always deployed together in same machine.
- 34. Pattern : Sidecar Pattern Load Balancer ............. ● Multiple instance of same service deployed along with sidecar container Inventory Service Inventory Service Inventory Service
- 35. Pattern : Sidecar Pattern ● The Sidecar can also exists without interacting with main service ● Sidecar and main service shares the same file system, network.... Etc. ● Sidecar can takes care of the activities like log collection, configuration updates, ... etc to reduce the responsibility of main service Load Balancer ............. Inventory Service Inventory Service Inventory Service
- 37. Pattern : Ambassador Pattern Load Balancer Order Service Inventory Service Circuit Breaker ● Ambassador container brokers interactions with the main service with the rest of the world ● Unlike in Sidecar, Order service is aware of the existence of Ambassador container
- 39. Pattern : Orchestrator Inventory Service Order Service Dispatch Service Orchestrator ● Orchestrator takes care of the communication between services ● Orchestrator is a centralized approach ● In this case, the communication between services is synchronous
- 40. Pattern : Orchestrator Dispatch Service Inventory Order Service ● Orchestrator takes care of the communication between services ● In this case, the communication between services is asynchronous Orchestrator
- 41. Pattern : Orchestrator Orchestrator Dispatch Service Inventory Service Order Service ● Orchestrator can become more knowledgeable and becomes heavier than services ● This situation is opposite to the "Smart Endpoints and Dumb Pipes" principle of microservices
- 44. Saga Pattern
- 45. Pattern : Saga Pattern Itenary Service Cab Service Hotel Service Flight Service Book My Trip Book a Cab Book a Hotel Book a flight ● How to handle distributed transactions? ● Successful itenary booking depends on the success of cab, hotel and flight bookings.
- 46. ● Cab booking is successful ● Hotel booking is successful ● Flight booking failed ● As one of booking failed itenary booking is also failed. ● What about cab and hotel successful bookings? Pattern : Saga Pattern Itenary Service Cab Service Hotel Service Flight Service Book My Trip Book a Cab Book a Hotel Book a flight
- 47. Pattern : Saga Pattern Itenary Service Cab Service Hotel Service Flight Service Book My Trip Book a Cab Cancel cab Book a Hotel Cancel Hotel Book a flight Book a Cab Cancel a Cab ● Rollback cab and hotel booking before itenery booking gets failed. ● There is no true rollback of cab and hotel bookings ● Call another REST API to cancel the the cab and hotel booking
- 49. Service Discovery Order Service 100.1.1.1 100.1.1.2 100.1.1.3 ? Order Service Order Service Inventory Service 200.1.1.1 200.1.1.2 200.1.1.3 Inventory Service Inventory Service ● Multiple instances of Order Service ● Multiple instances of Inventory Service ● How Order service discovers the inventory service?
- 50. Service Registry
- 51. Service Registry: Self register Service Registry order-service.test.com inventory-service.test.com Register and Unregister based on instance status Register and Unregister based on instance status Order Service 100.1.1.1 100.1.1.2 100.1.1.3 Order Service Order Service Inventory Service 200.1.1.1 200.1.1.2 200.1.1.3 Inventory Service Inventory Service ● Application is tightly coupled with the service registry ● You must implement the registration code in each programming language and framework used by your services ● Instances should send heart beats to service registry to prevent it's registration from expiry
- 52. Service Registry: Third Party Register Service Registry order-service.test.com inventory-service.test.com Order Service 100.1.1.1 100.1.1.2 100.1.1.3 Order Service Order Service Inventory Service 200.1.1.1 200.1.1.2 200.1.1.3 Inventory Service Inventory Service Server Manager Register and unregister on behalf of all services
- 54. Service Registry: Client Side Discovery ● Service Registry keeps track of all the services and their instances ● Order service takes the responsibility of identifying the instances of Inventory service and interact with them ● Load balancing, routing, ... etc are responsibility of the client Service Registry Order Service 100.1.1.1 100.1.1.2 100.1.1.3 Order Service Order Service Inventory Service 200.1.1.1 200.1.1.2 200.1.1.3 Inventory Service Inventory Service
- 56. Service Registry: Server Side Discovery Service Registry Order Service 100.1.1.1 100.1.1.2 100.1.1.3 Order Service Order Service Inventory Service 200.1.1.1 200.1.1.2 200.1.1.3 Inventory Service Inventory Service Router / Load Balancer Router / Load Balancer ● Service Registry keeps track of all the services and their instances ● Service discovery is delegated to another servers like Router or Load Balancers
- 58. Pattern: Micro Frontends How to develop the UI? Catalogue Service Recommen dation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 59. Pattern: Micro Frontends User Interface Catalogue Service Recommen dation Service Cart Service Checkout Service Order Service Dispatch Service Inventory Service Customer Service Payment Service
- 60. Summary ● Monolithic Service ● Decompose services by domain ● Strangler Pattern ● Database per service ● Communication Mechanisms ● Circuit Breaker ● Orchestrator ● Choreography ● SAGA ● Service Discovery
- 61. Thank You