Padrões de microsserviços: o que são? para que servem? e porque você deveria conhecer ?

Slide 1

Slide 1 text

O QUE SÃO? PARA QUE SERVEM? E PORQUE VOCÊ DEVERIA CONHECER ? Padrões de microsserviços Kamila Santos

Slide 2

Slide 2 text

Kamila Santos Tech Lead na Zup Innovation, microsoft mvp, co- autora dos livros Jornada Java e Jornada Microsserviços, co-organizadora da womakerscode, devsjavagirl e perifacode, e criadora de conteudo no youtube e instagram Kamila code

Slide 3

Slide 3 text

@kamila_code O QUE SÃO MICROSSERVIÇOS? 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.

Slide 4

Slide 4 text

@kamila_code CARACTERÍSTICAS DOS MICROSSERVIÇOS Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado sem interferir em outros serviços.

Slide 5

Slide 5 text

@kamila_code CARACTERÍSTICAS DOS MICROSSERVIÇOS 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.

Slide 6

Slide 6 text

@kamila_code CARACTERÍSTICAS DOS MICROSSERVIÇOS 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.

Slide 7

Slide 7 text

@kamila_code CARACTERÍSTICAS DOS MICROSSERVIÇOS 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.

Slide 8

Slide 8 text

@kamila_code BOAS PRÁTICAS As boas práticas apresentadas aqui são as mesmas apresentadas no livro Microsserviços prontos para produção

Slide 9

Slide 9 text

@kamila_code BOAS PRÁTICAS

Slide 10

Slide 10 text

@kamila_code ESTABILIDADE 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.

Slide 11

Slide 11 text

@kamila_code CONFIABLIDADE Um microsserviço confiável é aquele que outros microsserviços daquele ecossistema podem confiar.

Slide 12

Slide 12 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO ESTÁVEL E CONFIÁVEL QUANDO Tem um ciclo de desenvolvimento padronizado (para se proteger de más práticas de desenvolvimento)

Slide 13

Slide 13 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO ESTÁVEL E CONFIÁVEL QUANDO O código é submetido a testes de unidade, integração, e2e, regras de coverage (o tanto que um teste é coberto por testes) etc.

Slide 14

Slide 14 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO ESTÁVEL E CONFIÁVEL QUANDO Possui seus clientes (serviços que o consomem) conhecidos.

Slide 15

Slide 15 text

@kamila_code TOLERÂNCIA A FALHAS Nunca deve existir uma parte do ecossistema de microsserviços que uma falha pode parar todo o fluxo.

Slide 16

Slide 16 text

@kamila_code TOLERÂNCIA A FALHAS 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.

Slide 17

Slide 17 text

@kamila_code TOLERÂNCIA A FALHAS Microsserviços devem suportar falhas internas (do próprio microsserviço) e falhas externas (que acontecem em outras camadas e serviços externos).

Slide 18

Slide 18 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO TOLERANTE A FALHAS QUANDO Ele é testado por meio de testes de carga e teste de caos.

Slide 19

Slide 19 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO TOLERANTE A FALHAS QUANDO Existe um procedimento padrão para tratar incidentes dentro das equipes.

Slide 20

Slide 20 text

@kamila_code MONITORAMENTO É possível acompanhar o que está acontecendo e o que já aconteceu com os seus microsserviços

Slide 21

Slide 21 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO COM UM BOM MONITORAMENTO QUANDO Seu logging reflete com precisão os estados passados do microsserviço

Slide 22

Slide 22 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO COM UM BOM MONITORAMENTO QUANDO Seus dashboards são fáceis de interpretar e possuem todas as métricas principais.

Slide 23

Slide 23 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO COM UM BOM MONITORAMENTO QUANDO Possui bons alertas

Slide 24

Slide 24 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO COM UM BOM MONITORAMENTO QUANDO Os logs não contêm informações sensíveis e só informações relevantes.

Slide 25

Slide 25 text

@kamila_code DOCUMENTAÇÃO 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?

Slide 26

Slide 26 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO BEM DOCUMENTADO QUANDO A DOCUMENTAÇÃO Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente

Slide 27

Slide 27 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO BEM DOCUMENTADO QUANDO A DOCUMENTAÇÃO Contém um diagrama de arquitetura Contatos das pessoas responsáveis Guia de bordo de desenvolvimento Collections Faq

Slide 28

Slide 28 text

@kamila_code UM MICROSSERVIÇO PODE SER CONSIDERADO BEM DOCUMENTADO QUANDO A DOCUMENTAÇÃO 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.

Slide 29

Slide 29 text

@kamila_code ARQUITETURA MONOLÍTICA arquitetar um aplicativo como uma única unidade implantável, resolve casos em que você precisa desenvolver mais rápido, implantar mais rápido , dimensionar de modo mais simples e que a aplicação não tenha tantas responsabilidades diferentes para lidar

Slide 30

Slide 30 text

https://microservices.io/pattern s/monolithic.html

Slide 31

Slide 31 text

@kamila_code ARQUITETURA DE MICROSSERVIÇOS arquitetar um aplicativo como uma coleção de serviços fracamente acoplados, resolve o problema de quando temos várias responsabilidades na mesma aplicação, você precisa escalar algumas partes separadas, precisa usar tecnologias diferentes para problemas diferentes, quer separar as responsabilidades da aplicação.

Slide 32

Slide 32 text

https://microservices.io/pattern s/microservices.html

Slide 33

Slide 33 text

