SlideShare uma empresa Scribd logo
Do 0 ao 100 em
Microsserviços
Tudo que você precisa saber para se
tornar um especialista no assunto
#DEEPTECHCONFBR2021
Patrocínio:
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
Design
(Decomposição) 01
Contexto
Separação de microservices baseado
em domínios da aplicação, seguindo a
técnica de DDD.
Domínio/Subdomínio
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
Separação de microservices baseado
em segmentação de time, geralmente
é combinada com capacidade de
técnica e de negócio.
Time
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
Gestão de
dados
02
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
Um cenário muito comum, é manter um
banco de dados compartilhado entre
diversos microsserviços.
Banco de dados compartilhado
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.
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.
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.
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.
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.
Orquestração
Um orquestrador (objeto) diz aos participantes quais transações locais executar.
Transactional outbox (Message Relay)
Um processo de Message Relay separado para publicação dos eventos inseridos no banco de dados para o broker.
Coreografia
Cada transação local publica eventos de domínio que acionam transações locais em outros
serviços.
Service
Discovery
03
Problema
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.
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.
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.
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.
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.
Tipos de
comunicação
04
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.
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
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.
Padrões de
Resiliência
05
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
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.
Deployment 06
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.
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.
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%.
Monitoramento
e Observability
07
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
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.
Audit Logging
Armazenamento de todas as atividades
de usuários em um serviço centralizado
de logs de auditoria.
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
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
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
Log deployments and changes
Armazenamento de todos os
deploys e mudanças no
ambiente de produção em
um serviço centralizado.
Azure DevOps
Migrando de
monolito para
microservices
08
Strangler pattern
O Strangler pattern é uma estratégia inteligente de migração de uma arquitetura legada para uma arquitetura mais
moderna de forma incremental.
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.
OBRIGADO!
Tem alguma dúvida?
thiago.lima@linkapi.com.br
www.thiagolima.blog.br
instagram.com/thiago.limabr
linkedin.com/in/thiagolimabr

Mais conteúdo relacionado

Mais procurados

PacNOG 31: Internet Exchange Points
PacNOG 31: Internet Exchange PointsPacNOG 31: Internet Exchange Points
PacNOG 31: Internet Exchange PointsAPNIC
 
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來Shengyou Fan
 
Ccnp workbook network bulls
Ccnp workbook network bullsCcnp workbook network bulls
Ccnp workbook network bullsSwapnil Kapate
 
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...Neo4j
 
Getting Ready to Use Redis with Apache Spark with Dvir Volk
Getting Ready to Use Redis with Apache Spark with Dvir VolkGetting Ready to Use Redis with Apache Spark with Dvir Volk
Getting Ready to Use Redis with Apache Spark with Dvir VolkSpark Summit
 
Integração do Zabbix com Testes Automatizados
Integração do Zabbix com Testes AutomatizadosIntegração do Zabbix com Testes Automatizados
Integração do Zabbix com Testes AutomatizadosRobert Silva
 
Graphs in Telecommunications - Jesus Barrasa, Neo4j
Graphs in Telecommunications - Jesus Barrasa, Neo4jGraphs in Telecommunications - Jesus Barrasa, Neo4j
Graphs in Telecommunications - Jesus Barrasa, Neo4jNeo4j
 
VRRP (virtual router redundancy protocol)
VRRP (virtual router redundancy protocol)VRRP (virtual router redundancy protocol)
VRRP (virtual router redundancy protocol)Netwax Lab
 
Load Sharing Internet with MikroTik.pdf
Load Sharing Internet with MikroTik.pdfLoad Sharing Internet with MikroTik.pdf
Load Sharing Internet with MikroTik.pdfEnics
 
BGP Advance Technique by Steven & James
BGP Advance Technique by Steven & JamesBGP Advance Technique by Steven & James
BGP Advance Technique by Steven & JamesFebrian ‎
 
Effective Classification of Clinical Reports: Natural Language Processing-Bas...
Effective Classification of Clinical Reports: Natural Language Processing-Bas...Effective Classification of Clinical Reports: Natural Language Processing-Bas...
Effective Classification of Clinical Reports: Natural Language Processing-Bas...Efsun Kayi
 
Troubleshooting BGP
Troubleshooting BGPTroubleshooting BGP
Troubleshooting BGPDuane Bodle
 
Arquitectura de software y otros demonios
Arquitectura de software y otros demoniosArquitectura de software y otros demonios
Arquitectura de software y otros demoniosAndrés Londoño
 

Mais procurados (20)

PacNOG 31: Internet Exchange Points
PacNOG 31: Internet Exchange PointsPacNOG 31: Internet Exchange Points
PacNOG 31: Internet Exchange Points
 
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來
[Modern Web 2016] 讓你的 PHP 開發流程再次潮起來
 
Ccnp workbook network bulls
Ccnp workbook network bullsCcnp workbook network bulls
Ccnp workbook network bulls
 
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...
Training Series - Build A Routing Web Application With OpenStreetMap, Neo4j, ...
 
Getting Ready to Use Redis with Apache Spark with Dvir Volk
Getting Ready to Use Redis with Apache Spark with Dvir VolkGetting Ready to Use Redis with Apache Spark with Dvir Volk
Getting Ready to Use Redis with Apache Spark with Dvir Volk
 
