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

O que fazer quando microserviços se tornam mons...

O que fazer quando microserviços se tornam monstrinhos? [revisado], TDC Innovation, Stadium

[versão revisada e melhorada]

Todo developer na indústria já teve que enfrentar diversos monstrinhos de código e fluxos legados nos sistemas das empresas. Essa palestra compartilha conhecimentos e experiências sobre como lidar e resolver esses problemas em arquiteturas de microserviços. Venha aprender a refatorar fluxos e arquiteturas legadas de forma segura e eficiente, seguindo padrões e boas práticas.

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

Transcript

  1. • Graduação / Mestrado em Ciências da Computação • 10+

    anos de experiências em diversas techstacks e projetos OLÁ! Eu sou Jéssica Bonson Staff Engineer @ iFood
  2. Tópicos 1. Arquitetura de Microserviços ◦ O que são, e

    como evitar que virem monstrinhos? 2. Padrões de Refatoração para Microserviços
  3. • Trade-off Monolitos vs Microserviços ◦ Menos acoplamento, mais complexidade

    • Não são acoplados por código, mas por dados ◦ Contratos devem ser bem definidos e flexíveis O que são microserviços?
  4. • Síncrona ◦ Request / Response • Assíncrona ◦ Request

    / Response ◦ Eventos ◦ Acesso comum a dados Tipos de Comunicação
  5. • Priorize comunicações assíncronas ◦ Mais paralelismo ◦ Evita acúmulo

    de latência ◦ Menos acoplamento ◦ Mais resiliência e escalabilidade Boas Práticas
  6. • Orquestração Tipos de Controle de Fluxo • Coreografia Serviço

    Serviço Serviço Serviço Serviço Serviço Serviço Serviço Serviço
  7. Fluxo de criação de cadastro de cliente “Building Microservices”, Sam

    Newman Requisitos funcionais podem ser implementados de várias formas!
  8. • Existem várias maneiras de implementar os mesmos requisitos funcionais

    e não-funcionais de um sistema. ◦ Avalie os trade-offs! Boas Práticas
  9. Como definir os serviços? • Várias abordagens: ◦ Domain-Driven-Design (DDD)

    ◦ Volatilidade ◦ Sensibilidade dos dados ◦ Requisitos de performance ◦ Event-storming ◦ … • O importante é que os limites e responsabilidades sejam bem-definidos
  10. O que são limites bem definidos? • Escondem informação •

    Alta coesão ◦ “The code that changes together, stays together” • Baixo acoplamento ◦ “Avoid chatty communication” • Modularidade • Há um trade-off entre redundância e acoplamento
  11. • À medida que a complexidade do sistema aumenta, uma

    boa definição dos domínios e seus limites é essencial. ◦ Vale a pena investir tempo nisso! Boas Práticas
  12. Outras Boas Práticas • Usar IDs para trackear a sequência

    de chamadas • Deploys independentes ◦ Não compartilhar banco de dados • “Keep the pipes dumb, and the endpoints smart” • Circuit Breaker ◦ É mais fácil lidar com serviços que falham rápido do que aos poucos 1 / 3
  13. Outras Boas Práticas • Monitoramento robusto • Evitar caching desnecessário

    ◦ “The fewer the caches, the easier to reason about the system and the freshness of data” • Definir princípios e práticas de arquitetura ◦ Quais são os requisitos não-funcionais? 2 / 3
  14. Outras Boas Práticas • Versionamento ◦ ‘Semantic Versioning’ para bibliotecas

    e repositórios ◦ Endpoints de APIs ◦ ‘Schema Evolution’ para Kafka • Bibliotecas compartilhadas ◦ Ótimas para funcionalidades técnicas ◦ Péssimas se tiverem regras de negócio • Seguir Padrões e Frameworks já estabelecidos ◦ Evite reinventar a roda 3 / 3
  15. Por que quebrar um microserviço? • Microserviços legados tem problemas

    muito semelhantes a monolítos legados… ◦ …mas com algumas complexidades a mais • Mindset de “Arquitetura Sacrificável” ◦ O código precisar ser sacrificado é sinal de sucesso do produto ◦ A qualidade ainda é importante ◦ Modularidade é essencial ◦ Evita otimização prematura
  16. Como quebrar um microserviço? • Motivo? ◦ Complexidade Procure por

    domínios ◦ Performance Procure por bottlenecks ◦ Time to market Procure por volatilidade • Trade-off entre benefício e dificuldade da refatoração
  17. Como não quebrar um microserviço? • Não faça refatorações “Big

    Bang” ◦ Além dos riscos ao colocar em produção, também há o risco de nunca colocar em produção. “Se você fizer uma refatoração Big Bang, a única coisa garantida é o Big Bang.” Martin Fowler
  18. Tipos de Refatoração • Decomposição ◦ Strangler Fig Pattern ◦

    Branch by Abstraction Pattern • Modificação ◦ Parallel Run Pattern ◦ Expand-Contract Pattern • Combinação
  19. Branch by Abstraction Pattern • Usado como preparação para o

    Strangler Fig Pattern “Monolith To Microservices”, Sam Newman
  20. Parallel Run Pattern • É importante comparar resultados e acompanhar

    o uso. • Podem receber as mesmas requisições e só um ser usado, ou funcionar como um canário. Service 1 App Service 1 App Service 2 Service 2 App
  21. Expand-Contract Pattern • Exemplo: Renomear um campo A para B

    1. Adiciona o campo B, sem usar 2. Escrita tanto em A como em B 3. Leitura apenas em B 4. Aguardar/Corrigir bugs 5. Remover campo A
  22. Complexity Hell: Como escapar? Técnicas para lidar com microserviços legados

    Extra! - 12 de julho https://materiais.ifood.com.br/event_lunch_and_learn_12072022 (ou shorturl.at/mpGLZ)
  23. Boas Práticas na Documentação • Usar OpenAPI e AsyncAPI /

    CloudEvents • “Humane registry” • Obter dados reais dos sistemas • Usar metadados • ‘Health score’ de operação Bônus