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

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
44. Pode emitir de 0 to 1 eventos, passando por OnNext (), OnComplete () e onError. Mono
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
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