Os padrões de projeto de microsserviços servem como estratégias para construir software usando a arquitetura de microsserviços, uma abordagem que divide aplicações únicas em componentes ou serviços menores.
Esses padrões de arquitetura fornecem soluções padronizadas para os desafios diários que as equipes de desenvolvimento enfrentam ao implementar sistemas de computação distribuídos, incluindo comunicação de serviços, consistência de dados, tolerância a falhas e escalabilidade do sistema.
Muitas das experiências digitais atuais das quais o mundo depende são possibilitadas por padrões de projeto de microsserviços e podem ser vistas em muitos casos de uso. Por exemplo, se você está transmitindo um programa na Netflix, está envolvendo centenas de serviços separados que trabalham em conjunto para fornecer conteúdo, gerenciar perfis de usuários e sugerir o que assistir a seguir.
Da mesma forma, a Amazon coordena inventário, pagamentos e envio por meio de serviços distintos. No setor financeiro, bancos e outras instituições também contam com padrões de projeto de microsserviços para separar o gerenciamento de riscos e o atendimento ao cliente, mantendo o dinheiro seguro e acessível.
De acordo com uma pesquisa da IBM, Microservices in the Enterprise, 2021, 88% das organizações relatam que os microsserviços oferecem muitos benefícios às equipes de desenvolvimento. Esses benefícios incluem um aumento de 20% a 50% na produtividade do desenvolvedor devido à melhor organização do código, manutenção mais fácil e ciclos de implementação mais rápidos.
Mantenha-se atualizado sobre as tendências mais importantes (e intrigantes) do setor em IA, automação, dados e muito mais com o boletim informativo Think. Consulte a Declaração de privacidade da IBM.
A arquitetura de microsserviços é um método nativo da nuvem que divide as aplicações em serviços independentes e fracamente acoplados que são implementados em contêineres gerenciados por plataformas de orquestração como o Kubernetes.
Cada serviço opera de forma independente com seu próprio stack de tecnologia, incluindo bancos de dados dedicados e modelos de gerenciamento de dados. A comunicação entre serviços acontece por meio de APIs de REST, plataformas de fluxo de eventos, como o Apache Kafka e brokers de mensagens, enquanto as equipes projetam serviços com base em recursos de negócios com limites claros chamados de contextos limitados.
Essa abordagem moderna ao desenvolvimento de software é compatível com a flexibilidade operacional necessária para iniciativas modernas de transformação digital, como automação de DevOps e pipelines de CI/CD, migração para nuvem, modernização de aplicações e integração de inteligência artificial (IA).
Embora os microsserviços ofereçam vantagens significativas para aplicações modernas, entender quando escolher essa arquitetura exige compará-la às abordagens tradicionais.
A arquitetura monolítica cria uma aplicação como uma única unidade implementável, onde todas as funções de negócios são integradas e compartilham o mesmo banco de código, banco de dados e ambiente de tempo de execução. A arquitetura de microsserviços divide uma aplicação em microsserviços menores e independentes que se comunicam por meio de interfaces de programação de aplicativos (APIs) bem definidas, cada um podendo ter seu próprio banco de dados e ciclo de implementação.
A principal diferença entre esses métodos de projeto é o acoplamento — o quanto as diferentes partes do sistema estão conectadas. Os monólitos têm alto acoplamento interno, mas implementação simples, enquanto os microsserviços têm um acoplamento solto entre os serviços, mas requisitos de infraestrutura de TI mais complexos.
Os engenheiros de software frequentemente optam por arquitetura monolítica para aplicações menores e mais simples, como para pequenas empresas ou startups que buscam controlar custos e acelerar o desenvolvimento. Em cenários complexos que exigem alta escalabilidade, resiliência e flexibilidade (por exemplo, plataformas de redes sociais e aplicações bancárias), os microsserviços são a melhor escolha.
Quando decidir qual abordagem adotar, as organizações devem avaliar cada uma em relação a seus requisitos específicos, incluindo tamanho da equipe, complexidade da aplicação, necessidades de escalabilidade e níveis de maturidade de DevOps.
Saiba mais sobre arquitetura monolítica versus microsserviços.
Os padrões de projeto de microsserviços se enquadram em cinco áreas principais que fornecem soluções testadas que ajudam as equipes a resolver desafios de arquitetura distribuída:
Padrão de registro de serviços
O padrão de registro de serviços cria um diretório central no qual os serviços registram seus endpoints e o status da integridade, eliminando a necessidade de endereços fixos. Quando os serviços precisam se comunicar, eles consultam o registro para encontrar instâncias de servidores disponíveis. Por exemplo, quando um serviço de pagamento precisa entrar em contato com um serviço de inventário, ele verifica o registro para localizar instâncias de inventários íntegras.
Padrão de API Gateway
Um padrão de API Gateway cria um único ponto de entrada entre clientes e vários microsserviços de back-end. Em vez de os clientes fazerem chamadas separadas para diferentes serviços, o API Gateway recebe uma solicitação, encaminha para os microsserviços apropriados e combina as respostas em um único resultado.
Por exemplo, ao carregar uma página de produto, o gateway pode buscar simultaneamente detalhes de produtos, preços, inventário e avaliações de diferentes serviços. Em seguida, retorna todas essas informações em uma única resposta consolidada ao cliente.
Padrões de descoberta de serviços
Um padrão de descoberta de serviços resolve o desafio de os serviços localizarem uns aos outros em ambientes dinâmicos. À medida que os microsserviços aumentam de escala ou são atualizados para uma nova versão, seus locais de rede mudam constantemente. Os padrões de descoberta de serviços fornecem mecanismos automatizados para que os serviços se registrem e encontrem outros serviços com os quais precisam se comunicar, eliminando a necessidade de endereços inalteráveis.
Padrão de banco de dados por serviço
O padrão de banco de dados por serviço garante que cada microsserviço possua e gerencea seu próprio banco de dados, eliminando dependências de dados compartilhadas entre serviços. Essa abordagem impede o acesso a dados entre serviços e reduz o acoplamento, embora exija que os serviços se comuniquem por meio de APIs quando precisam de informações de outras fontes de informação. Por exemplo, em um sistema de planejamento de recursos empresariais (ERP), o serviço de contabilidade gerencia dados financeiros de forma independente do banco de dados de funcionários do serviço de RH.
Padrão Saga
Um padrão saga gerencia transações que abrangem vários microsserviços, dividindo-os em etapas coordenadas. Cada serviço conclui sua transação local e aciona a próxima etapa na cadeia. Se qualquer etapa falhar, o padrão executa automaticamente ações para desfazer as etapas anteriores. Por exemplo, ao processar um pedido online, se o pagamento falhar após o inventário ser reservado, o saga libera automaticamente os itens reservados.
CQRS (padrão de separação das operações de comando e de consulta)
O padrão CQRS separa a modificação de dados (comandos) da recuperação de dados (consultas) usando modelos dedicados para cada uma. Essa divisão permite que o sistema otimize cada caminho de forma independente, minimizando a contenção de gravação no lado do comando e reduzindo a latência de consulta no lado de leitura. Em um sistema de comércio eletrônico, a realização de um pedido usa o modelo de comando otimizado para gravação, enquanto a geração de um relatório de vendas aproveita o modelo de consulta otimizado para leitura.
Padrão de disjuntor
O padrão de disjuntor evita que falhas em um serviço se espalhem por todo o sistema, monitorando chamadas para serviços downstream e interrompendo solicitações quando falhas são detectadas. Quando um serviço deixa de responder, o disjuntor "desarma" e bloqueia novas chamadas, protegendo os recursos do sistema e evitando falhas em cascata.
Por exemplo, se um serviço de inventário ficar inativo, o disjuntor impedirá que o serviço de pedidos faça solicitações repetidas com falha. Isso permite que o restante do sistema continue funcionando enquanto fornece respostas de fallback aos clientes.
Padrão de anteparas
O padrão de anteparas isola os recursos do sistema para evitar que falhas em uma área afetem todo o sistema. Assim como os compartimentos no casco de um navio, as anteparas separam diferentes funções de modo que, se uma falhar, as outras permanecerão operacionais. O padrão limita o número de solicitações simultâneas ou recursos alocados a serviços específicos.
Padrão backend-for-frontend (BFF)
Um padrão back-end for front-end (BFF) cria um serviço de back-end dedicado adaptado a cada interface específica do front-end. Como os aplicativos móveis têm requisitos diferentes das aplicações da web (por exemplo, telas menores, largura de banda limitada, recursos de desempenho variados), o padrão BFF permite que os desenvolvedores otimizem cada back-end para seu front-end específico.
Padrões de entidade e agregado
Um padrão de entidade e agregado organiza dados relacionados em unidades lógicas com base em conceitos de projeto orientado ao domínio (DDD). Uma entidade representa um objeto distinto com uma identidade exclusiva, como uma conta de cliente identificada por um endereço de e-mail. Um agregado combina entidades relacionadas que devem ser atualizadas juntas como uma unidade única.
Por exemplo, em um sistema de comércio eletrônico, um agregado de pedidos incluiria os detalhes dos pedidos, os itens de linha e as informações de envio, que precisam permanecer sincronizados quando ocorrerem alterações.
Padrão estrangulador
Um padrão estranguladorajuda a gerenciar o processo de refatoração de uma aplicação monolítica em uma arquitetura de microsserviços mais sustentável. Novos microsserviços são gradualmente construídos ao lado do monólito existente, assumindo lentamente a funcionalidade até que o sistema antigo seja completamente substituído. O nome vem da metáfora de como uma videira (microsserviços) cresce gradualmente em torno de uma árvore (a aplicação monolítica) e, por fim, a sufoca com o passar do tempo.
Padrão orientado a eventos
Um padrão orientado a eventos permite que os microsserviços se comuniquem de forma assíncrona, publicando e consumindo eventos em vez de fazer chamadas de serviço diretas. Quando um serviço conclui uma ação, ele transmite um evento que outros serviços interessados podem ouvir e responder adequadamente. Essa abordagem cria um acoplamento solto entre os serviços, permitindo que eles operem de forma independente enquanto ainda coordenam suas atividades por meio de um sistema de eventos compartilhado.
Padrão sidecar
Um padrão sidecar refere-se à implementação de um contêiner secundário (o "sidecar") ao lado de uma aplicação principal ou serviço dentro do mesmo ambiente de execução. Esse sidecar lida com questões transversais (por exemplo, registro, monitoramento, segurança, observabilidade), estendendo a funcionalidade da aplicação principal sem modificar sua base de código.
Padrões de microsserviços de adaptadores
Um padrão de microsserviços de adaptadores permite a comunicação entre sistemas ou interfaces incompatíveis. Assim como um adaptador de viagem permite que você conecte seu dispositivo a tomadas no exterior, os padrões de adaptadores realizam a conversão entre diferentes formatos de dados, protocolos ou APIs. Esse padrão é benéfico na integração com sistemas legados ou serviços de terceiros que usam padrões de comunicação diferentes.
Os padrões de projeto de microsserviços são particularmente valiosos em setores que exigem alta escalabilidade, lógica de negócios complexa e desempenho confiável do sistema. Os principais casos de uso incluem:
Os padrões de projeto de microsserviços oferecem as melhores práticas para gerenciar os sistemas distribuídos complexos atuais e oferecem estes amplos benefícios:
A seleção de padrões apropriados depende dos requisitos específicos e dos recursos organizacionais de seu sistema. Usar uma abordagem sistemática pode orientar essas decisões arquitetônicas.
Comece com o API Gateway e a descoberta de serviços antes de implementar padrões complexos, como fonte de eventos ou CQRS. Esses padrões centrais estabelecem a infraestrutura de comunicação necessária para implementações mais sofisticadas.
Considere sua experiência com sistemas distribuídos, maturidade operacional e práticas de DevOps. As equipes novas em microsserviços inicialmente têm o benefício de padrões mais simples, enquanto equipes experientes podem lidar com padrões de coordenação mais avançados, que exigem um conhecimento operacional mais profundo.
Cada padrão introduz uma complexidade que sua equipe deve gerenciar a longo prazo. O banco de dados por serviço requer estratégias de sincronização de dados. Os padrões orientados por eventos precisam de uma infraestrutura de broker de mensagens. Assegure-se de que você tenha a capacidade de compatibilidade com os padrões escolhidos.
Comece com alguns serviços usando padrões básicos, ganhe experiência e expanda à medida que sua experiência aumenta. Essa abordagem incremental evita a engenharia excessiva e permite aprender com as implementações iniciais.
Aproveite o poder da IA e da automação para resolver problemas de forma proativa em todo o stack de aplicações.
Utilize softwares e ferramentas de DevOps para desenvolver, implementar e gerenciar aplicações nativas da nuvem em diversos dispositivos e ambientes.
Acelere a agilidade e o crescimento dos negócios, modernize suas aplicações de forma contínua em qualquer plataforma utilizando nossos serviços de consultoria de nuvem.