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

Monolíticos Distribuídos: Um case de Falha que ...

Monolíticos Distribuídos: Um case de Falha que deu certo

Evento: Meetup PHPRS - Microserviços
Nessa talk vamos falar sobre um case de migração de uma aplicação legada monolítica para uma arquitetura distribuída baseada em microserviços, na qual atingiu seu objetivo porém ao custo do hype do momento..

Igor Duarte

June 17, 2019
Tweet

More Decks by Igor Duarte

Other Decks in Technology

Transcript

  1. • Sistemas de Informação - ULBRA • PHP Developer •

    PHP Developer há 5 anos • Coordenador da Comunidade • Escritor • Criador de ElePHPants • Gamer nas horas vagas ;)
  2. • Aplicação monolítica legada • Escrita em PHP 5.4 em

    2012 • Totalmente estruturada e sem OO • Dividida em 2 partes Site e CMS Caso de Uso • + 3 mil usuários cadastrados • + 350 palestrantes • + de 400 Oficinas, workshops e outras atividades • 6 anos de congresso
  3. Site • Gerenciamento de usuários • Inscrições e Pagamentos •

    Certificados Cenário Atual CMS • Gerenciamento do conteúdo do Site • Gerenciamento do Congresso • Gerenciamento de Inscrições e Pagamentos
  4. • Separar as responsabilidades em serviços independentes • Estrutura descentralizada

    • Facilidade na manutenção • Facilidade e Agilidade para o desenvolvimento de novas features • Facilidade para subir ambiente usando Docker • Estava no HYPE Porque Microsserviços?
  5. Logs Uma arquitetura de microsserviços distribuídos é muito difícil de

    se monitorar. Se acontece algum problema ou algum erro em algum serviço: • Como vamos saber o que aconteceu? • Como vamos saber aonde aconteceu? • Em qual fluxo o usuário estava? Neste cenários os logs de arquivos vão ser o seu pior inimigo. Os logs estavam todos em nível de aplicação. Ou seja cada serviço tratava os seus logs a “sua maneira”
  6. Gargalos Todas requisições estavam sendo processadas de forma Síncrona e

    a melhor forma de resolver isso seria trabalhar a comunicação de forma Assíncrona para facilitar a comunicação entre serviços. Em alguns momentos ocorreu lentidão ou falhas, principalmente ao realizar pagamentos. Por causa do grande número de requisições ao mesmo tempo.
  7. API Gateway Serve como a porta de entrada para os

    seus microsserviços resolvendo problemas comuns como: Autenticação, Limite de uso e CORS (Cross-origin). Sem Gateway Cada serviço implementa sua lógica de autenticação, Log e Cache por exemplo, que acabam gerando inconsistência na utilização de API’s. Com Gateway Autenticação, Log e Cache podem ser resolvidos por exemplo, em uma camada antes de chegar em cada serviço simplificando e centralizando a utilização das API’s.
  8. API Gateway Desvantagens • Mais um serviço a ser desenvolvido

    e mantido. • Pode se tornar um gargalo de desenvolvimento. Vantagens • Único ponto de entrada. • Pode mascarar falhas ou erros, retornando cache de dados. • Fornece maior segurança.