Partilhar via

Avaliação e prontidão de microsserviços

  • Artigo

Uma arquitetura de microsserviços pode fornecer muitos benefícios para seus aplicativos, incluindo agilidade, escalabilidade e alta disponibilidade. Juntamente com estes benefícios, esta arquitetura apresenta desafios. Ao criar aplicativos baseados em microsserviços ou transformar aplicativos existentes em uma arquitetura de microsserviços, você precisa analisar e avaliar sua situação atual para identificar áreas que precisam de melhorias.

Este guia irá ajudá-lo a entender algumas considerações a ter em mente quando você mudar para uma arquitetura de microsserviços. Você pode usar este guia para avaliar a maturidade de seu aplicativo, infraestrutura, DevOps, modelo de desenvolvimento e muito mais.

Compreender as prioridades de negócios

Para começar a avaliar uma arquitetura de microsserviços, você precisa primeiro entender as principais prioridades do seu negócio. As principais prioridades podem estar relacionadas à agilidade, adoção de mudanças ou desenvolvimento rápido, por exemplo. Você precisa analisar se sua arquitetura é adequada às suas principais prioridades. Tenha em mente que as prioridades de negócios podem mudar ao longo do tempo. Por exemplo, a inovação é uma prioridade para as startups, mas depois de alguns anos, as principais prioridades podem ser a confiabilidade e a eficiência.

Eis algumas prioridades a considerar:

  • Inovação
  • Fiabilidade
  • Eficiência

Documente os SLAs que estão alinhados com várias partes do seu aplicativo para garantir um compromisso organizacional que possa servir como um guia para sua avaliação.

Registrar decisões arquitetônicas

Uma arquitetura de microsserviços ajuda as equipes a se tornarem autônomas. As equipes podem tomar suas próprias decisões sobre tecnologias, metodologias e componentes de infraestrutura, por exemplo. No entanto, essas escolhas devem respeitar os princípios formalmente acordados conhecidos como governança compartilhada, que expressam o acordo entre as equipes sobre como abordar a estratégia mais ampla para microsserviços.

Considere estes fatores:

  • Existe uma governação partilhada?
  • Você acompanha as decisões e seus trade-offs em um diário de arquitetura?
  • Sua equipe pode acessar facilmente seu diário de arquitetura?
  • Você tem um processo para avaliar ferramentas, tecnologias e estruturas?

Avalie a composição da equipe

Você precisa ter a estrutura de equipe adequada para evitar a comunicação desnecessária entre as equipes. Uma arquitetura de microsserviços incentiva a formação de equipes pequenas, focadas e multifuncionais e requer uma mudança de mentalidade, que deve ser precedida pela reestruturação da equipe.

Considere estes fatores:

  • Suas equipes são divididas com base em subdomínios, seguindo os princípios de design orientado a domínio (DDD)?
  • Suas equipes são multifuncionais, com capacidade suficiente para criar e operar microsserviços relacionados de forma independente?
  • Quanto tempo é gasto em atividades ad hoc e tarefas que não estão relacionadas com projetos?
  • Quanto tempo é gasto na colaboração entre equipas?
  • Você tem um processo para identificar e minimizar a dívida técnica?
  • Como as lições aprendidas e a experiência são comunicadas entre as equipes?

Use a metodologia dos doze fatores

O objetivo fundamental da escolha de uma arquitetura de microsserviços é entregar valor mais rapidamente e ser adaptável à mudança, seguindo práticas ágeis. A metodologia do aplicativo Twelve-Factor fornece diretrizes para a criação de aplicativos que podem ser mantidos e escaláveis. Essas diretrizes promovem atributos como imutabilidade, efemeridade, configuração declarativa e automação. Ao incorporar essas diretrizes e evitar armadilhas comuns, você pode criar microsserviços autônomos e com acoplamento flexível.

Compreender a abordagem de decomposição