@kamila_code DECOMPOSE BY BUSINESS CAPABILITY Você tem uma aplicação que acabou crescendo demais e precisa separa-la em partes menores, pontos a serem considerados:

Slide 34

Slide 34 text

@kamila_code DECOMPOSE BY BUSINESS CAPABILITY - A arquitetura deve ser estável - Serviços devem ser coesos - Serviços devem ser fracamente acoplados - Os serviços devem ser testáveis

Slide 35

Slide 35 text

https://microservices.io/pattern s/decomposition/decompose- by-business-capability.html

Slide 36

Slide 36 text

@kamila_code DECOMPOSE BY SUBDOMAIN Problema bem semelhante ao anterior e também com solução bem semelhante também

Slide 37

Slide 37 text

https://microservices.io/pattern s/decomposition/decompose- by-subdomain.html

Slide 38

Slide 38 text

@kamila_code PADRÕES DE REFATORAÇÃO 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

Slide 39

Slide 39 text

@kamila_code STRANGLER APPLICATION Problema: Como podemos migrar um legado monolito para vários microsserviços? Solução: desenvolva uma nova aplicação em volta da anterior para "estrangular o monolito", uns serviços implementem as antigas funcionalidades e façam novas funcionalidades também

Slide 40

Slide 40 text

https://microservices.io/pattern s/refactoring/strangler- application.html

Slide 41

Slide 41 text

@kamila_code CAMADA DE ANTICORRUPÇÃO Problema: Precisamos evitar que o modelo de domínio de um monolito polua o modelo de domínio do novo serviço Solução: Defina uma camada de anticorrupção que se traduz entre os dois modelos de domínio

Slide 42

Slide 42 text

\https://docs.microsoft.com/pt- br/azure/architecture/patterns/ anti-corruption-layer

Slide 43

Slide 43 text

@kamila_code PADRÕES DE GERENCIAMENTO DE DADOS Em sistemas distribuidas é muito importante garantir a consistência dos dados, que estejam com os valores corretos e que nenhum dado se perca entre os sitemas.

Slide 44

Slide 44 text

@kamila_code SAGA Problema: Como implementar transações que abrangem serviços ? Solução: Implementar cada transação que abrange vários serviços (saga -> sequência de transações locais).

Slide 45

Slide 45 text

@kamila_code SAGA Cada transação local atualizaroa o banco de dados e publicaria uma mensagem ou evento para acionar a próxima transação local na saga. Caso uma transação local falhe a saga vai executar uma série de transações para desfazer as alterações feitas pelas transações locais anteriores.

Slide 46

Slide 46 text

\https://docs.microsoft.com/pt- br/azure/architecture/patterns/ anti-corruption-layer

Slide 47

Slide 47 text

@kamila_code SAGA - COREOGRAFIA decisões distribuídas , cada transação publica eventos que acionam transações locais em outros serviços.

Slide 48

Slide 48 text

\https://docs.microsoft.com/pt- br/azure/architecture/patterns/ anti-corruption-layer

Slide 49

Slide 49 text

@kamila_code SAGA - ORQUESTRAÇÃO um objeto orquestrador informa as aplicações participantes quais transações locais executar.

Slide 50

Slide 50 text

https://microservices.io/pattern s/data/saga.html

Slide 51

Slide 51 text

@kamila_code API COMPOSITION 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.

Slide 52

Slide 52 text

https://microservices.io/pattern s/data/api-composition.html

Slide 53

Slide 53 text

CQRS 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

Slide 54

Slide 54 text

https://microservices.io/pattern s/data/api-composition.html

Slide 55

Slide 55 text

@kamila_code APIS EXTERNAS 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

Slide 56

Slide 56 text

https://microservices.io/pattern s/data/api-composition.html

Slide 57

Slide 57 text

https://microservices.io/pattern s/apigateway.html

Slide 58

Slide 58 text

@kamila_code OBSERVABILIDADE Depois que nosso microsserviço esta no ar, é muito importante conseguir entender o que está acontecendo com ele , quando acontece e onde acontece

Slide 59

Slide 59 text

AGREGAÇÃO DE LOGS Problema: Como entender o comportamento de um aplicativo e solucionar problemas? Solução: Usar uma solução de log centralizado de cada instância do serviço, as pessoas usuárias podem pesquisar , analisar e configurar alertas ex: cloud watch, datadog, new relic...

Slide 60

Slide 60 text

@kamila_code DISTRIBUTED TRACING Problema: Como entender o comportamento de um aplicativo e solucionar problemas? Solução: Usar serviços como o sleuth que atribuem um id unico para cada requisição e passa esse id em todos os logs dessa requisição

Slide 61

Slide 61 text

@kamila_code COMUNICAÇÃO Nenhum microsserviço existe sozinho, ele precisa se comunicar com outras aplicações e serviços

Slide 62

Slide 62 text

@kamila_code REMOTE PROCEDURE INVOCATION (RPI) Problema: como os microsserviços podem se comunicar de forma síncrona Solução: realize a comunicação utilizando REST ou GRPC

Slide 63

Slide 63 text

@kamila_code MENSAGERIA Problema: como os microsserviços podem se comunicar de forma assíncrona Solução: utilize serviços como Apache Kafka, Rabit Mq ou SQS

Slide 64

Slide 64 text

OBRIGADA :) https://www.linkedin.com/in/kamila-santos-oliveira/ https://www.youtube.com/Kamilacode https://www.instagram.com/kamila_code/ https://beacons.page/kamila_code