Integração do Zabbix com Testes Automatizados
Integração do Zabbix com Testes AutomatizadosIntegração do Zabbix com Testes Automatizados
Integração do Zabbix com Testes Automatizados
 
CCNP ROUTE V7 CH4
CCNP ROUTE V7 CH4CCNP ROUTE V7 CH4
CCNP ROUTE V7 CH4
 
Bgp (1)
Bgp (1)Bgp (1)
Bgp (1)
 
Graphs in Telecommunications - Jesus Barrasa, Neo4j
Graphs in Telecommunications - Jesus Barrasa, Neo4jGraphs in Telecommunications - Jesus Barrasa, Neo4j
Graphs in Telecommunications - Jesus Barrasa, Neo4j
 
VRRP (virtual router redundancy protocol)
VRRP (virtual router redundancy protocol)VRRP (virtual router redundancy protocol)
VRRP (virtual router redundancy protocol)
 
Load Sharing Internet with MikroTik.pdf
Load Sharing Internet with MikroTik.pdfLoad Sharing Internet with MikroTik.pdf
Load Sharing Internet with MikroTik.pdf
 
BGP Advance Technique by Steven & James
BGP Advance Technique by Steven & JamesBGP Advance Technique by Steven & James
BGP Advance Technique by Steven & James
 
Effective Classification of Clinical Reports: Natural Language Processing-Bas...
Effective Classification of Clinical Reports: Natural Language Processing-Bas...Effective Classification of Clinical Reports: Natural Language Processing-Bas...
Effective Classification of Clinical Reports: Natural Language Processing-Bas...
 
Bgp tutorial for ISP
Bgp tutorial for ISPBgp tutorial for ISP
Bgp tutorial for ISP
 
ACI Hands-on Lab
ACI Hands-on LabACI Hands-on Lab
ACI Hands-on Lab
 
Troubleshooting BGP
Troubleshooting BGPTroubleshooting BGP
Troubleshooting BGP
 
Zabbix conference 2018v2
Zabbix conference 2018v2Zabbix conference 2018v2
Zabbix conference 2018v2
 
Arquitectura de software y otros demonios
Arquitectura de software y otros demoniosArquitectura de software y otros demonios
Arquitectura de software y otros demonios
 
The Computing Continuum.pdf
The Computing Continuum.pdfThe Computing Continuum.pdf
The Computing Continuum.pdf
 
EVPN for Cloud Builders
EVPN for Cloud BuildersEVPN for Cloud Builders
EVPN for Cloud Builders
 

Semelhante a [DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices

Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Renato Groff
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoLuiz Costa
 
Microservices com Spring Boot e Spring Cloud Netflix
Microservices com Spring Boot e Spring Cloud NetflixMicroservices com Spring Boot e Spring Cloud Netflix
Microservices com Spring Boot e Spring Cloud NetflixNatanael Fonseca
 
O desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicosO desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicosGraziella Bonizi
 
Transformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualizaçãoTransformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualizaçãoDarlan Segalin
 
Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015Renato Groff
 
Microservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendMicroservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendRenato Groff
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Renato Groff
 
Azure Functions e Logic Apps
Azure Functions e Logic AppsAzure Functions e Logic Apps
Azure Functions e Logic AppsResource IT
 
9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stvwilson_lucas
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecturerenanwb
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlabJackson F. de A. Mafra
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidorMarcia Abrahim
 
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha MicroservicesTDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservicestdc-globalcode
 
Introdução ao 12 Factors APP
Introdução ao 12 Factors APPIntrodução ao 12 Factors APP
Introdução ao 12 Factors APPDouglas Alonso
 

Semelhante a [DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices (20)

Architecture performance using micro services
Architecture performance using micro servicesArchitecture performance using micro services
Architecture performance using micro services
 
Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
 
Microservices com Spring Boot e Spring Cloud Netflix
Microservices com Spring Boot e Spring Cloud NetflixMicroservices com Spring Boot e Spring Cloud Netflix
Microservices com Spring Boot e Spring Cloud Netflix
 
O desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicosO desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicos
 
Microservices
MicroservicesMicroservices
Microservices
 
Transformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualizaçãoTransformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualização
 
Microservices
MicroservicesMicroservices
Microservices
 
Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015Microservices - ALM Roadshow 2015
Microservices - ALM Roadshow 2015
 
Microservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendMicroservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev Weekend
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
 
Azure Functions e Logic Apps
Azure Functions e Logic AppsAzure Functions e Logic Apps
Azure Functions e Logic Apps
 
9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv9.cloud computing v3.1_wl_stv
9.cloud computing v3.1_wl_stv
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlab
 
Microservices
MicroservicesMicroservices
Microservices
 
Arquitetura cliente servidor
Arquitetura cliente servidorArquitetura cliente servidor
Arquitetura cliente servidor
 
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha MicroservicesTDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservices
 
Introdução ao 12 Factors APP
Introdução ao 12 Factors APPIntrodução ao 12 Factors APP
Introdução ao 12 Factors APP
 
World Wide Web
World Wide WebWorld Wide Web
World Wide Web
 

[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices

  • 1. Do 0 ao 100 em Microsserviços Tudo que você precisa saber para se tornar um especialista no assunto #DEEPTECHCONFBR2021
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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%.
  • 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
  • 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.