Transformar um aplicativo monolítico em uma arquitetura de microsserviços leva tempo. Comece com serviços de borda. Os serviços de borda têm menos dependências de outros serviços e podem ser facilmente decompostos do sistema como serviços independentes. É altamente recomendável padrões como Strangler Fig e Anti-corruption Layer para manter o aplicativo monolítico em um estado de funcionamento até que todos os serviços sejam decompostos em microsserviços separados. Durante a segregação, os princípios do DDD podem ajudar as equipes a escolher componentes ou serviços do aplicativo monolítico com base em subdomínios.

Por exemplo, em um sistema de comércio eletrônico, você pode ter estes módulos: carrinho, gerenciamento de produtos, gerenciamento de pedidos, preços, geração de faturas e notificação. Você decide iniciar a transformação do aplicativo com o módulo de notificação porque ele não tem dependências em outros módulos. No entanto, outros módulos podem depender deste módulo para enviar notificações. O módulo de notificação pode ser facilmente decomposto em um microsserviço separado, mas você precisará fazer algumas alterações no aplicativo monolítico para chamar o novo serviço de notificação. Você decide transformar o módulo de geração de faturas em seguida. Este módulo é chamado depois que um pedido é gerado. Você pode usar padrões como Strangler e Anticorrupção para dar suporte a essa transformação.

A sincronização de dados, as gravações múltiplas em interfaces monolíticas e de microsserviços, a propriedade dos dados, a decomposição do esquema, as junções, o volume de dados e a integridade dos dados podem dificultar a divisão e a migração dos dados. Há várias técnicas que você pode usar, como manter um banco de dados compartilhado entre microsserviços, dissociar bancos de dados de um grupo de serviços com base na capacidade ou domínio de negócios e isolar bancos de dados dos serviços. A solução recomendada é decompor cada banco de dados com cada serviço. Em muitas circunstâncias, isso não é prático. Nesses casos, você pode usar padrões como o padrão de Exibição de Banco de Dados e o padrão Serviço de Encapsulamento de Banco de Dados.

Avalie a prontidão do DevOps

Quando você muda para uma arquitetura de microsserviços, é importante avaliar sua competência de DevOps. Uma arquitetura de microsserviços destina-se a facilitar o desenvolvimento ágil em aplicações para aumentar a agilidade organizacional. O DevOps é uma das principais práticas que você deve implementar para alcançar essa competência.

Ao avaliar sua capacidade de DevOps para uma arquitetura de microsserviços, lembre-se destes pontos:

  • As pessoas na sua organização conhecem as práticas e os princípios fundamentais do DevOps?
  • As equipes entendem as ferramentas de controle de origem e sua integração com pipelines de CI/CD?
  • Você implementa as práticas de DevOps corretamente?
    • Você segue práticas ágeis?
    • A integração contínua é implementada?
    • A entrega contínua é implementada?
    • A implantação contínua é implementada?
    • A monitorização contínua é implementada?
    • A infraestrutura como código (IaC) está em vigor?
  • Você usa as ferramentas certas para suportar CI/CD?
  • Como a configuração de ambientes de preparação e produção é gerenciada para o aplicativo?
  • A cadeia de ferramentas tem suporte da comunidade e um modelo de suporte e fornece canais e documentação adequados?

Identificar áreas de negócio que mudam frequentemente

Uma arquitetura de microsserviços é flexível e adaptável. Durante a avaliação, conduza uma discussão na organização para determinar as áreas que seus colegas acham que mudarão com frequência. A criação de microsserviços permite que as equipes respondam rapidamente às alterações solicitadas pelos clientes e minimizem os esforços de teste de regressão. Em uma aplicação monolítica, uma alteração em um módulo requer vários níveis de testes de regressão e reduz a agilidade no lançamento de novas versões.

Considere estes fatores:

  • O serviço pode ser implantado de forma independente?
  • O serviço segue os princípios do DDD?
  • O serviço segue os princípios SOLID?
  • A base de dados é privada para o serviço?
  • Você criou o serviço usando o padrão de chassi de microsserviços suportado?

Avaliar a prontidão da infraestrutura

Quando você muda para uma arquitetura de microsserviços, a prontidão da infraestrutura é um ponto crítico a ser considerado. O desempenho, a disponibilidade e a escalabilidade do aplicativo serão afetados se a infraestrutura não estiver configurada corretamente ou se os serviços ou componentes corretos não forem usados. Às vezes, um aplicativo é criado com todas as metodologias e procedimentos sugeridos, mas a infraestrutura é inadequada. Isso resulta em baixo desempenho e manutenção.

