QCon SP 2017 - Reactive Microservices e a experiência do iFood
1 gostou1,109 visualizações
O documento aborda a evolução de microserviços reativos, destacando a importância da programação reativa para a eficiência no processamento e na resposta de sistemas de software diante de desafios como altas cargas de tráfego. Com a adoção de princípios do manifesto reativo, os sistemas se tornam mais responsivos, resilientes e escaláveis, demonstrando melhorias significativas em serviços como o de entrega de pedidos. Os desafios como depuração e dependência de rede são mencionados, mas os benefícios na otimização de recursos e na resposta a falhas são claros.
QCon SP 2017 - Reactive Microservices e a experiência do iFood
- 1. Microservices Reativos A experiência no Tiago Dolphine
- 3. Order food from App or Web Restaurant receives the order Confirms the order and prepare Back office operators Customer search for restaurants APIs Online Delivery
- 4. +3MM pedidos / mês +16K restaurantes ativos +4MM usuários ativos +140K requests/min +200 instâncias em Cloud
- 5. Um pouco do passado...
- 7. Programação imperativa Descrevemos como um programa deve se comportar Sequência de passos (comandos) Chamadas para alterar o estado de um recurso Tradicional Fácil entendimento e ensino
- 8. Mas com o crescimento . . . Número de acessos Consumo de recursos Tempo de resposta aceitável Falhas não podem impactar Popularização de Cloud Computing Adoção de Microservices
- 9. Sistemas de software precisam acompanhar esta evolução!
- 10. Sistemas de software precisam REAGIR !
- 11. Reactive Manifesto (2013… 2014...)
- 12. Responsive: sempre responder e com baixa latência Resilient: sem downtime, responder mesmo em situações de falha Elastic: responder mesmo quando for sobrecarregado, auto escalar Message Driven: comunicação por mensagens async, baixo acoplamento
- 13. Mas porquê Reactive ?
- 14. Blocking ...
- 15. Blocking pode ser um desperdício ! Tempo de resposta pode ficar comprometido Paralelizar: performance com aumento de Threads Threads são custosas e limitadas I/O é lento (chamadas para DB, HTTP…) Threads esperando resposta :( Desperdício de recurso !
- 16. Blocking Total = T1 + T2+ T3
- 17. Non-Blocking Total < T1 + T2+ T3
- 18. Sync Async
- 19. Reactive Programing ● Paradigma baseado no consumo de eventos ● Alteração de dados "over time" -> dispara ações (callback) ● Publish-Subscribe ● Lógica declarativa e composição de operações ● Async e non-blocking ● Escalar vertical -> poucas threads ● Contexto local (não distribuído) ● Desacoplamento no tempo (concorrência)
- 20. Reactive streams ● Padronização de APIs: manipulação de streams de dados ● Backpressure ○ Feedback enviado para o produtor quando o consumidor está pronto para consumir ○ Importante quando o produtor está mais rápido que o consumidor ● Frameworks: Reactor, RxJava, Akka, Vert.x … ● Java 9: java.util.concurrent.Flow * Source: Reactive Streams (4) "Padrão para processamento de fluxo de dados assíncrono com backpressure non-blocking" *
- 21. Reactor "Reactor is a fourth-generation Reactive library for building non-blocking applications on the JVM based on the Reactive Streams Specification"
- 22. Reactor Implementação de reactive streams Publisher ● Mono: 0 ou 1 item ● Flux: sequencia async de 0 a N itens Subscribers ● Consumir dados de publishers (callbacks de sucesso, erro, completo) ● subscribe() -> trigger para startar fluxo de dados ● Nada ocorre sem subscribe()
- 23. Exemplo Flux.range(0, 20) .filter(n -> n % 2 == 0) .map(n -> "Number: " + n) .subscribe(s -> System.out.println( s + " Thread: " + Thread.currentThread().getName())); Number: 0 Thread: main Number: 2 Thread: main Number: 4 Thread: main Number: 6 Thread: main Number: 8 Thread: main Number: 10 Thread: main Number: 12 Thread: main Number: 14 Thread: main Number: 16 Thread: main Number: 18 Thread: main
- 24. Number: 4 Thread: parallel-2 Number: 10 Thread: parallel-2 Number: 16 Thread: parallel-2 Number: 0 Thread: parallel-1 Number: 6 Thread: parallel-1 Number: 12 Thread: parallel-1 Number: 18 Thread: parallel-1 Number: 2 Thread: parallel-3 Number: 8 Thread: parallel-3 Number: 14 Thread: parallel-3 CountDownLatch countDownLatch = new CountDownLatch(1); Flux.range(0, 20) .parallel(3) .runOn(Schedulers.parallel()) .filter(n -> n % 2 == 0) .map(n -> "Number: " + n) .doOnTerminate(() -> countDownLatch.countDown()) .subscribe(s -> System.out.println(s + " Thread: " + Thread.currentThread().getName())); countDownLatch.await();
- 25. Never block a reactive code !
- 26. Spring 5.0 Novo módulo Reativo WebFlux Non-blocking HTTP adaptado em Reactive Streams API Cliente e Servidor reactive Reactor Flux / Mono nas APIs Netty, Undertow, Servlet 3.1 NIO HttpServletRequest → ServerHttpRequest InputStream / OutputStream → Flux<DataBuffer>
- 27. Source: Spring Reference Documentation(9)
- 28. https://github.com/tiagodolphine/spring5-reactive-playground https://github.com/tiagodolphine/reactor-playground Talk is cheap show me the code
- 29. Reactive Systems Reatividade em sistemas distribuídos Desacoplamento ● Tempo: concorrência e paralelismo ● Espaço: transparência na localização de componentes Conjunto de padrões arquiteturais e princípios ● Message based ● Resilience ● Elasticity ● … ● Location transparency
- 30. Aplicar princícios reactive em microservices !
- 32. 2011 Pedidos / Mês 20162013 2014 2015 20k 100k 450k 1M 2,8M 3,5M
- 33. Almoço Jantar
- 34. Alguns problemas atacados Entrega de pedidos aos restaurantes Sincronização de dados entre sistemas Integrações com parceiros Disparo de tarefas (sms, push, emails, cancelamentos…)
- 35. Princípios reactive aplicados em microservices
- 36. Princípios reactive aplicados ● Messaging ⬅ message driven ● HTTP (async processing) ⬅ non-blocking ● Circuit breakers ⬅ responsive ● Retry ⬅ resilient, responsive ● Recovery ⬅ resilient ● ACK Events ⬅ resilient ● Eternal cache (with refresh) ⬅ resilient, responsive ● Auto-Scaling ⬅ elastic ● Reactive Programming ⬅ non-blocking ● Load balancers ⬅ location transparency
- 38. Resultados positivos ● 16K restaurantes conectados ● Entrega de 3MM pedidos e transição de estados ● Push de pedidos polling ● ⇩Tempos de recepção de pedidos ● Disponibilidade de restaurantes (centralizado) ● Elasticidade com recursos menores ● Independência do sistema legado ● Mais responsivo e resiliente (às falhas)
- 40. Dificuldades Debug Trace de erros e logging Curva maior para novos desenvolvedores Dependência de rede e infraestrutura Monitoramento de lógica específica de cada serviço Maturidade em ambiente de produção custosa
- 41. Concluindo... Migraçao para microservices é realidade Aplicar princípios reactive entre microservices Reactive programming internamente para microservices Melhor uso de recursos (mais com menos) Necessário para acompanhar todo crescimento!
- 42. Referências 1. http://projectreactor.io 2. http://projectreactor.io/docs/core/release/reference/docs/index.html 3. http://www.reactivemanifesto.org 4. http://www.reactive-streams.org 5. https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems 6. http://www.oreilly.com/programming/free/developing-reactive-microservices.csp 7. http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp 8. https://spring.io/search?q=Notes+on+Reactive+Programming 9. http://docs.spring.io/spring-framework/docs/5.0.x/spring-framework-reference/html/web-reactive.html 10. https://community.oracle.com/docs/DOC-1006738 11. https://spring.io/blog/2016/04/19/understanding-reactive-types