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

DevConf - Separando uma aplicação monolítica @Rafael Girolineto

DevConf - Separando uma aplicação monolítica @Rafael Girolineto

Primeiro Evento organizado pelo Opensanca se trata do DevConf, tivemos a participação do Rafael Girolineto (https://www.linkedin.com/in/girolineto/) abordando sobre Microserviços

Opensanca

May 27, 2017
Tweet

More Decks by Opensanca

Other Decks in Programming

Transcript

  1. Rafael Pereira Girolineto Eng. da Computação - USP São Carlos

    9 anos no mercado de TI Líder técnico no CasaeCafe.com Apreciador de cerveja e café (não necessariamente nesta ordem) Apaixonado por Fotografia (analógica e digital)
  2. Agenda • Aplicações Monolíticas e Microserviços • Microserviços ◦ Definições

    ◦ Aplicabilidade ◦ Padrões de Design ◦ Docker ◦ Vantagens e Desvantagens • CasaeCafe.com ◦ Problema ◦ Solução Proposta ◦ Passo a Passo ◦ Dificuldades
  3. Qual a diferença? Monolito Microserviços Se você não é capaz

    de construir uma aplicação monolítica bem estrutura, o que te faz pensar que microserviços é uma saída? – Simon Brown
  4. Monolito • Processo Único • Base de dados unificada •

    Integrações via chama de função • Integrações no banco de dados • Uso de uma stack única • Tendência a alto acoplamento • Tendência a baixa redundância de informação Fonte: https://martinfowler.com
  5. Microserviços • Múltiplos processos • Separação do modelo de dados

    • Integrações por chamadas remotas • Fronteira bem definida • Possibilidade de diversas stacks • Baixo acoplamento entre módulos • Tendência a alta redundância de informação Fonte: https://martinfowler.com
  6. Definições • Independência: ◦ Modelo Interno ◦ Tecnologias utilizadas ◦

    Atualizações / Deploys ◦ Escalabilidade • Descentralização dos dados (e do modelo de dados) • Propósito único: domínio a ser tratado • Fronteira: ◦ Codebase separada (uni / multi repositórios) ◦ API pública estável, versionada e bem definida ◦ Protocolo único de comunicação (RESTish)
  7. Aplicabilidade Quando faz sentido adotar Microserviços? "Qualquer empresa que projeta

    um sistema, inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização." - Melvin Conway
  8. Conway's Law Seguindo esta lei, a empresa que planeja trabalhar

    com Microserviços deve ter equipes com: • Multidisciplinaridade • Autonomia sobre um domínio (ou mais) • Comunicação com times de domínios próximos e VICE-VERSA Fonte: https://www.thoughtworks.com/pt/insights/blog/demystifying-conways-law
  9. Constraints Quais são os requisitos mínimas para adotar Microserviços? Provisionamento

    rápido de infraestrutura: • Utilização de algum provedor de cloud 1 Capacidade de entregar em produção rapidamente • Testes automatizados, releases pequenas, automatização 2 Monitoria básica • Acesso aos logs, status da infraestrutura, status dos serviços 3
  10. Padrões de Design Timeout Controle configurável de tempo máximo de

    espera para obter uma resposta Circuit Breaker Gestão de disponibilidade de serviços através de medição de erros Bulkheads Capacidade de suportar a serviços indisponíveis de forma "graciosa"
  11. Padrões de Design Arquitetura Orientada a Eventos • Consistência eventual.

    • Cada serviço publica eventos sempre que algum dado muda. • Os subscribers destes eventos e podem executar ações após receberem • Após o processamento de toda a árvore de eventos, o sistema fica, novamente, consistente
  12. Arquitetura Orientada a Eventos UI Order Microservice Payment Microservice Payment

    Gateway Realizar pedido Criar pedido ... [evento] Pedido Criado ... [evento] Pagamento Aprovado pagar
  13. Docker • Fidelidade de Ambientes • Comoditização da Infra Estrutura

    • Escalabilidade Horizontal • Deploy consistente
  14. Veredito? Desvantagens • Complexidade • Impraticável sem automação • Custo

    alto para integração entre módulos • Multiplas stacks Vantagens • Times auto gerenciáveis • Times multifuncionais • Desacoplamento • Independência entre módulos • Arquitetura Evolutiva • Multiplas stacks DEPENDE
  15. A Empresa Marketplace de empregos domésticos • Profissionais buscam emprego

    • Contratantes buscam profissionais • Geolocalização • Reputação + 500 mil usuários
  16. MVP

  17. O Problema • MVP tornou-se o produto • Produto ganhou

    escala • Não existiu preocupação com qualidade de software • Lógica de negócio obscura ou desconhecida • Sistema escalou verticalmente • Indisponibilidade de serviço constante
  18. Solução Proposta Encontrar uma entidade do sistema que pudesse ser

    isolada 1 Entender a regra de negócio associada à esta entidade 2 Criar um serviço completamente independente com a lógica de negócio implementada 3 Usar o sistema antigo como fallback até que a lógica toda fosse implementada 4 MICROSERVIÇOS
  19. Resultados Iniciais • Redução de lock no Banco de Dados

    • Diminuição no tempo médio de transações envolvendo vagas • Fallback permitiu dupla convivência • Insuficiente para resolver problemas de escalabilidade da plataforma
  20. Review Evolução Opport User Prof WebF Event Search Payment Metric

    Message Products Account Fav Notif Auth Audit AppF Extract Behav
  21. Alguns dados técnicos • REST over HTTP - JSON •

    Cluster Docker Swarm • AWS EC2 • Deploy de Imagens Docker • Bancos de Dados MongoDB (e um Cassandra perdido) • Comunicação síncrona (na maior parte) • PHP7 + NGINX
  22. Dificuldades • Problemas por falta de automatização • Problemas por

    falta de monitoria • Perda de produtividade do time: ◦ Ambientes ◦ versionamento de API ◦ Deploy • Overhead de requisições
  23. Referências • Martin Fowler: https://martinfowler.com/ • Microservices.io: http://microservices.io/ • Building

    Microservices - Sam Newman • Release It!: Design and Deploy Production-Ready Software - Michael T. Nygard • ThoughtWorks: https://www.thoughtworks.com • Netflix Techblog: https://medium.com/netflix-techblog • NGINX Blog: https://www.nginx.com/blog