Considere estes fatores ao avaliar a prontidão da infraestrutura:

  • A infraestrutura garante a escalabilidade dos serviços implantados?
  • A infraestrutura suporta o provisionamento por meio de scripts que podem ser automatizados via CI/CD?
  • A infraestrutura de implantação oferece um SLA para disponibilidade?
  • Você tem um plano de recuperação de desastres (DR) e cronogramas de exercícios de rotina?
  • Os dados são replicados para diferentes regiões para DR?
  • Você tem um plano de backup de dados?
  • As opções de implantação estão documentadas?
  • A infraestrutura de implantação é monitorada?
  • A infraestrutura de implantação oferece suporte à autorrecuperação de serviços?

Avaliar os ciclos de libertação

Os microsserviços são adaptáveis à mudança e aproveitam o desenvolvimento ágil para encurtar os ciclos de lançamento e agregar mais valor aos clientes. Considere estes fatores ao avaliar seus ciclos de lançamento:

  • Com que frequência você cria e lança aplicativos?
  • Com que frequência suas versões falham após a implantação?
  • Quanto tempo leva para recuperar ou remediar problemas após uma interrupção?
  • Você usa versionamento semântico para seus aplicativos?
  • Você mantém ambientes diferentes e propaga a mesma liberação em uma sequência (por exemplo, primeiro para a preparação e depois para a produção)?
  • Você usa o controle de versão para suas APIs?
  • Você segue as diretrizes de controle de versão adequadas para APIs?
  • Quando você altera uma versão da API?
  • Qual é a sua abordagem para lidar com o controle de versão de API?
    • Controle de versão de caminho de URI
    • Controle de versão do parâmetro de consulta
    • Controle de versão do tipo de conteúdo
    • Controle de versão de cabeçalho personalizado
  • Você tem uma prática para versionamento de eventos?

Avalie a comunicação entre serviços

Os microsserviços são serviços autônomos que se comunicam entre si através dos limites do processo para lidar com cenários de negócios. Para obter uma comunicação confiável e confiável, você precisa selecionar um protocolo de comunicação apropriado.

Leve estes fatores em consideração:

  • Você está seguindo uma abordagem API-first, onde as APIs são tratadas como cidadãos de primeira classe?
  • Você tem operações de cadeia longa, onde vários serviços se comunicam em sequência por meio de um protocolo de comunicação síncrono?
  • Já pensou em comunicação assíncrona em qualquer lugar do sistema?
  • Você avaliou a tecnologia do corretor de mensagens e suas capacidades?
  • Você entende a taxa de transferência de mensagens que os serviços recebem e processam?
  • Você usa a comunicação direta cliente-serviço?
  • Você precisa persistir mensagens no nível do agente de mensagens?
  • Você está usando o padrão de Visualização Materializada para abordar o comportamento tagarela dos microsserviços?
  • Você implementou Retry, Circuit Breaker, Exponential Backoff e Jitter para uma comunicação confiável? Uma maneira comum de lidar com isso é usar o padrão Ambassador.
  • Você definiu eventos de domínio para facilitar a comunicação entre microsserviços?

Avaliar como os serviços são expostos aos clientes

Um gateway de API é um dos componentes principais em uma arquitetura de microsserviços. Expor diretamente os serviços aos clientes cria problemas em termos de gerenciabilidade, controle e comunicação confiável. Um gateway de API serve como um servidor proxy, intercetando o tráfego e roteando-o para serviços back-end. Se você precisar filtrar o tráfego por endereço IP, autorização, respostas simuladas e assim por diante, poderá fazê-lo no nível do gateway da API sem fazer alterações nos serviços.

