Microsserviços

Termo Micro-Webservices citado em 2005

Nascimento do termo microsserviço em 2011

Começou ser utilizado na Netflix e na Amazon

Aplicação como uma suíte de serviços, cada um rodando em seu próprio processo

Comunicação através de mecanismos leves como HTTP/Rest

Divisão das responsabilidades de uma aplicação

Melhor modularização

Componentização com serviços

Escalabilidade mais precisa

Interoperabilidade

Facilitar implantação

Divisão correta dos serviços

Desenvolvimento de serviços distribuídos

Estado, consistência e confiabilidade da rede requerem novas hipóteses

Desafios operacionais

Necessidade de mais velocidade para implantar novas versões

Menor preocupação com a infraestrutura

Migração de sistemas de AppServer para o Cloud

Monolítico: unidade de implantação única:

Os serviços SOA são implantados como monolitos

A lógica de negócio está concentrada no meio de comunicação

Decomposição

Implantação

Configuração

Comunicação

Dados

Monitoramento

Como dividir um sistema em microsserviços?

Alguns serviços podem ser divididos porque crescem

Serviços podem ser reagrupados pois estão mais ligados que previsto

Novos sub-assuntos podem ser descobertos

Serviços em um ou mais VMs

Containerização

Plataforma aplicativa (Cattle, Kubernetes)

Frameworks aplicativos

Service Mesh

Minimizar o desafio de entregar rapidamente

Developers + Operators (+ Profissionais de Segurança)

Unificação da Cadeia de Produção

Manifestação automatizada do processo de entrega

Colaboração entre as áreas envolvidas no pipeline

Automação do Processo = Retorno rápido

Configuração externalizada

Configuração centralizada

Suporte Versionamento

Service Registry and Discovery

API gateway

Circuit Breaker

Integração por transações

Os serviços precisam se localizar para executar comandos remotos

Esse registro deve ser dinâmico

Client-side discovery (Eureka Client)

Platform-provided Service Discovery (DNS + Routing)

Configuração de CORS

Conhecimento de muitos detalhes, endereços

Gestão de segurança “espalhada”

Ponto de contato único

Gestão centralizada da autenticação

Não precisa de CORS

Pattern implementado: Fachada

Integração com SSO + Geração de Token JWT

Pode ter um gateway por tipo de cliente (Pattern: Backend for Frontend)

Pode ser utilizado para implementar o Strangler Application Pattern

Resiliência e Tolerância a falhas

Também Client-Side e na Plataforma

Proteção com as falhas em cascata

Abre o circuito em caso de falha = tira componente com defeito

Fecha o circuito de volta depois de um intervalo

Uso de Fallbacks em caso de falha

Único serviço: 22 min. de downtime/mês

30 serviços: 11 horas de downtime/mês

100 serviços: 36 horas de downtime/mês (ouch!)

CDC (Change Data Capture)

Transaction Log

Kafka Connect

Database por serviço

API Composition

Saga

CQRS

Event sourcing

Permite juntar dados oriundos de vários serviços

Efetua pesquisas em vários serviços para juntar os dados

Exemplo: query para retornar dados básicos de um processo com pessoas envolvidas e pagamentos efetuados

Ponto importante: quem atua como API Composer?

Permite resolver o problema de consistência dos dados

Evita o uso de transação distribuída

Usa compensação de transação para Rollback

Separa a lógica de recuperação e de modificação dos dados

Mantém uma View somente leitura dos dados

Resolve os problemas de performance da API Composition

Eventos como fonte de verdade

O estado é uma agregação de eventos

Histórico agregado

Arquitetura Lambda

Agregação de Logs

Métricas da Aplicação

Auditoria

Tracing Distribuído

API Health check