Tweet
Tweet

Slide 1

Slide 1 text

Microsserviços: conceitos, boas práticas e padrões Kamila Santos

Slide 2

Slide 2 text

Nesta palestra Boas práticas de se adotar em microsserviços O que são microsserviços? Características de microsserviços 1 3 2

Slide 3

Slide 3 text

Nesta palestra Vamos ao código! Padrões de microsserviços Spring Cloud 4 6 5

Slide 4

Slide 4 text

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?

Slide 5

Slide 5 text

Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado sem interferir em outros serviços. Características dos microsserviços

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Reutilização de código - A divisão em módulos com responsabilidades bem definidas permite que funções específicas de algum serviço possam ser utilizadas para complementar features em outros sem precisar reescrever o código. Características dos microsserviços

Slide 10

Slide 10 text

As características apresentadas aqui são as mesmas apresentadas no livro Microsserviços prontos para produção Boas práticas de se adotar em microsserviços

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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. Estabilidade

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Possui seus clientes (serviços que o consomem) conhecidos. Um microsserviço pode ser considerado estável e confiável quando

Slide 17

Slide 17 text

Nunca deve existir uma parte do ecossistema de microsserviços que uma falha pode parar todo o fluxo. Tolerância a falhas

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Ele é testado por meio de testes de carga e teste de caos. Um microsserviço pode ser considerado tolerante a falhas quando

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Seu logging reflete com precisão os estados passados do microsserviço Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Possui bons alertas Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

As pessoas responsáveis pelo microsserviço estão bem definidas? Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente Um microsserviço pode ser considerado bem documentado quando a documentação

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Alguns dos principais padrões apresentados por Chris Richardson no site Microsservices.io Padrões de microsserviços

Slide 34

Slide 34 text

Monolítica - arquitetar um aplicativo como uma única unidade implantável Padrões de arquitetura

Slide 35

Slide 35 text

https://microservices.io/patterns/monolithic.html

Slide 36

Slide 36 text

Microsserviços - arquitetar um aplicativo como uma coleção de serviços fracamente acoplados Padrões de arquitetura

Slide 37

Slide 37 text

https://microservices.io/patterns/microservices.html

Slide 38

Slide 38 text

Strangler Patterns - cria uma nova aplicação em torno do monolito legado, fazendo as funções do antigo monolito e adicionando novas, agregando mais valor ao novo serviço Padrões de refatoração

Slide 39

Slide 39 text

https://microservices.io/patterns/refactoring/strangler-application.html

Slide 40

Slide 40 text

AntiCorruption Layers - cria uma camada de anticorrupção que se traduz entre os modelos de domínio (do monolito que foi herdado e do microsserviço novo que está sendo desenvolvido) Padrões de refatoração

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Database per Service - cada serviço tem seu próprio banco de dados privado Padrões de gerenciamento de dados

Slide 43

Slide 43 text

https://microservices.io/patterns/data/database-per-service.html

Slide 44

Slide 44 text

Saga - trabalha com uma sequência de transações locais, para manter a consistência dos dados entre os serviços Padrões de gerenciamento de dados

Slide 45

Slide 45 text

https://microservices.io/patterns/data/database-per-service.html

Slide 46

Slide 46 text

Saga - Orquestração - um objeto orquestrador informa as aplicações participantes quais transações locais executar. Padrões de gerenciamento de dados

Slide 47

Slide 47 text

https://microservices.io/patterns/data/saga.html

Slide 48

Slide 48 text

Saga - Coreografia - decisões distribuídas , cada transação publica eventos que acionam transações locais em outros serviços. Padrões de gerenciamento de dados

Slide 49

Slide 49 text

https://microservices.io/patterns/data/saga.html

Slide 50

Slide 50 text

Api Composition - implementar consultas invocando os serviços que possuem os dados e realizando uma junção na memória Padrões de gerenciamento de dados

Slide 51

Slide 51 text

https://microservices.io/patterns/data/api-composition.html

Slide 52

Slide 52 text

CQRS - Define um banco de dados read-only, que é uma réplica somente leitura projetada para oferecer suporte a essa consulta. O aplicativo mantém a réplica atualizada por meio de eventos Padrões de gerenciamento de dados

Slide 53

Slide 53 text

https://microservices.io/patterns/data/cqrs.html

Slide 54

Slide 54 text

Domain Event - publica um evento sempre que os dados forem alterados Padrões de gerenciamento de dados

Slide 55

Slide 55 text

API Gateway - um serviço que fornece a cada cliente uma interface unificada para serviços, adicionando uma camada a mais de segurança, fazendo balanceamento de carga etc Padrões de APIs externas

Slide 56

Slide 56 text

https://microservices.io/patterns/apigateway.html

Slide 57

Slide 57 text

Backend-for-frontend - um gateway de API separado para cada tipo de cliente Padrões de APIs externas

Slide 58

Slide 58 text

https://microservices.io/patterns/apigateway.html

Slide 59

Slide 59 text

Spring possui uma grande variedade de projetos para os mais variados cenários e necessidades dentro de uma aplicação Spring Cloud

Slide 60

Slide 60 text

Facilita a criação de sistemas distribuídos que são cloud native https://spring.io/projects/spring-cloud Spring Cloud

Slide 61

Slide 61 text

Possibilita que microsserviços descubram facilmente a rota de outros serviços que precisem acessar, os mais conhecidos são Spring Cloud Consul e Spring Cloud Netflix Eureka Service Discovery

Slide 62

Slide 62 text

Tem o papel de ser um intermediário nas nossas requisições para outros serviços. Os mais conhecidos são o Zuul e o Spring Cloud Gateway Gateway

Slide 63

Slide 63 text

Permite armazenar configurações de modo centralizado, para isso temos o Spring Cloud Config Server Configuração centralizada - Config Server

Slide 64

Slide 64 text

Um modo simples de se comunicar com outras aplicações Open Feign

Slide 65

Slide 65 text

Controle sobre falhas e altas taxas de latência dentre os serviços, mais conhecido: Resilience4J Circuit Breaker

Slide 66

Slide 66 text

Inclui id único a cada requisição que entra na aplicação, o que facilita o rastreamento de requisições que passam por um grande fluxo dentro do serviço Sleuth

Slide 67

Slide 67 text

Vamos ao código!

Slide 68

Slide 68 text

Obrigada! https://www.linkedin.com/in/kamila-santos-oliv eira/ https://www.youtube.com/Kamilacode https://www.instagram.com/kamila_code/ https://beacons.page/kamila_code