Leve estes fatores em consideração:

  • Os serviços são consumidos diretamente pelos clientes?
  • Existe um gateway de API que funciona como uma fachada para todos os serviços?
  • O gateway de API pode configurar políticas como limites de cota, respostas simuladas e filtragem de endereços IP?
  • Você está usando vários gateways de API para atender às necessidades de vários tipos de clientes, como aplicativos móveis, aplicativos Web e parceiros?
  • Seu gateway de API fornece um portal onde os clientes podem descobrir e assinar serviços, como um portal do desenvolvedor no Gerenciamento de API do Azure?
  • Sua solução fornece recursos de balanceamento de carga L7 ou WAF (Web Application Firewall) junto com o gateway de API?

Avaliar o tratamento das transações

As transações distribuídas facilitam a execução de múltiplas operações como uma única unidade de trabalho. Em uma arquitetura de microsserviços, o sistema é decomposto em vários serviços. Um único caso de uso comercial é abordado por vários microsserviços como parte de uma única transação distribuída. Em uma transação distribuída, um comando é uma operação que começa quando ocorre um evento. O evento dispara uma operação no sistema. Se a operação for bem-sucedida, ela poderá acionar outro comando, que poderá acionar outro evento, e assim por diante até que todas as transações sejam concluídas ou revertidas, dependendo se a transação for bem-sucedida.

Tenha em conta as seguintes considerações:

  • Quantas transações distribuídas existem no sistema?
  • Qual é a sua abordagem para lidar com transações distribuídas? Avaliar o uso do padrão Saga com orquestração ou coreografia.
  • Quantas transações abrangem vários serviços?
  • Você está seguindo um modelo de transação ACID ou BASE para obter consistência e integridade de dados?
  • Você está usando operações de encadeamento longo para transações que abrangem vários serviços?

Avalie seu modelo de desenvolvimento de serviços

Um dos maiores benefícios das arquiteturas de microsserviços é a diversidade tecnológica. Os sistemas baseados em microsserviços permitem que as equipes desenvolvam serviços usando as tecnologias que escolherem. No desenvolvimento de aplicativos tradicional, você pode reutilizar o código existente ao criar novos componentes ou criar uma estrutura de desenvolvimento interna para reduzir o esforço de desenvolvimento. O uso de várias tecnologias pode impedir a reutilização do código.

Considere estes fatores:

  • Você usa um modelo de serviço para iniciar o desenvolvimento de novos serviços?
  • Você segue a metodologia do aplicativo Twelve-Factor e usa uma única base de código para microsserviços, isolando dependências e externalizando a configuração?
  • Você mantém a configuração sensível nos cofres de chaves?
  • Contentores dos seus serviços?
  • Conhece os seus requisitos de consistência de dados?

Avalie sua abordagem de implantação

Sua abordagem de implantação é seu método para liberar versões de seu aplicativo em vários ambientes de implantação. Os sistemas baseados em microsserviços fornecem a agilidade para lançar versões mais rápido do que você pode com aplicativos tradicionais.

Ao avaliar seu plano de implantação, considere estes fatores:

  • Você tem uma estratégia para implantar seus serviços?
  • Você está usando ferramentas e tecnologias modernas para implantar seus serviços?
  • Que tipo de colaboração é necessária entre as equipes quando você implanta serviços?
  • Você provisiona a infraestrutura usando a infraestrutura como código (IaC)?
  • Você usa os recursos de DevOps para automatizar implantações?
  • Você propaga as mesmas compilações para vários ambientes, como sugerido pela metodologia do aplicativo Twelve-Factor?

Avalie sua plataforma de hospedagem

A escalabilidade é uma das principais vantagens das arquiteturas de microsserviços. Isso porque os microsserviços são mapeados para domínios de negócios, para que cada serviço possa ser dimensionado de forma independente. Um aplicativo monolítico é implantado como uma única unidade em uma plataforma de hospedagem e precisa ser dimensionado de forma holística. Isso resulta em tempo de inatividade, risco de implantação e manutenção. Seu aplicativo monolítico pode ser bem projetado, com componentes que abordam domínios de negócios individuais. Mas, devido à falta de limites processuais, o potencial para violar os princípios da responsabilidade única torna-se mais difícil. Isso eventualmente resulta em código de espaguete. Como o aplicativo é composto e implantado como um único processo de hospedagem, a escalabilidade é difícil.

