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

Seu microsserviço realmente está pronto para pr...

Seu microsserviço realmente está pronto para produção?

More Decks by Kamila de fatima santos oliveira

Other Decks in Programming

Transcript

  1. Kamila Santos Tech Lead na Zup Innovation Microsoft MVP Co-org

    WomakersCode, DevsJavaGirl e Perifacode Criadora de conteúdo no @kamila_code co-autora dos livros Jornada Java e Jornada Microsserviços
  2. São uma abordagem de arquitetura na qual o software é

    composto de pequenos serviços independentes que se comunicam entre si e são organizados de acordo com seus domínios de negócio. O que são microsserviços?
  3. Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado

    sem interferir em outros serviços. Características dos microsserviços
  4. Autônomos - Não é necessário compartilhar nenhum código e a

    comunicação acontece por meio de chamadas as APIs (síncronas) ou de forma assíncrona. Características dos microsserviços
  5. Especialistas - Cada serviço é desenhado para resolver um problema

    específico, se começar a ser necessário ter outras responsabilidades, é indicado que se crie um novo serviço. Características dos microsserviços
  6. Resilientes - A independência do serviço aumenta a resiliência a

    falhas na arquitetura , se um deles tiver algum problema , só afetará alguma parte do fluxo. Características dos microsserviços
  7. Algumas das boas práticas apresentadas aqui são as mesmas apresentadas

    no livro Microsserviços prontos para produção Boas práticas
  8. Um microsserviço considerado estável é aquele que durante o desenvolvimento,

    deploy, inclusão de novas tecnologias e desativação de outros serviços não resulta em instabilidade do ecossistemas de microsserviços que ele faz parte. Estabilidades
  9. Tem um ciclo de desenvolvimento padronizado (para se proteger de

    más práticas de desenvolvimento) Um microsserviço pode ser considerado estável e confiável quando
  10. O código é submetido a testes de unidade, integração, e2e,

    regras de coverage (o tanto que um teste é coberto por testes) etc. Um microsserviço pode ser considerado estável e confiável quando
  11. Possui seus clientes (serviços que o consomem) conhecidos. Um microsserviço

    pode ser considerado estável e confiável quando
  12. Nunca deve existir uma parte do ecossistema de microsserviços que

    uma falha pode parar todo o fluxo. Tolerância a falhas
  13. Também não deve haver qualquer parte individual dentro da arquitetura

    de um microsserviço que possa derrubar o microsserviço todo quando ele falhar. Tolerância a falhas
  14. Microsserviços devem suportar falhas internas (do próprio microsserviço) e falhas

    externas (que acontecem em outras camadas e serviços externos). Tolerância a falhas
  15. Ele é testado por meio de testes de carga e

    teste de caos. Um microsserviço pode ser considerado tolerante a falhas quando
  16. Existe um procedimento padrão para tratar incidentes dentro das equipes.

    Um microsserviço pode ser considerado tolerante a falhas quando
  17. É possível acompanhar o que está acontecendo e o que

    já aconteceu com os seus microsserviços Monitoramento
  18. Seu logging reflete com precisão os estados passados do microsserviço

    Um microsserviço pode ser considerado com um bom monitoramento quando
  19. Seus dashboards são fáceis de interpretar e possuem todas as

    métricas principais. Um microsserviço pode ser considerado com um bom monitoramento quando
  20. Os logs não contêm informações sensíveis e só informações relevantes.

    Um microsserviço pode ser considerado com um bom monitoramento quando
  21. As pessoas que entram na equipe desse serviço conseguem ter

    acesso a esse histórico de informações, sabe como preparar o ambiente, desenho da arquitetura, dentre outras informações essenciais para que possa iniciar o desenvolvimento? Uma equipe que quiser saber desse microsserviço vai conseguir entender o papel dele somente com a documentação? Documentação
  22. Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente

    Um microsserviço pode ser considerado bem documentado quando a documentação
  23. Contém um diagrama de arquitetura Contatos das pessoas responsáveis Guia

    de bordo de desenvolvimento Collections Faq Um microsserviço pode ser considerado bem documentado quando a documentação
  24. Qual o papel dele/em que parte esse microsserviço entra dentro

    daquele ecossistema. Todas as pessoas da equipe devem saber do conteúdo e pessoas de fora devem compreender. Um microsserviço pode ser considerado bem documentado quando a documentação
  25. Algumas regras básicas quando falamos de segurança de aplicações /

    microsserviços: - Usar autenticação via jwt com tempo de expiração curto Segurança
  26. - Realizar hash/encriptação de dados sensiveis e senhas - não

    trafegar dados sensíveis em logs - Fazer uso de APIs gateways Segurança
  27. - Separar tokens de aplicação e token de usuário -

    Conceder somente os acessos/permissões necessários - Matenha suas dependências atualizadas Segurança
  28. - Utilize ferramentas de SAST(Static application security testing ): analisa

    o código fonte em busca de vulnerabilidades e DAST (Dynamic application security testing): identificar possíveis vulnerabilidades em um aplicativo em execução. Segurança
  29. Você tem uma aplicação que acabou crescendo demais e precisa

    separa-la em partes menores, pontos a serem considerados: Decompose by business capability
  30. Com o tempo as aplicações vão crescendo , o código

    vai ficando mais confuso e ainda vamos evoluindo tecnicamente e pensamos em soluções e implementações melhores do que as anteriores. Para isso, também existem os padrões de refatorações de microsserviços Padrões de refatoração
  31. Em sistemas distribuids é muito importante garantir a consistência dos

    dados, que estejam com os valores corretos e que nenhum dado se perca entre os sitemas. Padrões de gerenciamento de dados
  32. Problema: como implementar consultas em uma arquitetura de microsserviços? Solução:

    implemente uma consulta definindo um API consumer, que invoca os serviços que possuem os dados e executa uma junção na memória dos resultados. API composition
  33. Problema: como implementar uma consulta que recupera dados de vários

    serviços em uma arquitetura de microsserviços? Solução: defina um banco de dados de somente leitura, que é uma replica do "oficial" somente para consulta, a aplicação manterá essa replica atualizada por meio de eventos CQRS
  34. Problema: como os clientes de uma aplicação baseados em microsserviços

    acessem os serviços individuais. Solução: implemente um API Gateway que seja o único ponto de entrada para todos os clientes APIS EXTERNAS