Reactive Microservices
5 likes464 views
The document discusses the evolution of software architecture, highlighting the shift from monolithic systems to microservices and the need for responsive, resilient, and elastic systems. It emphasizes the importance of isolation, autonomy, and single responsibility in microservices, while advocating for asynchronous communication and event-driven architecture for better scalability and resilience. The challenges of microservices, such as data management and maintaining consistency across services, are also addressed, alongside patterns like circuit breakers and the saga pattern for managing failures.
![A Recap – [Patterns Covered]
Aggregation
Chaining
Branching](https://image.slidesharecdn.com/techtalkreactivemicroservices-190208060714/85/Reactive-Microservices-7-320.jpg)
![Source: Reactive Microsystems [1] [Book]](https://image.slidesharecdn.com/techtalkreactivemicroservices-190208060714/85/Reactive-Microservices-17-320.jpg)
![Source: Reactive Microsystems [1] [Book]](https://image.slidesharecdn.com/techtalkreactivemicroservices-190208060714/85/Reactive-Microservices-18-320.jpg)
![Source: Reactive Microsystems [1] [Book]](https://image.slidesharecdn.com/techtalkreactivemicroservices-190208060714/85/Reactive-Microservices-19-320.jpg)
![Source: Reactive Microsystems [1] [Book]](https://image.slidesharecdn.com/techtalkreactivemicroservices-190208060714/85/Reactive-Microservices-20-320.jpg)
Reactive Microservices
- 5. Reference: Microservices: The resurgence of SOA principles and an alternative to the monolith (PWC) Monolithic / SOA / Microservices
- 14. State
- 17. Source: Reactive Microsystems [1] [Book]
- 18. Source: Reactive Microsystems [1] [Book]
- 19. Source: Reactive Microsystems [1] [Book]
- 20. Source: Reactive Microsystems [1] [Book]
- 22. Reactive?
- 23. Why Reactive Manifesto? The application requirements have changed dramatically over the years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloudbased clusters running thousands of multicore processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday’s software architectures
- 25. The Reactive Manifesto Responsive: Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. Resilient: The system stays responsive in the face of failure. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole.
- 26. The Reactive Manifesto Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. the ability to shard or replicate components and distribute inputs among them
- 27. The Reactive Manifesto Message Driven: Reactive Systems rely on asynchronous message passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.
- 28. SOA vs Microservices What makes Microservices interesting is that this architecture has learned from the failures and successes of SOA, kept the good ideas, and rearchitected them from the ground up using Reactive principles and modern infrastructure.
- 29. So.. What is a Microservice? In summary, we have characterized Microservices as a set of isolated services, each one with a single area of responsibility. This forms the basis for being able to treat each service as a single unit that lives and dies in isolation a prerequisite for resilience and can be moved around in isolation a prerequisite for elasticity.
- 31. Inter Service Communication Blocking I/O Non Blocking I/O
- 35. Distributed Database Management The Challenges: 1. Implementing business transactions that maintain consistency across multiple services. 2. How to implement queries that retrieve data from multiple services with multiple data sources (polygot persistence) The Solution? Event Driven Architecture (Event Logging/ Event Sourcing)
- 39. Back Pressure Source: Lightbend The backpressure may cascade all the way up to the user, at which point responsiveness may degrade, but this mechanism will ensure that the system is resilient under load, and will provide information that may allow the system itself to apply other resources to help distribute the load. (i.e elasticity).
- 40. Circuit Breaker Pattern A circuit breaker is used to provide stability and prevent cascading failures in distributed systems. These should be used in conjunction with timeouts at the interfaces between remote systems to prevent the failure of a single component from bringing down all components. Introducing circuit breakers on the web service call would cause the requests to begin to failfast, letting the user know that something is wrong and that they need not refresh their request.
- 41. Saga Pattern The distributed Saga Pattern is a pattern for managing failures, where each action has a compensating action for rollback
- 42. References Reactive Microservices Architecture: Design Principles for Distributed Systems, Jonas Bonér, Orielly Reactive Manifesto : https://www.reactivemanifesto.org/ The art of scalability (2nd edition), Martin L. Abbott and Michael T. Fisher Event driven data management for Microservices: https://www.nginx.com/blog/eventdrivendatamanagement microservices/ Event Sourcing with Kafka: https://dzone.com/articles/eventsourcingwithkafka