Reactive systems zJava VIII
•Download as PPTX, PDF•
1 like•102 views
The document discusses reactive systems and provides an overview of key concepts from the Reactive Manifesto. It defines the main principles of reactive systems as being responsive, resilient, and elastic. It explains the benefits of reactive systems for businesses and technical perspectives. The document also discusses differences between reactive systems and reactive programming, advantages of asynchronous communication over synchronous, and some of the main concerns in designing reactive systems like consistency and isolation.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Reactive systems zJava VIII
Similar to Reactive systems zJava VIII (20)
Recently uploaded
Recently uploaded (20)
Reactive systems zJava VIII
- 1. Digital Transformation Specialist Reactive Systems - introduction Wojciech Nowak zJava VIII - 16.04.2019
- 2. “ © 2019 Objectivity Ltd Classification Agenda 1. The Reactive Manifesto 2. Why we need Reactive Systems 3. Reactive Systems vs Reactive Programming 4. Sync vs async communication 5. Benefits of Reactive Systems 6. Main challenges
- 3. © 2019 Objectivity Ltd What does the Reactive System term mean?
- 4. © 2019 Objectivity Ltd Classification The Reactive Manifesto Source: https://www.reactivemanifesto.org/
- 5. © 2019 Objectivity Ltd Classification Responsiveness • A cornerstone of modern system’s usability • The consistent quality of service • System responds in a timely fashion • An experience that the system is responsive at all time, under any condition • Some components of the system can operate in degraded state but they still work • System’s optional features can be down but this should not impact the system as a whole • Builds user’s positive experience, confidence level and encourages for further interactions
- 6. © 2019 Objectivity Ltd Classification Resilience • System stays responsive even in case of failure • We don’t try to avoid or secure against failures, we are just prepared to handle them accordingly • Recovery is delegated to separate component (supervisor) • Failing service can be restarted so it needs to start up really quick • Can be achieved by: • Replication (data, services) – workload distribution (load balancing), redundant processing or mix • Isolation and containment (bulkheading) – failures are not propagated to a client, failure in one service shouldn’t cause failure in another service • Delegation
- 7. © 2019 Objectivity Ltd Classification Elasticity • The system remains responsive under any load (especially peak loads) • Able to react and accommodate to the current load (scale up and down) • Provides cost-effective way of system operation • No contention • No bottleneck
- 8. © 2019 Objectivity Ltd Classification Message driven • Provides an async and non-blocking communication • Communication by message passing • Elasticity • A target participant doesn’t necessarily need to be up & running at a given time for communication to succeed • Provides traits like: • A greater level of loose coupling between components (services) • Facilitates isolation and containment • Easies the implementation of the supervision • Enables the location transparency • Decouples in time and failure • Prevents cascade failures
- 9. © 2019 Objectivity Ltd Classification Why we need reactive software? Business perspective Technical perspective Software is present in almost every business Business cannot afford unresponsive software Business is not able to operate without robust and responsive systems Competition on software market enforces high service quality and end-user satisfaction These days systems needs to handle radical changes in load (peak loads) – Black Friday, Sales Business needs cost-effective software, it doesn’t pay for the idle time of the system Nowadays software systems get bigger and bigger Serves, handles and processes more and more data Systems just need to scale Architecture which favors isolation and containment of failures Loose coupling, flexibility and elasticity
- 10. © 2019 Objectivity Ltd Classification Reactive System vs reactive programming Reactive System and reactive programming is not the same thing. Futures Reactive Streams Promises Reactive programming Futures Reactive Streams Promises Reactive programming Blocking calls Regular non-reactive programming Reactive Systemmicroservice microservice microservice
- 11. © 2019 Objectivity Ltd Classification Why not synchronous communication? • Reduces availability • Limited flexibility Sync communication Async comunication Reduces availability Limited flexibility Simple architecture Location tranparency need to be provided by separate component (load balancer, service discovery) Couples in time Favors waterfall failures Holds resources It’s not how the real world communicates Increases availability Facilitates flexibility More complex architecture (message broker) Out-of-the box location transparency Decouples in time Enables isolation and containment Releases resources Represents the real world communication
- 12. © 2019 Objectivity Ltd Classification Asynchronous service API Service Command Query Event publisher <<inbox>> <<outbox>> <<event channel>> message: • command • query/response • event event
- 13. © 2019 Objectivity Ltd Classification Command vs event Command Event • Represents an intent • Can be discarded • Represents a fact • Cannot be discarded Message Both carried by
- 14. 01 02 03 04 © 2019 Objectivity Ltd Classification Isolation in Reactive Systems Isolation in space Service can be deployed anywhere Service can be restarted, replaced, moved around during its lifetime (to different host, networks, data centers) location transparency != transparent remoting Isolation in state Isolation in time Request can go successfully even if target is not available in a given time Asnynchronous, non-blocking communication Isolation in failure Failures are not propagated to clients Failures of one service should not cause failure of other service System stays operational even in case of failures Data is private to service An access to data is only available though service APIa No data sharing through database sharing
- 15. © 2019 Objectivity Ltd Classification Main concerns • Autonomicity • Consistency • Reliability • Preserving a message order • Isolation of the „transaction”
- 16. © 2019 Objectivity Ltd Classification Autonomous services – no isolation (sync) Service A Service B
- 17. © 2019 Objectivity Ltd Classification Autonomous services – no isolation (sync) Service A Service B
- 18. © 2019 Objectivity Ltd Classification Autonomous services – no isolation Service A Service B
- 19. © 2019 Objectivity Ltd Classification Autonomous services – no isolation (sync) Service A Service B
- 20. © 2019 Objectivity Ltd Classification Autonomous services – with isolation (sync), cache Service A Service B cache
- 21. © 2019 Objectivity Ltd Classification Autonomous services – with isolation (sync), cache Service A Service B cacheHIT
- 22. © 2019 Objectivity Ltd Classification Autonomous services – with isolation (sync), cache Service A Service B cacheMISS
- 23. © 2019 Objectivity Ltd Classification Autonomous services – with isolation (sync), cache Service A Service B cacheMISS
- 24. © 2019 Objectivity Ltd Classification Autonomous services – async Service A Service B <<subscribe>> <<publish>> Event stream / event store
- 25. © 2019 Objectivity Ltd Classification Autonomous services – async Service A Service B <<subscribe>> Event stream / event store
- 26. © 2019 Objectivity Ltd Classification Consistency - problem Service A Service C <<command>> Service B 1 <<command>> 2 <<response>> 3 <<command>> 4 <<error>> 5 2 How to deal with already commited local transaction triggered by In fact of ?5
- 27. © 2019 Objectivity Ltd Classification Consistency - orchestration Service A Service C <<command>> Service B 1 <<command>> 2 <<response>> 3 <<command>> 4 <<error>> 5 Saga <<compensation_of_2>> 6
- 28. © 2019 Objectivity Ltd Classification Consistency - choreography Service A Service C <<command>> Service B 1 <<event>> 2 <<event>> 3 <<event>> 3 <<event>> 5 Message broker <<event>> 2 <<event>> 5 <<event>> 5
- 29. © 2019 Objectivity Ltd Classification Consistency – orchestration by events Service A Service C <<command>> Service B 1 <<event>> 2 <<command>> 3 <<command>> 5 <<event>> 6 Message broker <<event>> 2 <<command>> 8 <<command>> 7 Service A Saga <<command>> 3 <<event>> 4 <<event>> 4 <<command>> 5 <<event>> 6 <<command>> 7 8
- 30. © 2019 Objectivity Ltd Classification Reliability – do we really need it? Delivery guarantees: • At most once • At least once • Exactly once Do we really need it to be provided by messaging protocol? Service A Service B Service A Service B A A A at-most-once delivery at-least-once delivery Message duplication handling: • Idempotency of business operation • Explicitly provided by business logic
- 31. © 2019 Objectivity Ltd Classification Out of order processing in scaled up services - problem Service A Service B1 A Message broker B A B Service B2 A B <<processed>> <<processed>>
- 32. © 2019 Objectivity Ltd Classification Out of order processing in scaled up services - solution Service A Service B1 Message broker C B Service B2 <<processed>> <<processed>> Service A shards / partitions AC A A C DB D D B C A B D partition partition …
- 33. © 2019 Objectivity Ltd Classification Isolation of distributed „transactions” Problems • Lost updates • Dirty reads • Non-repeatable reads Possible solutions • Semantic lock • Commutative updates • Pessimistic View • Reread value
- 34. © 2019 Objectivity Ltd Classification Worth looking at 1. Reactive courses - https://www.lightbend.com/learn/lightbend-reactive-architecture 2. Nobody needs reliable messaging - https://www.infoq.com/articles/no-reliable-messaging 3. Life Beyond the Illusion of Present - https://www.youtube.com/watch?v=Nhz5jMXS8gE 4. Data on the Outside versus Data on the Inside - http://cidrdb.org/cidr2005/papers/P12.pdf 5. Eventually Consistent, Revisited - https://www.allthingsdistributed.com/2008/12/eventually_consistent.html 6. Life beyond Distributed Transactions - http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf 7. Memories, Guesses, & Apologies – http://cidrdb.org/cidr2007/gongshow/15Helland.ppt 8. Microservices Patterns (book) - https://www.manning.com/books/microservices-patterns
- 35. © 2019 Objectivity Ltd Classification Thank you!
Editor's Notes
- it’s not a new thing Reactive Systems is a response for looking by different people for solutions for the same problems – unified, documented outline of solution Reactive Manifesto is just a try to address people concers, what peple tried to achive so far to achive the same goal
- Failure is contained in single component – recovery is delegated to separate component
- decouples components allows to scale them independently
- If software doesn’t work in the Reactive way or for a specific period of time – you are not able to work, company cannot operate normally, which brings a real many losses. Not only software failures makes the business not operating properly – slow / unresponsive / hanging systems as well From one end software is not the same one as years back, but also software users and their expectations are different People rely on software to do their jobs The more World is driven by software the higher expectations regarding it Non responsive software is quickly thrown out of the marker – there are alteratives – market is compet
- Reactive Systems - Reactive features from system architectural level, all architetural componetns (microservices) interacts in the Reactive eway Reactive Programing – doesn’t actually mean that you build Reactive System but it’s often used to build one. Reactivness at microservice level. You don’t need Reactive Programming to build Reactive systems. Both provides Reactive features but on different levels
- it’s still monolit * location transparency * one-to-one, one-to-many * it’s like with eventual consistency, that’s not like the world works
- Same thing when it comes to transportation media, just name and interpretation differs Events reverts the dependencies between services – I can add another participant (observer of events without chaning source service) Event-Carried State transfer – event brings all data so the event oberver has all necessary information and don’t need to fetch additional data
- Fully aunotomous service has no dependencies, but this is really rare case The less dependencies the better The closer to fully anotomous service the better Ideal anatomous services can scale indefinately. Anatomous systems can tolerate any number of its dependencies’ failures, the entire world can fail around and they still stay resposive Asynchronous communication increases autonomy of the service
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Same thing when it comes to transportation media, just name and interpretation differs
- Reliabiable delivery – quarantee that the message is delived once and only once WS-ReliableMessaging provides Reliability at a communication level through SOAP headers - business layer is independent of the messaging layer – business logic has no burden of Reliability guarantee – provides all kinds of quarantee + „in order” Reliable messaging solves this issues on the pictures by acknowledgments, duplicate detection and removal Duplicated sequence numer in message header and message body (business content) If we don’t need „in order” delivery why do we need a delivery mean to delay the message until it gets message with lower sequence numer Even if we deliver message in proper order does that mean the got processed in that order? Is the delivery quarantee a real quarantee that the message has been processed? Acknowledgement after verification that the message is syntacticly correct (validation)? Acknowledgment after processing? What if the processing fails… do we need both acknowledge and response of failure? Delivery acks are rather useless we need business ack. What if the same message is send again (maybe by mistake) by source service (not resent by message system). Business logic should process it again?
- Comutative updates can be done in any order Pesimistic view – reordering steps of saga to minimize the risk of dirty reads Reread value – reread first from database and then check if the record has changed Lost updates, dirty reads, fuzzy/non-repeatable reads
- Comutative updates can be done in any order Pesimistic view – reordering steps of saga to minimize the risk of dirty reads Reread value – reread first from database and then check if the record has changed Lost updates, dirty reads, fuzzy/non-repeatable reads