Share via

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

  • Artigo

Uma arquitetura de microsserviços pode fornecer muitos benefícios para seus aplicativos, incluindo agilidade, escalabilidade e alta disponibilidade. Junto com esses benefícios, essa 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 ser aprimoradas.

Este guia ajudará você a entender algumas considerações a ter em mente ao migrar 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.

Noções básicas das prioridades de negócios

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

Veja algumas prioridades a serem consideradas:

  • Inovação
  • Confiabilidade
  • Eficiência

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

Registrar decisões de arquitetura

Uma arquitetura de microsserviços ajuda as equipes a se tornarem autônomas. As equipes podem tomar as 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 de microsserviços.

Considere estes fatores:

  • A governança compartilhada está em vigor?
  • Você controla as decisões e as compensações decorrentes 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?

Avaliar a composição da equipe

Você precisa ter a estrutura de equipe adequada para evitar comunicações desnecessárias 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 precisa 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 DDD (design controlado pelo domínio)?
  • Suas equipes são multifuncionais, com capacidade suficiente para criar e operar microsserviços relacionados de modo independente?
  • Quanto tempo é gasto em atividades ad hoc e tarefas que não estão relacionadas a projetos?
  • Quanto tempo é gasto na colaboração entre equipes?
  • Você tem um processo para identificar e minimizar a dívida técnica?
  • Como as lições são aprendidas e a experiência é comunicada entre as equipes?

Usar a metodologia de doze fatores

A meta fundamental de escolher uma arquitetura de microsserviços é fornecer valor mais rapidamente e ser adaptável às alterações seguindo as práticas agile. A metodologia do aplicativo de doze fatores fornece diretrizes para a criação de aplicativos que podem ser mantidos e escaloná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 livremente acoplados e autossuficientes.

Noções básicas sobre a abordagem de decomposição

A transformação de 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 em outros serviços e podem ser facilmente decompostos do sistema como serviços independentes. Padrões como o de Estrangulamento e de Camada Anticorrupção são muito recomendados 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 desse 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. Em seguida, você decide transformar o módulo de geração de faturas. Esse módulo é chamado depois que um pedido é gerado. Você pode usar padrões como o de Estrangulamento e de Anticorrupção para dar suporte a essa transformação.

Sincronização de dados, várias gravações em interfaces monolíticas e de microsserviço, propriedade de dados, decomposição de esquema, junções, volume de dados e integridade de dados podem dificultar a migração e o detalhamento de dados. Há várias técnicas que você pode usar, como manter um banco de dados compartilhado entre microsserviços, desacoplar bancos de dados de um grupo de serviços com base na funcionalidade ou no 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 de Serviço de Encapsulamento de Banco de Dados.

Avaliar a preparação do DevOps

Quando você passa para uma arquitetura de microsserviços, é importante avaliar sua competência do DevOps. Uma arquitetura de microsserviços destina-se a facilitar o desenvolvimento agile em aplicativos 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 funcionalidade de DevOps para uma arquitetura de microsserviços, tenha estes pontos em mente:

  • As pessoas em sua organização conhecem as práticas e os princípios fundamentais do DevOps?
  • As equipes entendem as ferramentas de controle do código-fonte e a integração com pipelines de CI/CD?
  • Você implementa as práticas de DevOps corretamente?
    • Você segue as práticas agile?
    • A integração contínua foi implementada?
    • A entrega contínua foi implementada?
    • A implantação contínua foi implementada?
    • O monitoramento contínuo foi implementado?
    • A IaC (Infraestrutura como Código) está em vigor?
  • Você usa as ferramentas certas para dar suporte a CI/CD?
  • Como a configuração de ambientes de preparo e de 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ócios que mudam com frequência

Uma arquitetura de microsserviços é flexível e adaptável. Durante a avaliação, realize 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 mudanças que os clientes solicitam e minimizam os esforços de teste de regressão. Em um aplicativo monolítico, uma alteração em um módulo requer vários níveis de teste de regressão e reduz a agilidade na liberação de novas versões.

Considere estes fatores:

  • O serviço é implantável de modo independente?
  • O serviço segue os princípios do DDD?
  • O serviço segue os princípios SOLID?
  • O banco de dados no serviço é privado?
  • Você criou o serviço usando o padrão de chassi de microsserviços com suporte?

Avaliar a preparação da infraestrutura

Quando você muda para uma arquitetura de microsserviços, a preparaçã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 preparação da infraestrutura:

  • A infraestrutura garante a escalabilidade dos serviços implantados?
  • A infraestrutura dá suporte ao provisionamento por meio de scripts que podem ser automatizados por meio de CI/CD?
  • A infraestrutura de implantação oferece um SLA para disponibilidade?
  • Você tem um plano de DR (recuperação de desastre) e agendamentos de análise de rotina?
  • Os dados são replicados para regiões diferentes para DR?
  • Você tem um plano de backup de dados?
  • As opções de implantação são documentadas?
  • A infraestrutura de implantação é monitorada?
  • A infraestrutura de implantação dá suporte à autorrecuperação de serviços?

Avaliar ciclos de versão

