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

Slide 1

Slide 1 text

Monolíticos Distribuídos Um case de falha que deu certo

Slide 2

Slide 2 text

● Sistemas de Informação - ULBRA ● PHP Developer ● PHP Developer há 5 anos ● Coordenador da Comunidade ● Escritor ● Criador de ElePHPants ● Gamer nas horas vagas ;)

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

● 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 Oﬁcinas, workshops e outras atividades ● 6 anos de congresso

Slide 5

Slide 5 text

Site ● Gerenciamento de usuários ● Inscrições e Pagamentos ● Certiﬁcados Cenário Atual CMS ● Gerenciamento do conteúdo do Site ● Gerenciamento do Congresso ● Gerenciamento de Inscrições e Pagamentos

Slide 6

Slide 6 text

Cenário Atual

Slide 7

Slide 7 text

● 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?

Slide 8

Slide 8 text

Cenário Atual + Novas Features

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Beleza! e Agora?

Slide 11

Slide 11 text

#timetocode

Slide 12

Slide 12 text

4 meses depois

Slide 13

Slide 13 text

Projeto Entregue

Slide 14

Slide 14 text

Sim! e com ele diversos problemas!

Slide 15

Slide 15 text

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 ﬂuxo 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”

Slide 16

Slide 16 text

Qual seria a solução?

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

Qual seria a solução? Implementação de algum padrão como Publish Subscribe.

Slide 19

Slide 19 text

Melhorias

Slide 20

Slide 20 text

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 simpliﬁcando e centralizando a utilização das API’s.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

Aprendizado imensurável para a equipe!

Slide 23

Slide 23 text

Recomendação

Slide 24

Slide 24 text

Dúvidas

Slide 25

Slide 25 text

twitter.com/IgorSantoos17 linkedin.com/in/igorsantoos github.com/IgorSantos17 medium.com/@igorsantos17 speakerdeck.com/igorsantos

Slide 26

Slide 26 text

#junteseamanada