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

Cloud-Conference-Day-Spring Cloud + Spring Webflux: como desenvolver seu primeiro microsserviço reativo em Java?

Cloud-Conference-Day-Spring Cloud + Spring Webflux: como desenvolver seu primeiro microsserviço reativo em Java?

More Decks by Kamila de fatima santos oliveira

Other Decks in Programming

Transcript

  1. Spring Cloud + Spring Webflux: como desenvolver seu primeiro microsserviço

    reativo em Java? C L O U D C O N F E R E N C E D A Y Kamila Santos
  2. Kamila Santos Tech Lead na Zup Innovation Microsoft MVP criadora

    de conteúdo no youtube e instagram Kamila_code
  3. Agenda DO QUE VAMOS FALAR HOJE? O que são microsservicos?

    Características de microsservicos Padrões de microsserviços Spring Cloud Projetos do Spring Cloud
  4. Agenda DO QUE VAMOS FALAR HOJE? Paradigma reativo? Manifesto Reativo

    Reactive Streams Conceitos da programação reativa Spring Webflux Projeto reactor
  5. Agenda DO QUE VAMOS FALAR HOJE? RxJava Mas a Netflix

    ta saindo do modelo reativo???? E esse tal de Project Loom? Vamos ao código!!
  6. O que são microsserviços?

  7. São uma abordagem de arquitetura na qual o software é

    composto de pequenos serviços independentes que se comunicam entre si e são organizados de acordo com seus domínios de negócio.
  8. Características de microsserviços

  9. Cada serviço pode ser desenvolvido, escalado e implantado sem interferir

    em outros serviços. Autônomos
  10. Não é necessário compartilhar nenhum código e a comunicação acontece

    por meio de chamadas as APIs (síncronas) ou de forma assíncrona. Autônomos
  11. Cada serviço é desenhado para resolver um problema específico ,

    se começar a ser necessário ter outras responsabilidades é indicado que se crie um novo serviço. Especialistas
  12. A independência do serviço aumenta a resiliência a falhas na

    arquitetura , se um deles tiver algum problema , só afetará alguma parte do fluxo. Resilientes
  13. A divisão em módulos com responsabilidades bem definidas permite que

    funções específicas de algum serviço possam ser utilizadas para complementar features em outros sem precisar reescrever o código. Reutilização de código
  14. Os responsáveis por cada serviço podem decidir qual a melhor

    stack para cada caso. Liberdade da escolha de stack
  15. Padrões de microsserviços https://microservices.io/

  16. Monolítica - arquitetar um aplicativo como uma única unidade implantável

    Microsserviços - arquitetar um aplicativo como uma coleção de serviços fracamente acoplados Padrões de arquitetura
  17. Strangler Patterns - cria uma nova aplicação em torno do

    monolito legado, fazendo as funções do antigo monilito e adicionando novas, agregando mais valor ao novo serviço AntiCorruption Layers - cria uma camada de anticorrupção que se traduz entre os modelos de domínio (do monolito que foi herdado e do microsserviço novo que está sendo desenvolvido) Padrões de refatoração
  18. Database per Service - cada serviço tem seu próprio banco

    de dados privado Saga - trabalha com uma sequência de transações locais, para manter a consistência dos dados entre os serviços Padrões de gerenciamento de dados
  19. Api Composition - implementar consultas invocando os serviços que possuem

    os dados e realizando uma junção na memória CQRS - Define um banco de dados read-only, que é uma réplica somente leitura projetada para oferecer suporte a essa consulta. O aplicativo mantém a réplica atualizada por meio de eventos; Padrões de gerenciamento de dados
  20. Domain Event - publica um evento sempre que os dados

    forem alterados Padrões de gerenciamento de dados
  21. API Gateway - um serviço que fornece a cada cliente

    uma interface unificada para serviços, adicionando uma camada a mais de segurança, fazendo balanceamento de carga, etc Backend-for-frontend - um gateway de API separado para cada tipo de cliente Padrões de APIs externas
  22. Spring Cloud

  23. Spring possui uma grande variedade de projetos para os mais

    variados cenários e necessidades dentro de uma aplicação
  24. Facilita a criação de sistemas distribuidos que são cloud native

    https://spring.io/projects/spring-cloud Spring Cloud
  25. Possibilita que microsserviços descubram facilmente a rota de outros serviços

    que precisem acessar, os mais conhecidos são Spring Cloud Consul e Spring Cloud Netflix Eureka Service Discovery
  26. Tem o papel de ser um intermediário nas nossas requisições

    para outros serviços. Os mais conhecidos são o Zuul e o Spring Cloud Gateway Gateway
  27. Permite armazenar configurações de modo centralizado , para isso temos

    o Spring Cloud Config Server Configuração centralizada - Config Server
  28. Um modo simples de se comunicar com outras aplicações Open

    Feign
  29. Controle sobre falhas e altas taxas de latência dentre os

    serviços, mais conhecido: Resilience4J Circuit Breaker
  30. Inclui id único a cada requisição que entra na aplicação,

    o que facilita o rastreamento de requisições que passam por um grande fluxo dentro do serviço Sleuth
  31. Paradigma reativo

  32. É um paradigma de programação orientado a fluxos de dados/eventos,

    bem como a propagação dos mesmos de forma assíncrona. Paradigma reativo
  33. Manifesto reativo

  34. https://www.reactivemanifesto.org/pt-BR

  35. O sistema responde em tempo hábil, se possível Responsivo

  36. O sistema permanece responsivo a falhas Resiliente

  37. O sistema permanece responsivo em face de uma carga de

    trabalho variável. Elástico
  38. Os aplicativos reativos contam com a passagem de mensagens assíncronas

    para estabelecer um limite entre os componentes, garantindo acoplamento flexível, isolamento e transparência Message Driven
  39. Conceitos de programação reativa

  40. Resistência ou força que se opõe ao fluxo de dados

    desejado por meio do software. Feedback do receptor ao produtor de que ele não está suportando a carga. BackPressure
  41. Sequência de objetos que suporta vários métodos que podem ser

    operados para produzir um resultado Stream
  42. Pode emitir de 0 to N eventos, passando por OnNext

    (), OnComplete () e onError. Flux
  43. None
  44. Pode emitir de 0 to 1 eventos, passando por OnNext

    (), OnComplete () e onError. Mono
  45. None
  46. consome os dados recebidos da subscription Subscriber

  47. produz os dados que serão consumidos pela assinatura. Publisher

  48. conexão entre o Subscriber e o Publisher Subscription

  49. a sequência de eventos só é executada se o Observable

    tiver um subscriber associado Cold observable
  50. ele emite eventos independentemente de haver um subscriber associado Hot

    observable
  51. Reactive streams

  52. Reactive Streams https://www.reactive-streams.org/

  53. Spring Webflux

  54. Spring WebFlux pode ser definido como uma versão “paralela” ao

    já conhecido e amplamente utilizado Spring MVC (servlet), tendo como principal diferença o suporte para streams NIO reativos e por suportar o conceito de backpressure com o servidor Netty vindo por default embutido em seu arquitetura. Spring Webflux
  55. A partir da versão 5.0 do Spring Framework temos uma

    parte reativa além da estrutura Servlet que já existia, cada módulo destes é opcional, você pode usar a parte Servlet, a parte reativa ou mesmo ambas em suas aplicações. Spring Webflux
  56. Spring Webflux foi desenvolvido porque precisávamos de aplicativos não bloqueantes

    que pudessem trabalhar com um pequeno número de threads simultaneamente e que pudessem ser executados com alguns recursos de hardware. Spring Webflux
  57. Projeto Reactor

  58. https://projectreactor.io/

  59. É uma biblioteca baseada nas Reactive Streams Specifications, é totalmente

    não bloqueante e interage diretamente com a API Java funcional (Stream, Duration e Completable Future), para composição de elementos utilizando Flux e Mono em arquiteturas de microsserviços , oferecendo mecanismos de backpressure prontos para TCP, UDP e HTTP (incluindo sockets da web). Projeto Reactor
  60. Seus operators e schedulers podem suportar um grande volume de

    transferência (até 10 milhões de solicitações por segundo, de acordo com a documentação do Reactor https://projectreactor.io/), também foi a primeira biblioteca reativa a implementar alguns pontos sugeridos pela reactive streams applications( https://github.com/reactor/reactive-streams-commons), que mais tarde também foram implementados por RxJava2. Projeto Reactor
  61. Seus módulos são fluxos reativos abstratos e interoperáveis ​ ​

    para facilitar o seu desenvolvimento, podendo ser utilizados com:Spring FrameworksDrivers e clientes (por exemplo CloudFoundry Java Client https://github.com/cloudfoundry/cf-java-client)- em protocolos / contratos como R2DBC (https://r2dbc.io/) e RSocket (https://rsocket.io/), por exemplo. Projeto Reactor
  62. é a parte principal desta biblioteca, os outros módulos são

    dependentes dela, ela fornece tipos reativos que implementam um Publisher que fornece Flux e Mono Reactor Core
  63. é o servidor de nosso aplicativo NIO, usada para o

    desenvolvimento de servidores altamente escaláveis. Reactor Netty
  64. Voltado para o desenvolvimento de testes com webflux Reactor Test

  65. RxJava

  66. https://reactivex.io/

  67. É uma implementação para a JVM das Reactie Extensions ,

    que é uma biblioteca assíncrona e baseada em eventos que trabalha com sequências de observables. Rx Java
  68. Estende do padrão observer -> cada objeto chamado (subject), tem

    uma listas de dependentes (observers) que são notificados pelo subject automaticamente a cada mudança de estado por meio de seus operadores e métodos. Rx Java
  69. Suporta sequências de dados e eventos para compor suas sequências

    de eventos de forma declarativa. Rx Java
  70. Mas se o modelo reativo é tão bom, por que

    a netflix parou de usar?
  71. https://netflixtechblog.com/zuul-2-the-netflix-journey-to- asynchronous-non-blocking-systems-45947377fb5c

  72. https://twitter.com/pbakker

  73. https://twitter.com/rafaelcodes/status/1523327905434062848? s=20&t=maytWvgFrE6fhr8_07NCqQ

  74. None
  75. https://filia-aleks.medium.com/microservice-performance-battle-spring-mvc-vs-webflux- 80d39fd81bf0

  76. Projeto Loom

  77. Traablha alterando a implementação das Threads existentes no SO para

    um tipo de abstração que pode representar a prórpia thread ou uma thread virtual Projeto Loom
  78. Seria uma forma de tirar de um framework/linguagem a responsabilidade

    que criam uma abstração entre as threads da JVM. Projeto Loom
  79. https://openjdk.java.net/jeps/425

  80. https://deviniciative.wordpress.com/2020/08/18/java-15-project-loom-programacao- reativa-e-coroutines/

  81. Chega de conversa, vamos ao código :)

  82. Você tem alguma pergunta? Obrigada! https://beacons.page/kamila_code