Share
Embed
Decisões arquiteturais para micro serviços: tradeoffs, granularidade e fronteiras
Explore os trade-offs inerentes à decisões arquiteturais cruciais na construção de sistemas baseados em microserviços, descubra a importância da granularidade adequada e aprenda a estabelecer fronteiras sólidas. Esta palestra procura oferecer insights para pessoas arquitetas e desenvolvedoras que desejam criar sistemas robustos e eficientes.
Palestra apresentada no TDC de Porto Alegre de 12/2023
Jessilyneh
December 05, 2023
Transcript
39 slides
-
A ARQUITETURA DE SOFTWARE COMPREENDE NÃO APENAS A ESTRUTURA CENTRAL
DE UM SISTEMA, MAS TAMBÉM DECISÕES ESSENCIAIS DE DESIGN. Software Architecture Knowledge Management: Theory and Practice -
Conceito vindo do artigo “The Mindset for Architectural Decisions” O
Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Aspectos de uma decisão que podemos considerar para avaliar rapidamente a sua importância -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
O Papel das Decisões Arquiteturais - PRILER checklist @jessilyneh Prioridade
e Valor Reversibilidade Impacto (escopo/efeito) Limitações e Restrições Esforço (custo, recursos) Risco -
Decision Record (DR) @jessilyneh Iniciar, debater e arquivar uma escolha
importante, com seu contexto e consequências. Um registro de decisão (DL) Uma decisão Um requisito significativo (SR) -
FOCO NA ANÁLISE DE CENÁRIO NÃO PREPARA PARA A EROSÃO
DA ARQUITETURA, ENQUANTO O FOCAR APENAS NAS MÉTRICAS DE CÓDIGO NO NÍVEL DA ARQUITETURA SERIA NEGLIGENCIAR REQUISITOS E TECNOLOGIAS EM MUDANÇA. Measuring Architecture Sustainability - Heiko Koziolek, Dominik Domis, Thomas Goldschmidt, Philipp Vorst -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Limites de
módulo: definir os limites de cada serviço pode ser um desafio, e acertá-los é crucial para o desempenho do sistema Conway's Law - as arquiteturas dos sistemas são semelhantes à organização da equipe de desenvolvimento que os construiu -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Distribuição: Latência
de chamadas remotas, overhead de rede e custos operacionais Chamadas em processos(in-process) e chamadas remotas(remote calls) -
SISTEMAS DISTRIBUIDOS E MICROSSERVIÇOS A arquitetura de microsserviços é um
tipo de sistema distribuído, porém os dois conceitos não são intercambiáveis. -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Consistência eventual:
atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente. -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Consistência eventual:
atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente. Diversidade tecnológica: aplicações em tecnologias diversas, aumento de custo de manutenção. -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Consistência eventual:
atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente. Diversidade tecnológica: aplicações em tecnologias diversas, aumento de custo de manutenção. Segurança: Mais pontos de exploração para atacantes, gerenciamento de acessos, monitoramento e auditoria, atualizações constantes -
Trade-offs na divisão de sistemas em microsserviços @jessilyneh Consistência eventual:
atualização assíncrona, uso técnicas de sincronização ou compensação para atingir estado consistente. Diversidade tecnológica: aplicações em tecnologias diversas, aumento de custo de manutenção. Segurança: Mais pontos de exploração para atacantes, gerenciamento de acessos, monitoramento e auditoria, atualizações constantes Orquestração: Interação coordenada para funcionalidades completas, transações distribuidas, gestão de configuração -
Escolhendo a granularidade adequada @jessilyneh tamanho e complexidade de um
sistema microsserviço deve: refletir uma unidade de negócios ou um domínio coeso ser capaz de evoluir independentemente dos outros ter fácil comunicação considerar requisitos de desempenho, como responsividade e processamento de dados https://architecturenotes.co/granularity-of-systems/ -
@jessilyneh fronteiras determinam como a funcionalidade do sistema é dividida
entre os serviços individuais -
Estabelecendo fronteiras entre microserviços @jessilyneh Boundaries Context (contexto delimitado): conceito
fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos -
Estabelecendo fronteiras entre microserviços @jessilyneh Boundaries Context (contexto delimitado): conceito
fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos Responsabilidades: Uma parte limitada da lógica de negócios. -
Estabelecendo fronteiras entre microserviços @jessilyneh Boundaries Context (contexto delimitado): conceito
fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos Responsabilidades: Uma parte limitada da lógica de negócios. Limite de transações: Cuidado com casos de falhas, considere estratégias como consistência eventual -
Estabelecendo fronteiras entre microserviços @jessilyneh Boundaries Context (contexto delimitado): conceito
fundamental no DDD, que ajuda a dividir e organizar modelos de domínio extensos Responsabilidades: Uma parte limitada da lógica de negócios. Limite de transações: Cuidado com casos de falhas, considere estratégias como consistência eventual Requisitos de desempenho e escalabilidade Contratos explícitos entre as APIs -
@jessilyneh Inicie com microsserviços maiores e ajuste seus limites com
base no feedback da equipe e experiência prática. -
Comunicação Síncrona vs Assíncrona @jessilyneh Síncrona: as chamadas criam uma
cadeia de dependências por meio de todos os serviços Um serviço que faz uma chamada síncrona para um carrinho de compras também pode ficar dependente do pagamento associado e dos serviços de armazenamento. Se um ou mais desses serviços não estiverem disponíveis, é improvável que o chamador receba uma resposta. Mesmo que haja uma resposta, pode demorar tanto que o usuário encerrará a sessão -
Comunicação Síncrona @jessilyneh Padrão de Requisição-Resposta Bloqueio de Recursos Simplicidade
de Implementação Depuração Simples Latência de Rede Crítica: Em cenários onde a latência de rede é crítica, a comunicação síncrona pode ser preferível, pois a resposta é imediata. -
Comunicação Síncrona vs Assíncrona @jessilyneh Assíncrona: Pode ser realizada por
meio de mensagens assíncronas ou sondagem HTTP, aliada a uso de message brokers, como Kafka ou RabbitMQ. Cada microsserviço envia mensagens para o message broker e os outros microsserviços pegam as mensagens quando estiverem prontos -
Comunicação Assíncrona @jessilyneh Desacoplamento e Escalabilidade Resiliência O emissor não
fica bloqueado esperando por uma resposta. Redução de Sobrecarga .Filas de Mensagens Complexidade Adicional: Especialmente na lógica de tratamento de mensagens e na coordenação de eventos. -
Uso Combinado @jessilyneh Operações críticas em tempo real podem ocorrer
de forma síncrona, enquanto operações não críticas ou processamentos em lote podem ser tratados de forma assíncrona. -
Impacto das métricas de Desempenho e Escalabilidade @jessilyneh Tempo de
Resposta: baixos tempos de resposta são desejáveis para garantir uma resposta rápida às solicitações do cliente. Taxa de Erros: Podem afetar a confiabilidade do sistema e a satisfação do usuário. Utilização de Recursos (CPU, Memória): altas taxas de utilização podem indicar a necessidade de escalabilidade ou otimização de código. Latência de Rede: podem prejudicar o desempenho geral do sistema e exigir estratégias de otimização. -
Ações: métricas de Desempenho e Escalabilidade @jessilyneh Otimização de Código
Escalonamento Automático: Utilizar sistemas de escalabilidade automática para ajustar dinamicamente o número de instâncias de microsserviços com base nas métricas de desempenho. Ajuste de Recursos Estratégias de Cache: Implementar estratégias de cache para reduzir a carga em microsserviços e melhorar os tempos de resposta. Revisão de Arquitetura -
Como Avaliar e Refinar Decisões arquiteturais @jessilyneh Identificar microsserviços Avaliar
as decisões arquitetônicas Discutir com a equipe Avaliar e preparar microsserviços Avaliar e refazer as decisões arquitetônicas .Monitorar e ajustar -
Referências @jessilyneh https://www.architectureandgovernance.com/applications-technology/the-mindset-for- architectural-decisions/ M.A. Babar et al., Software Architecture
Knowledge Management: Theory and Practice, Springer, 2009. https://www.infoq.com/articles/sustainable-architectural-design-decisions/ https://adr.github.io/ https://www.koziolek.de/docs/Koziolek2013-IEEE-SW-preprint.pdf https://github.com/joelparkerhenderson/decision-record https://martinfowler.com/bliki/ConwaysLaw.html