Os microsserviços permitem que as equipes escolham a plataforma de hospedagem certa para suportar suas necessidades de escalabilidade. Várias plataformas de hospedagem estão disponíveis para enfrentar esses desafios, fornecendo recursos como dimensionamento automático, provisionamento elástico, maior disponibilidade, implantação mais rápida e monitoramento fácil.

Considere estes fatores:

  • Qual plataforma de hospedagem você usa para implantar seus serviços (máquinas virtuais, contêineres, sem servidor)?
  • A plataforma de hospedagem é escalável? Suporta dimensionamento automático?
  • Quanto tempo leva para escalar sua plataforma de hospedagem?
  • Você entende os SLAs que várias plataformas de hospedagem fornecem?
  • Sua plataforma de hospedagem suporta recuperação de desastres?

Avalie o monitoramento de serviços

O monitoramento é um elemento importante de um aplicativo baseado em microsserviços. Como o aplicativo é dividido em vários serviços que são executados de forma independente, a solução de problemas de erros pode ser assustadora. Se você usar a semântica adequada para monitorar seus serviços, suas equipes poderão facilmente monitorar, investigar e responder a erros.

Considere estes fatores:

  • Você monitora seus serviços implantados?
  • Você tem um mecanismo de registro? Que ferramentas utilizam?
  • Dispõe de uma infraestrutura de rastreio distribuído?
  • Registam exceções?
  • Você mantém códigos de erro de negócios para identificação rápida de problemas?
  • Vocês usam sondas de saúde para serviços?
  • Você usa log semântico? Você implementou métricas, limites e indicadores importantes?
  • Você mascara dados confidenciais durante o registro?

Avaliar a atribuição de token de correlação

Em uma arquitetura de microsserviços, um aplicativo é composto por vários microsserviços que são hospedados de forma independente, interagindo entre si para atender a vários casos de uso de negócios. Quando um aplicativo interage com serviços back-end para executar uma operação, você pode atribuir um número exclusivo, conhecido como token de correlação, à solicitação. Recomendamos que você considere o uso de tokens de correlação, pois eles podem ajudá-lo a solucionar erros. Eles ajudam a determinar a causa raiz de um problema, avaliar o impacto e determinar uma abordagem para remediar o problema.

Você pode usar tokens de correlação para recuperar a trilha de solicitação identificando quais serviços contêm o token de correlação e quais não. Os serviços que não têm o token de correlação para essa solicitação falharam. Se ocorrer uma falha, você pode tentar novamente a transação mais tarde. Para impor a idempotência, apenas os serviços que não têm o token de correlação atenderão à solicitação.

Por exemplo, se você tiver uma longa cadeia de operações que envolve muitos serviços, passar um token de correlação para serviços pode ajudá-lo a investigar problemas facilmente se algum dos serviços falhar durante uma transação. Cada serviço tem normalmente a sua própria base de dados. O token de correlação é mantido no registro do banco de dados. No caso de uma repetição de transação, os serviços que têm esse token de correlação específico em seus bancos de dados ignoram a solicitação. Apenas os serviços que não têm o token atendem à solicitação.

Considere estes fatores:

  • Em que estágio você atribui o token de correlação?
  • Qual componente atribui o token de correlação?
  • Você salva tokens de correlação no banco de dados do serviço?
  • Qual é o formato dos tokens de correlação?
  • Você registra tokens de correlação e outras informações de solicitação?

Avaliar a necessidade de uma estrutura de chassi de microsserviços

Uma estrutura de chassi de microsserviços é uma estrutura básica que fornece recursos para preocupações transversais, como registro, tratamento de exceções, rastreamento distribuído, segurança e comunicação. Ao usar uma estrutura de chassi, você se concentra mais na implementação do limite de serviço do que na interação com a funcionalidade da infraestrutura.

Por exemplo, digamos que você esteja criando um serviço de gerenciamento de carrinho. Você deseja validar o token de entrada, gravar logs no banco de dados de log e se comunicar com outro serviço invocando o ponto de extremidade desse serviço. Se você usar uma estrutura de chassi de microsserviços, poderá reduzir os esforços de desenvolvimento. O Dapr é um sistema que fornece vários blocos de construção para a implementação de preocupações transversais.

