Thiago Lima é um empreendedor e especialista em tecnologia com mais de 30 anos de experiência desenvolvendo e liderando equipes de tecnologia. Ele falará sobre microsserviços, desde a decomposição de sistemas até práticas de monitoramento e resiliência.

1. Do 0 ao 100 em
Microsserviços
Tudo que você precisa saber para se
tornar um especialista no assunto
#DEEPTECHCONFBR2021

2. Patrocínio:

3. Thiago Lima, 30 anos, empreendedor entusiasta da tecnologia. Começou como
desenvolvedor de software aos 12 anos, fundando e liderando 3 empresas de
tecnologia de sucesso.
Como CTO, arquiteto e desenvolvedor, ele tem trabalhado em ambientes de
arquitetura enterprise com muitas tecnologias diferentes, como .NET, Java, NodeJS,
Python e Golang.
Destaques:
- Experiência na liderança de grandes equipes de tecnologia (> 700 desenvolvedores)
- Speaker na comunidade de tecnologia (> 50 mil seguidores nas redes sociais)
- Palestrante em eventos globais de tecnologia
- Board Member de empresas Enterprise (bilhões de receita)
- Acredita na liderança hands-on
Thiago Lima
CTO Semantix

4. Design
(Decomposição) 01

5. Contexto

6. Separação de microservices baseado
em domínios da aplicação, seguindo a
técnica de DDD.
Domínio/Subdomínio

7. Separação de microservices baseado em
funcionalidades de um produto ou
capacidades de negócio, geralmente
correspondem a um nível acima de objetos de
domínio.
Capacidade de negócio

8. Separação de microservices baseado
em segmentação de time, geralmente
é combinada com capacidade de
técnica e de negócio.
Time

9. Serviço totalmente autônomo a
ponto de que ele consiga responder a
uma requisição síncrona sem esperar
pela resposta de qualquer outro
serviço.
Esse tipo de serviço é desenvolvido
com base em agregação de outros
microservices, réplicas de CQRS ou
transações SAGA.
Serviço Autônomo

10. Gestão de
dados
02

11. Como o próprio nome diz,
nesse cenário, cada serviço tem
o seu próprio banco de dados.
Banco de dados por serviço

12. Um cenário muito comum, é manter um
banco de dados compartilhado entre
diversos microsserviços.
Banco de dados compartilhado

13. API composition
Um API Composer funciona como um
invocador dos serviços que possuem os
dados e executa uma junção dos resultados
na memória.

14. CQRS(Command Query Responsibility Segregation)
CQRS é uma técnica onde você usa uma
réplica readonly projetada para oferecer
suporte a queries em diversos microservices.
Nesse caso, a réplica dos dados é atualizada
através da assinatura de eventos de
domínios publicados pelos serviços que
possuem os dados originais.

15. Event sourcing
Event sourcing é uma estratégia de persistência de estado dos dados utilizada em arquiteturas baseadas em eventos. Isso permite que sua
aplicação consiga reconstruir o estado atual de uma entidade apenas reproduzindo os eventos. Além disso, nessa estratégia você fornece uma
API que permite que todos os outros microservices se inscrevam e acompanhem os eventos.

16. Domain event
Domain event é complementar ao event
sourcing. Ele é um pattern que usa como
base o DDD (domain driven design), e que
serve para descrever eventos para
comunicação entre microservices.
Ele é bem útil para disparar gatilhos em
outros microservices, e popular dados na
estratégia de CQRS.

17. Transações distribuídas
O padrão saga é uma maneira de gerenciar a consistência de dados
em microsserviços em cenários de transações distribuídas. Um saga é
uma sequência de transações que atualiza cada serviço e publica uma
mensagem ou um evento para disparar a próxima etapa da transação.
Se uma etapa falhar, o saga executará transações de compensação que
neutralizam as transações anteriores.
Existem dois métodos de se trabalhar com SAGA: orquestração e
coreografia.

18. Orquestração
Um orquestrador (objeto) diz aos participantes quais transações locais executar.

19. Transactional outbox (Message Relay)
Um processo de Message Relay separado para publicação dos eventos inseridos no banco de dados para o broker.

20. Coreografia
Cada transação local publica eventos de domínio que acionam transações locais em outros
serviços.

21. Service
Discovery
03

22. Problema

23. Service Registry
Mecanismo que permite que os clients dos serviços façam requisições no lugar certo mesmo com toda a
dinâmica existente em uma arquitetura de microservices baseada em containers.
Em outras palavras, um mecanismo que centraliza as informações de localização dos serviços na rede.
Com isso, ele soluciona questões importantes como:
● Possibilidade do endereço físico (e até mesmo DNS) do seu serviço variar sem afetar o código de quem
depende dele.
● Healthcheck, pois se os serviços desconectarem do service registry você receberá essa informação.
● Facilidade no load balancing, pois o service registry pode assumir essa função na sua arquitetura.
As ferramentas mais famosas são Eureka, Consul, e Zookeeper.
Alguns sistemas como: Kubernetes, Marathon e AWS ELB já possuem service registry implementado.

24. Client-side service discovery
O client fica responsável por fazer uma requisição no
server para obter as localizações das instâncias no
Service Registry.

25. Server-side service discovery
Quando o client faz uma requisição, essa
requisição cai diretamente para um router
(load balancer). O router consulta o Service
Registry (Geralmente embarcado no router), e
com isso, ele encaminha a solicitação para uma
instância de serviço disponível.

26. Self-registration
Para criar dinamismo no processo de registro
das instâncias, e muito comum fazer o próprio
serviço se auto registrar no Service Registry.

27. 3rd party registration
Uma alternativa para manter o dinamismo, mas não criar acoplamento entre os serviços e o service registry, é utilizar
3rd party. Exemplos: Netflix Prana, Registrator.

