Reactive Programming - Brincando com eficiência, composição e assíncronia

Trilha HPC TDC 2015: Mostramos quais são as principais vantagens e desvantagens da programação reativa. Atualmente existem algumas perguntas que ainda de fato não temos respostas: Será que nossos sistemas já estão no limite? Será que ainda há espaço a ser conquistado e ganhos de performance a se descobrir?

Transcript

1. Reactive Programming: Brincando com eficiência, composição e assincronia. Felipe Mamud @ftmamud Raphael Almeida @raphait HPC
2. Agradecimentos HPC
3. Será que nossos sistemas já estão no limite?
5. INTERNET USERS 2.4bi 2012 INTERNET USERS 3.01bi TENS OF SERVERS Fontes: http://recode.net/2014/05/28/meeker-as-internet-user-growth-slows-the-real-driver-is-mobile-usage/ http://www.slideshare.net/wearesocialsg/digital-social-mobile-in-2015 RESPONSE TIME SECONDS CLOUD-BASED CLUSTER MULTICORE OFFLINE MAINTENANCE REAL TIME MILLISEC/MICROSEC 100% UPTIME FAST DATA GIBABYTE DATA BIGDATA PETABYTES 2015
6. As exigências e as expectativas para aplicações mudaram drasticamente nos últimos anos.
7. Precisamos de sistemas que irão: • Reagir a eventos (Event-Driven) • Reagir a carga (Scalable) • Reagir a falhas (Resilient) • Reagir a usuários (Responsive)
8. Reactive Programming “Readily responsive to a stimulus”
9. Reactive Manifesto
10. O que são sistemas Reativos? Sistemas criados como Reativos são muito mais flexíveis, desacoplados e escaláveis. Isso os torna mais fáceis de desenvolver e manter. São mais tolerantes a falhas e quando elas ocorrem são tratadas com elegância ao invés de desastre. Sistemas Reativos são responsivos, dando aos usuários feedbacks mais interativos. Fonte: http://www.reactivemanifesto.org/pt-BR
11. Reactive frameworks Reactor ReactiveX
12. Message-Driven “Reactive Systems rely on asynchronous message-passing”
13. Share Mutable State • with threads: ◦ code that is totally non-deterministic; ◦ the root of all evil; • Avoid it at all cost; • Use immutability;
14. Never/Avoid Block • Unless you really have to; • Blocking kills scalability (+ performance); • Use non-blocking IO; • Use lock-free concurrency;
15. Async • Use asynchronous event/message passing; • Lower latency (vs sales); • Better throughput; • A more loosely coupled architecture, easier to extend, evolve and maintain.
16. Some t ls • Actors • Agents • Future/Dataflow • Reactive Extensions (Rx)
17. Actors • Isolated lightweight event-based processes; • Each actor has a mailbox (message queue); • Communicates through asynchronous and non-blocking message passing; • Location transparent (distributable); • Supervision-based failure management;
18. Agents • Reactive memory cells; • Send a update function to the Agent; • Reads are “free”, just dereferences the Ref; • Composes nicely;
19. Futures/Dataflow • Allows you to spawn concurrent computations and work with the not yet computed results; • Freely sharable; • Allows non-blocking composition; • Build in model for managing failure;
20. Reactive Extensions (Rx) • Extend Futures with the concept of a Stream; • Composable in a type-safe way; • Event-based & asynchronous; • Observable ⇛ Push Collections;
21. Elastic “Capable of being easily expanded or upgraded on demand”
22. • Mobile • SQL Replication • NoSQL DB • Cloud Services Distributed systems
23. What is the essence of distributed computing?
24. What is the essence of distributed computing? 1. Information travels at the speed of light; 2. Independent things fail independently.
25. Why necessary? • Scalability; • Availability; • The network is unreliable; • Location Transparency;
26. “Almost” no limit to scalability. Shared Nothing Assynchronous communication Location Transparency Loose Coupling
27. Resilience “The ability of a substance or object to spring back into shape.” “The capacity to recover quickly from difficulties.”
28. • Exception in thread; • Errors do not propagate between threads; • Error handling tangled with business logic; Failure recover
29. Right Way • Isolate the failure; • Compartmentalize; • Manage failure locally; • Avoid cascading failures; • Supervision;
30. Responsive “Quick to respond or react appropriately”
31. • Latency consistent; • Use Back Pressure; • Smart Batching; • Reative Request (Async & Non-blocking Request & Response) Responsive
33. Dúvidas?
34. THANK YOU! FRIENDS TECHDAY COMPARTILHAR, APRENDER E CONTRIBUIR! Felipe Mamud @ftmamud Raphael Almeida @raphait We are a reactive family