Os microsserviços são adaptáveis para alterar e aproveitar o desenvolvimento agile para reduzir os ciclos de lançamento e trazer mais valor aos clientes. Considere esses 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 corrigir problemas após uma interrupção?
  • Você usa o controle de versão semântico nos seus aplicativos?
  • Você mantém ambientes diferentes e propaga a mesma versão em uma sequência (por exemplo, primeiro para preparo e depois para produção)?
  • Você usa controle de versão nas 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 gerenciar o controle de versão da API?
    • Controle de versão do caminho do URI
    • Controle de versão do parâmetro de consulta
    • Controle de versão de tipo de conteúdo
    • Controle de versão de cabeçalho personalizado
  • Você tem uma prática em vigor para o controle de versão do evento?

Avaliar a comunicação entre serviços

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

Leve estes fatores em consideração:

  • Você está seguindo uma abordagem orientada para API, na qual as APIs são priorizadas?
  • Você tem operações de cadeia longa, em que vários serviços se comunicam em sequência em um protocolo de comunicação síncrono?
  • Você considerou usar a comunicação assíncrona em alguma parte do sistema?
  • Você avaliou a tecnologia do agente de mensagens e as funcionalidades dela?
  • Você entende a taxa de transferência de mensagens que os serviços recebem e processam?
  • Você usa a comunicação direta do cliente com o serviço?
  • Você precisa persistir mensagens no nível do agente de mensagens?
  • Você está usando o padrão de Exibição Materializada para abordar o comportamento de excesso de comunicação de microsserviços?
  • Você implementou Nova tentativa, Disjuntor, Retirada Exponencial e Variação para ter uma comunicação confiável? Uma forma comum de lidar com isso é usar o padrão Embaixador.
  • 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 principais componentes em uma arquitetura de microsserviços. Expor diretamente os serviços aos clientes cria problemas de capacidade de gerenciamento, controle e comunicação confiável. Um gateway de API serve como um servidor proxy, interceptando o tráfego e roteando-o para serviços de 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 de API sem fazer nenhuma alteração nos serviços.

Leve estes fatores em consideração:

  • Os serviços são consumidos diretamente pelos clientes?
  • Há um gateway de API que atua como fachada para todos os serviços?
  • O gateway de API pode configurar políticas como limites de cota, respostas incorretas 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?
  • O gateway de API fornece um portal em que os clientes podem descobrir e assinar serviços, como um portal do desenvolvedor no Gerenciamento de API do Azure?
  • Sua solução fornece funcionalidades de balanceamento de carga L7 ou WAF (Firewall de Aplicativo Web) juntamente com o gateway de API?

Avaliar o gerenciamento de transações

As transações distribuídas facilitam a execução de várias operações como uma unidade de trabalho. Em uma arquitetura de microsserviços, o sistema é decomposto em vários serviços. Um caso de uso empresarial é abordado por vários microsserviços como parte de uma 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á disparar outro comando, que poderá disparar 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.

Leve 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? Avalie 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 em transações que abrangem vários serviços?

Avaliar 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 elas escolhem. No desenvolvimento tradicional de aplicativos, você pode reutilizar o código existente ao criar componentes ou desenvolver uma estrutura de desenvolvimento interna para reduzir o esforço de desenvolvimento. O uso de várias tecnologias pode impedir a reutilização de 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 de doze fatores e usa uma só base de código para microsserviços, isolando dependências e externalizando a configuração?
  • Você mantém a configuração confidencial em cofres de chaves?
  • Você conteineriza seus serviços?
  • Você conhece seus requisitos de consistência de dados?

Avaliar sua abordagem de implantação

Sua abordagem de implantação é seu método para liberar versões do aplicativo em vários ambientes de implantação. Os sistemas baseados em microsserviços fornecem a agilidade de lançar versões mais rapidamente do que em 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 ao implantar serviços?
  • Você provisiona a infraestrutura usando a IaC (Infraestrutura como Código)?
  • Você usa funcionalidades de DevOps para automatizar implantações?
  • Você propaga os mesmos builds para vários ambientes, conforme sugerido pela metodologia do aplicativo de doze fatores?

Avaliar sua plataforma de hospedagem

A escalabilidade é uma das principais vantagens das arquiteturas de microsserviços. Isso ocorre porque os microsserviços são mapeados para domínios de negócios, para que cada serviço possa ser escalonado de modo independente. Um aplicativo monolítico é implantado como uma unidade em uma plataforma de hospedagem e precisa ser escalado de modo holístico. 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 empresariais individuais. Mas devido à falta de limites de processo, o potencial de violar os princípios da responsabilidade única torna-se mais difícil. Isso eventualmente resulta em um código espaguete. Como o aplicativo é composto e implantado como um só processo de hospedagem, a escalabilidade é difícil.

Os microsserviços permitem que as equipes escolham a plataforma de hospedagem correta para dar suporte às necessidades de escalabilidade. Várias plataformas de hospedagem estão disponíveis para enfrentar esses desafios, fornecendo funcionalidades 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 é escalonável? Ele dá suporte ao 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 dá suporte à recuperação de desastre?