28. Tipos de
comunicação
04

29. Síncrona (comunicação interna)
O client envia uma requisição e espera uma resposta do serviço. Nesse caso a thread só é desbloqueada após a resposta do
serviço. HTTP e gRPC são os protocolos mais utilizados nesse tipo de comunicação.

30. Assíncrona (comunicação interna)
O client envia uma requisição e não precisa
aguardar uma resposta para continuar, ou
seja, a thread fica desbloqueada enquanto o
server processa a resposta.
Publish/Subscribe
Async one to one

31. API Gateway (comunicação externa)
Um API Gateway permite que você centralize todas as
entradas de requisições.
Nesse caso, qualquer requisição de um client que esteja
fora da sua rede de microservices via Gateway, que por
sua vez, fará a requisição e orquestração dessa
requisição ao microservice.
Isso permite deixar seus microservices acessíveis
somente pela sua rede interna.
Como fica apenas um ponto de acesso, isso facilita a
gestão de segurança, performance, políticas, etc.

32. Padrões de
Resiliência
05

33. Circuit Breaker
O pattern circuit breaker funciona como um proxy para
operações que podem falhar. O proxy deve monitorar o
número de falhas recentes que ocorreram e usar essas
informações para decidir se permite que a operação
prossiga ou apenas retorna uma exceção
imediatamente.
Frameworks famosos:
Hystrix -> Resilience4j - Java
PyBreaker - Python
Polly - .NET
Opossum e Brakes - Node

34. Bulkhead
Bulkhead é uma técnica usada para resiliência e
funciona a partir do isolamento em pools de
microservices críticos para o funcionamento da
arquitetura.
Com esse isolamento, sua arquitetura continua
funcionando, mesmo que algum serviço não
esteja disponível, ou respondendo a requisição
com alta latência.

35. Deployment 06

36. Rolling
Estratégia de deploy mais simples e por isso a mais
utilizada. Consiste em subir a nova versão do
microservice substituindo a versão antiga.
Nesse caso, a versão antiga só ficará indisponível
quando a nova versão estiver pronta para ser executada,
ou seja, no decorrer do deploy teremos N+1 instâncias do
mesmo serviço sendo executada.

37. Bluegreen
No deploy blue-green há dois ambientes idênticos na
infraestrutura, sendo um deles o mirror. Então você sobe
a nova versão para um dos ambientes, e nesse sentido,
você pode testar o novo ambiente com o antigo ainda
funcionando através de um load balancer.
Se todos os testes estiverem corretos, então você pode
fazer o redirecionamento do load balancer para o seu
novo ambiente.

38. Canary
O deploy Canary funciona parecido com o Bluegreen, ou
seja, com dois ambientes, e um deles, sendo o Mirror.
Entretanto a diferença é que você coloca uma nova
versão em produção, mas libera o tráfego dessa versão
apenas para um pequeno grupo de usuários.
Sendo assim, os outros usuários continuam utilizando
normalmente a versão anterior.
Assim que todos os seus experimentos funcionarem na
nova versão, então você poderá virar a chave 100%.

39. Monitoramento
e Observability
07

40. Log Aggregation
Armazenamento de todos os registros de operações de cada microservice em um serviço centralizado de logs. Os
usuários geralmente tem a possibilidade de pesquisar e analisar os logs, além de configurar alertas que são acionados
quando certas mensagens aparecem nos logs.
Fluentd

41. Application Metrics
Criação de um serviço que agrega métricas
das operações individuais de cada
microservice. Por exemplo: imagine que seu
microservice serve para criação de contas
bancárias, uma métrica interessante pode ser
quantas contas bancárias foram criadas com
sucesso na última hora. Isso permite criar
relatórios e alertas inteligentes para times de
desenvolvimento, além de serem úteis no
diagnóstico e antecipação de problemas.
Exemplo: Grafana com prometheus.

42. Audit Logging
Armazenamento de todas as atividades
de usuários em um serviço centralizado
de logs de auditoria.

43. Distributed Tracking
Enquanto os logs servem para armazenar checkpoints relevantes de uma requisição, o trace conecta todos esses
checkpoints em uma jornada única, além de mostrar do início ao fim como essa requisição foi tratada entre todos os
microservices.
Jaeger

44. Exception Tracking
Armazenamento de todas as exceções em
um serviço centralizado de tracking, com
o objetivo de agregar e rastrear exceções,
e notificar os desenvolvedores.
Sentry

45. Health Check API
Cada microservice tem um endpoint de health check
na sua API (por exemplo, HTTP /health), no qual,
retorna a integridade do serviço.
O endpoint da API pode executar várias checagens,
como: status das conexões com os serviços de
infraestrutura usados pela instância de serviço, status
do host (e.g: memória), algo específico da aplicação, e
por aí vai.
Para funcionar, é importante ter um client, que pode
ser um serviço de monitoramento, por exemplo, que
fica responsável por fazer requisições periodicamente
ao endpoint.
Consul

46. Log deployments and changes
Armazenamento de todos os
deploys e mudanças no
ambiente de produção em
um serviço centralizado.
Azure DevOps

47. Migrando de
monolito para
microservices
08

48. Strangler pattern
O Strangler pattern é uma estratégia inteligente de migração de uma arquitetura legada para uma arquitetura mais
moderna de forma incremental.

49. Anti-corruption layer
Implementação de uma camada (adapter) entre diferentes serviços que não compartilham a mesma semântica.
Essa camada tem o objetivo de mover solicitações feitas de um serviço para outro.

50. OBRIGADO!
Tem alguma dúvida?
thiago.lima@linkapi.com.br
www.thiagolima.blog.br
instagram.com/thiago.limabr
linkedin.com/in/thiagolimabr