Considere estes fatores:

  • Você usa uma estrutura de chassi de microsserviços?
  • Você usa o Dapr para interagir com preocupações transversais?
  • A linguagem da estrutura do chassi é agnóstica?
  • A estrutura do seu chassis é genérica, pelo que suporta todo o tipo de aplicações? Uma estrutura de chassi não deve conter lógica específica do aplicativo.
  • A estrutura do chassi fornece um mecanismo para usar os componentes ou serviços selecionados conforme necessário?

Avalie sua abordagem aos testes de aplicativos

Tradicionalmente, o teste é feito após a conclusão do desenvolvimento e o aplicativo está pronto para ser implementado em ambientes de teste de aceitação do usuário (UAT) e produção. Atualmente, há uma mudança nessa abordagem, movendo o teste no início (esquerda) no ciclo de vida de desenvolvimento do aplicativo. O teste shift-left aumenta a qualidade dos aplicativos porque os testes são feitos durante cada fase do ciclo de vida de desenvolvimento do aplicativo, incluindo as fases de design, desenvolvimento e pós-desenvolvimento.

Por exemplo, ao criar um aplicativo, você começa projetando uma arquitetura. Ao usar a abordagem shift-left, você testa o design em busca de vulnerabilidades usando ferramentas como a Modelagem de Ameaças da Microsoft. Ao iniciar o desenvolvimento, você pode verificar seu código-fonte executando ferramentas como teste estático de segurança de aplicativos (SAST) e usando outros analisadores para descobrir problemas. Depois de implantar o aplicativo, você pode usar ferramentas como o teste dinâmico de segurança de aplicativos (DAST) para testá-lo enquanto está hospedado. Testes funcionais, testes de caos, testes de penetração e outros tipos de testes acontecem mais tarde.

Considere estes fatores:

  • Você escreve planos de teste que abrangem todo o ciclo de vida do desenvolvimento?
  • Você inclui testadores em reuniões de requisitos e em todo o ciclo de vida de desenvolvimento de aplicativos?
  • Você usa design orientado a teste ou design orientado a comportamento?
  • Você testa histórias de usuários? Você inclui critérios de aceitação em suas histórias de usuário?
  • Você testa seu design usando ferramentas como o Microsoft Threat Modeling?
  • Você escreve testes de unidade?
  • Você usa analisadores de código estáticos ou outras ferramentas para medir a qualidade do código?
  • Você usa ferramentas automatizadas para testar aplicativos?
  • Você implementa práticas de Secure DevOps ?
  • Você faz testes de integração, testes completos de aplicativos, testes de carga/desempenho, testes de penetração e testes de caos?

Avalie a segurança dos microsserviços

Proteção de serviços, acesso seguro e comunicação segura estão entre as considerações mais importantes para uma arquitetura de microsserviços. Por exemplo, um sistema baseado em microsserviços que abrange vários serviços e usa validação de token para cada serviço não é uma solução viável. Este sistema afetaria a agilidade do sistema global e o potencial de introdução de desvios de implementação entre serviços.

As preocupações de segurança geralmente são tratadas pelo gateway de API e pelo firewall do aplicativo. O gateway e o firewall recebem solicitações de entrada, validam tokens e aplicam vários filtros e políticas, como a implementação dos 10 principais princípios do OWASP para intercetar o tráfego. Finalmente, eles enviam a solicitação para os microsserviços de back-end. Essa configuração ajuda os desenvolvedores a se concentrarem nas necessidades de negócios em vez da preocupação transversal de segurança.

Considere estes fatores:

  • A autenticação e a autorização são necessárias para o serviço?
  • Você está usando um gateway de API para validar tokens e solicitações de entrada?
  • Você está usando SSL ou mTLS para fornecer segurança para a comunicação de serviços?
  • Você tem políticas de segurança de rede em vigor para permitir a comunicação necessária entre os serviços?
  • Você está usando firewalls (L4, L7) quando aplicável para fornecer segurança para comunicações internas e externas?
  • Você usa políticas de segurança no API Gateway para controlar o tráfego?

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos