Padrões de design de microsserviços mais importantes para se preparar para entrevistas

Como funcionam os padrões de design de microsserviços

Os padrões de design de microsserviços tornaram-se cada vez mais populares devido à sua capacidade de melhorar a agilidade, escalabilidade, resiliência e capacidade de manutenção do software. Os padrões de design de microsserviços são um conjunto de princípios e práticas recomendadas usados ​​para desenvolver e manter sistemas de software compostos de serviços pequenos e implementáveis ​​de forma independente. arquiteturas.

Gateway de API:

Um API Gateway é um serviço que atua como front-end para microsserviços. Ele recebe solicitações de clientes e as encaminha para o serviço apropriado.

Como funciona o padrão API Gateway:

O padrão API Gateway funciona interceptando solicitações de clientes e roteando-as para o serviço apropriado. Quando um cliente faz uma solicitação ao sistema, a solicitação é enviada primeiro ao API Gateway. O API Gateway verifica se a solicitação está autorizada e, em caso afirmativo, encaminha a solicitação para o serviço apropriado.

O API Gateway também pode executar outras funções, como limitação de taxa, cache e autenticação. Por exemplo, pode limitar o número de solicitações que um cliente pode fazer a um serviço em um determinado período de tempo. Ele também pode armazenar em cache as respostas dos serviços para reduzir a carga nos serviços subjacentes.

Disjuntor:

O padrão Circuit Breaker é usado para detectar falhas e prevenir falhas em cascata em um sistema distribuído. Funciona como um disjuntor elétrico, que desarma e interrompe o circuito em caso de sobrecarga, evitando danos aos equipamentos elétricos. Da mesma forma, o padrão do disjuntor pode desarmar e interromper o fluxo de tráfego para um sistema com falha.

Como funciona o padrão do disjuntor:

O padrão Circuit Breaker funciona monitorando a integridade de um componente do sistema e tomando medidas quando detecta uma falha. O disjuntor possui três estados: fechado, aberto e semi-aberto.

1. Estado fechado: No estado fechado, o disjuntor permite que o tráfego flua normalmente para o componente do sistema. O disjuntor monitora os tempos de resposta e as taxas de erro do componente do sistema.
2. Estado aberto: Se o disjuntor detectar que o componente do sistema está falhando, ele desarma e entra no estado aberto. No estado aberto, o disjuntor interrompe todo o tráfego para o componente do sistema e redireciona o tráfego para um componente de backup ou retorna uma mensagem de erro ao cliente.
3. Estado semiaberto: Após um determinado período de tempo, o disjuntor entra no estado semiaberto. No estado semi-aberto, o disjuntor permite que uma quantidade limitada de tráfego flua para o componente do sistema. Se o componente do sistema responder com sucesso ao tráfego, o disjuntor retorna ao estado fechado. Se o componente do sistema não responder com sucesso, o disjuntor retorna ao estado aberto.

Em um sistema tradicional, existe um único modelo que manipula as operações de leitura e gravação. Esse modelo é responsável por manter o estado do sistema, processar comandos e retornar dados ao cliente. No entanto, à medida que o sistema cresce em complexidade e tamanho, torna-se difícil dimensionar e manter.

Para superar o problema acima, o padrão CQRS separa as operações de leitura e gravação em dois modelos diferentes: o modelo Command e o modelo Query. O modelo Command é responsável por manipular as operações de gravação e atualizar o estado do sistema. O modelo Query é responsável por manipular operações de leitura e retornar dados ao cliente.

Como funciona o padrão CQRS:

Quando um cliente envia um comando para o sistema, ele é tratado pelo modelo Command. O modelo Command processa o comando e atualiza o estado do sistema. Se o comando for bem-sucedido, ele retornará uma mensagem de sucesso ao cliente.

Quando um cliente envia uma consulta ao sistema, ela é tratada pelo modelo Consulta. O modelo Query recupera os dados do sistema e os retorna ao cliente. O modelo Query pode ser otimizado para operações de leitura, o que pode melhorar o desempenho do sistema.

Fornecimento de Eventos

Event sourcing é um padrão usado no design de software que envolve a modelagem do estado de um aplicativo como uma sequência de eventos. Em vez de armazenar o estado atual do aplicativo, o sistema armazena uma sequência de eventos.

Como funciona o fornecimento de eventos:

O padrão de fonte de eventos funciona armazenando uma sequência de eventos que descrevem mudanças no estado de um aplicativo. Cada evento é armazenado como um registro separado em um armazenamento de eventos, que é um banco de dados otimizado para armazenar grandes números de eventos.

Quando um usuário interage com o sistema, o sistema gera um evento que descreve a ação do usuário. Por exemplo, se um usuário fizer um pedido, o sistema gerará um evento que descreve os detalhes do pedido. O evento seria armazenado no armazenamento de eventos e o sistema atualizaria o estado do aplicativo com base no evento.

Quando o estado do aplicativo precisa ser consultado, o sistema lê todos os eventos no armazenamento de eventos e os aplica em sequência para reconstruir o estado atual do aplicativo. Esse processo é conhecido como repetição de evento.

Padrão Saga

O padrão de projeto Saga é uma técnica usada em sistemas distribuídos para manter a consistência em várias transações envolvendo vários serviços. Ele é usado para gerenciar transações distribuídas em vários serviços de forma a garantir a consistência dos dados.

Em um sistema distribuído, é comum que uma única transação envolva vários serviços. Por exemplo, em um sistema de comércio eletrônico, um único pedido pode exigir atualizações no serviço de estoque, serviço de pagamento e serviço de remessa. Se algum desses serviços falhar, isso pode levar a inconsistências nos dados. O padrão Saga ajuda a garantir que a transação seja concluída com sucesso ou revertida se ocorrer algum erro.

O padrão Saga funciona dividindo uma única transação em várias transações menores, também conhecidas como “transações de compensação”. Essas transações de compensação são executadas em uma ordem específica e são projetadas para desfazer os efeitos da transação anterior caso ocorra algum erro. A ordem das transações de compensação é crucial para garantir que o sistema permaneça consistente.

Conclusão

Embora os padrões de design de microsserviços ofereçam muitos benefícios, eles também introduzem novas complexidades, como orquestração de serviços, comunicação serviço a serviço e gerenciamento de sistemas distribuídos. Portanto, é importante considerar cuidadosamente os padrões de design apropriados para um determinado aplicativo, levando em consideração os requisitos de negócios, as restrições técnicas e a experiência da equipe de desenvolvimento.

Em geral, com os padrões de design de microsserviços, as organizações podem criar sistemas de software mais flexíveis, escaláveis ​​e resilientes.

Consulte os links para os conceitos do Spring Boot:

Acesso baseado em funções do Spring Security com Spring Boot

Autenticação e autorização do Spring Security com JWT

Tutorial de primavera AOP

Tutorial de log de inicialização do Spring

Configuração Centralizada no Spring Boot