Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Razões e Emoções na Programação Reativa com Java

Razões e Emoções na Programação Reativa com Java

Essa palestra é de 2019, na época, a versão de Java que eu estudava e trabalhava era a 8 e a 11. Também é importante saber que eu era desenvolvedora Junior e que eu acabei fazendo algo mais voltado a expor meus estudos do que algo mais prático. Levando tudo isso em consideração, espero que seja util :)

Jessilyneh

June 29, 2019
Tweet

More Decks by Jessilyneh

Other Decks in Technology

Transcript

  1. Nada do que foi será, denovo, do jeito que já

    foi um dia... • maior quantidade de usuários; • maior quantidade de requests e mais dados; • maior exigência de performance e tempo de resposta; • Intolerância a downtime; • Maior quantidade de nós de servidores por aplicação necessários para atender a toda essa demanda.
  2. “Não vou mudar a arquitetura agora” “A equipe não vai

    saber fazer, vamos manter assim mesmo” “o projeto já está em andamento, vamos ver no próximo”
  3. “A programação funcional tem muito mais a ver com paradigmas

    a serem utilizados do que com frameworks e arquiteturas de projetos” Bruno Bilescky, “Programação Funcional e Reativa para todos”
  4. 4 pilares da programação reativa Reage á usuários em tempo

    real Reage e se recupera a falhas de software Gerenciadores assíncronos e não bloqueantes Reage á demanda (cores/servidores)
  5. 4 pilares da programação reativa Reagir á usuários em tempo

    real Reagir e se recuperar a falhas de software Gerenciadores assíncronos e não bloqueantes Reagir à demanda (cores/servidores)
  6. Threads e Capacidade de concorrência Administração manual de threads; Java

    5 - java.util.concurrent - Executors. Java 7 - Fork/Join framework Criação de aplicações de alta concorrência sem se preocupar com detalhes de baixo nível é possível? Framework Akka!
  7. Modelo de Concorrência Estado compartilhado: o código a ser paralelizado

    é executado simultaneamente através da criação de processos ou threads. Quando as threads precisam acessar a mesma informação (estado compartilhado), usamos blocos synchronized, que acabam gerando um gargalo na aplicação, pois as instruções protegidas por synchronized são executadas apenas por uma thread por vez.
  8. Modelo de Concorrência Troca de mensagens: Os componentes não compartilham

    estado e se comunicam através de mensagens predominantemente assíncronas. O envio das mensagens normalmente é feito por algum outro software que atua como intermediário entre os componentes. Este “desconhecimento” entre os componentes garante um bom nível de desacoplamento e favorece a distribuição, pois permite a troca de mensagens entre componentes que estejam em servidores diferentes ou até em outras redes.
  9. “tudo são atores” Os atores são definidos como entidades capazes

    de realizar um processamento computacional e que se comunicam entre si através do envio e recebimento de mensagens. A comunicação entre atores é feita estritamente pela troca de mensagens, o estado interno de um ator não é acessível para outros. Um ator pode ter várias mensagens pendentes, mas apenas uma ser processada por vez, eliminando problemas com lock.
  10. Escrito em Scala e com API para Scala e Java,

    o Akka foi desenvolvido sobre a API de concorrência do Java e que possibilita ao desenvolvedor utilizar um modelo de concorrência baseado em atores. O Akka foi desenvolvido em 2009 por Jonas Bonér, inspirado pelo modelo de atores do Erlang Em Akka, a comunicação entre serviços usa mensagens assíncronas que otimizam a utilização da CPU, baixa latência, alto rendimento e escalabilidade.
  11. Akka Revelado: A jornada de um arquiteto da JVM de

    atores resilientes para clusters escalonáveis
  12. Operação de maneira distribuída Atores: Utiliza o modelo de concorrência

    baseado em atores · Futures: Os futures do Akka são muito parecidos com a implementação padrão do java.util.concurrent, porém possui integração com atores; · Scheduler: integrado ao contexto de atores, o Akka permite o agendamento de tarefas usando vários tipos de schedulers.
  13. RxJava (Reactive extensions Java) Embora o RxJava não seja tão

    explicitamente orientado a mensagens como outras implementações de sistemas reativos, tais como os modelos de atores (por exemplo, o Akka), a plataforma RxJava oferece inúmeros recursos onde essa característica de orientação a mensagens fica mais evidente. O melhor exemplo disso são os Subjects que implementam o padrão Publish/Subscribe. No RxJava, um Subject representa um Observer e um Observable ao mesmo tempo, permitindo o multicasting de eventos de uma única fonte para múltiplos Subscribers filhos. Observer: coleção que funciona de forma unidirecional, ou seja, ele emite notificações sempre que ocorre uma mudança em um de seus itens e a partir disso podemos executar uma ação.
  14. Alpakka O projeto Alpakka é uma iniciativa de código aberto

    para implementar pipelines de integração reativa e com reconhecimento de fluxo para Java e Scala. Ele é construído sobre o Akka Streams e foi projetado desde o início para entender o fluxo nativamente e fornecer uma DSL para programação reativa e orientada por fluxo, com suporte integrado para contrapressão. O Akka Streams é uma implementação compatível com JavacontactStreams e JDK 9+ java.util.concurrent.Flow e, portanto, totalmente interoperável com outras implementações.
  15. Quem me ajudou a construir essa palestra: https://www.reactivemanifesto.org https://www.youtube.com/watch?v=wioDkHQ9Pm8&feature=youtube_gdata https://www.devmedia.com.br/akka-programacao-concorrente/30714

    https://doc.akka.io/docs/alpakka/current/ https://www.linkedin.com/learning/reactive-programming-with-java-8 https://pt.stackoverflow.com/questions/207362/qual- é-a-diferença-entre-promises-e-observables