Avaliar 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 executados de modo independente, a solucionar erros pode ser assustador. Se você usar a semântica adequada para monitorar seus serviços, suas equipes poderão monitorar, investigar e responder facilmente a erros.

Considere estes fatores:

  • Você monitora seus serviços implantados?
  • Você tem um mecanismo de registro em log? Quais ferramentas você usa?
  • Você tem uma infraestrutura de rastreamento distribuído em vigor?
  • Você registra exceções?
  • Você mantém códigos de erro de negócios para identificação rápida de problemas?
  • Você usa investigações de integridade para serviços?
  • Você usa registro em log semântico? Você implementou as principais métricas, limites e indicadores?
  • Você mascara dados confidenciais durante o registro em log?

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

Em uma arquitetura de microsserviços, um aplicativo é composto por vários microsserviços hospedados de modo independente, interagindo uns com os outros para atender a vários casos de uso empresarial. Quando um aplicativo interage com serviços de 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 ajudar na solução de erros. Eles ajudam você a determinar a causa raiz de um problema, avaliar o impacto e determinar uma abordagem para corrigir o problema.

Você pode usar tokens de correlação para recuperar o caminho da solicitação identificando quais serviços contêm o token de correlação e quais não contêm. Os serviços que não têm o token de correlação para essa solicitação falharam. Se ocorrer uma falha, você poderá tentar novamente a transação posteriormente. Para impor a idempotência, somente 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 os serviços poderá ajudar a investigar problemas com facilidade se algum dos serviços falhar durante uma transação. Normalmente, cada serviço tem o próprio banco de dados. O token de correlação é mantido no registro do banco de dados. No caso de uma reprodução de transação, os serviços que têm esse token de correlação específico nos bancos de dados ignoram a solicitação. Somente os serviços que não têm o token atendem à solicitação.

Considere estes fatores:

  • Em que fase 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 de 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 base que fornece funcionalidades para preocupações paralelas, como registro em log, 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 de infraestrutura.

Por exemplo, digamos que você esteja criando um serviço de gerenciamento de carrinhos. Você deseja validar o token de entrada, gravar logs no banco de dados de registro em 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 implementar preocupações paralelas.

Considere estes fatores:

  • Você usa uma estrutura de chassi de microsserviços?
  • Você usa o Dapr para interagir com preocupações paralelas?
  • Sua linguagem de estrutura de chassi é agnóstica?
  • Sua estrutura de chassis é genérica para dar suporte a todos os tipos de aplicativos? Uma estrutura de chassi não deve conter a lógica específica do aplicativo.
  • A estrutura do chassi fornece um mecanismo para usar os componentes ou serviços selecionados, conforme necessário?

Avaliar sua abordagem para testes de aplicativo

Tradicionalmente, o teste é feito após o desenvolvimento ser concluído e quando o aplicativo está pronto para ser distribuído para o UAT (teste de aceitação do usuário) e ambientes de produção. Atualmente, há uma mudança nessa abordagem, realizando o teste antecipadamente (à esquerda) no ciclo de vida do desenvolvimento do aplicativo. O teste de mudança antecipada aumenta a qualidade dos aplicativos porque os testes são feitos durante cada fase do ciclo de vida do desenvolvimento de aplicativos, 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 de mudança antecipada, você testa o design de vulnerabilidades usando ferramentas como o Microsoft Threat Modeling. Ao iniciar o desenvolvimento, você pode verificar seu código-fonte executando ferramentas como SAST (teste de segurança de aplicativo estático) e usando outros analisadores para descobrir problemas. Depois de implantar o aplicativo, você pode usar ferramentas como o DAST (teste dinâmico de segurança de aplicativo) para testá-lo enquanto ele está hospedado. Testes funcionais, testes do caos, testes de penetração e outros tipos de teste acontecem mais tarde.

Considere estes fatores:

  • Você escreve planos de teste que abrangem todo o ciclo de vida de desenvolvimento?
  • Você inclui testadores em reuniões de requisitos e em todo o ciclo de vida de desenvolvimento de aplicativos?
  • Você usa design controlado por teste ou por 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ático ou outras ferramentas para medir a qualidade do código?
  • Você usa ferramentas automatizadas para testar aplicativos?
  • Você implementa práticas do Secure DevOps?
  • Você faz testes de integração, teste de aplicativo de ponta a ponta, teste de carga/desempenho, teste de penetração e teste do caos?

Avaliar a segurança dos microsserviços

A proteção do serviço, o acesso seguro e a 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 a validação de token para cada serviço não é uma solução viável. Esse sistema afetaria a agilidade do sistema geral e o potencial de introduzir o descompasso de implementação entre os 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 implementar os 10 principais princípios de OWASP para interceptar o tráfego. Por fim, eles enviam a solicitação para os microsserviços de back-end. Essa configuração ajuda os desenvolvedores a se concentrarem nas necessidades empresariais, em vez de da preocupação paralela com a 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 o SSL ou o mTLS para fornecer segurança para comunicação de serviço?
  • 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 Gateway de API para controlar o tráfego?

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

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

Próximas etapas